Only libraries can form library cycles.
Include library cycles with their API signatures into dumps.
This lets us see how new LibraryCycle instances are created, and
how API signatures are affected by changes to files.
Change-Id: I33d9e6dab34079821b68388a70d5d56f1b39671b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/249781
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
C compilers don't enforce nesting rules. `dart:ffi` was enforcing these
rules causing issues for binding to C libraries having looser packing
for nested structs than outer structs.
This CL completely removes the error from the analyzer and CFE.
(As an alternative we could have kept a hint/lint, but this might create
more noise than value.)
TEST=pkg/analyzer/test/src/diagnostics/packed_nesting_non_packed_test.dart
Closes: https://github.com/dart-lang/sdk/issues/46644
Change-Id: Iae2d5c885546f7799bc6dea2f8cd7dd508216a0c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/247382
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This CL implements `NativeFinalizer` in the GC.
`FinalizerEntry`s are extended to track `external_size` and in which
`Heap::Space` the finalizable value is.
On attaching a native finalizer, the external size is added to the
relevant heap. When the finalizable value is promoted from new to old
space, the external size is promoted as well. And when a native
finalizer is run or is detached, the external size is removed from the
relevant heap again.
In contrast to Dart `Finalizer`s, `NativeFinalizer`s are run on isolate
shutdown.
When the `NativeFinalizer`s themselves are collected, the finalizers are
not run. Users should stick the native finalizer in a global variable to
ensure finalization. We will revisit this design when we add send and
exit support, because there is a design space to explore what to do in
that case. This current solution promises the least to users.
In this implementation native finalizers have a Dart entry to clean up
the entries from the `all_entries` field of the finalizer. We should
consider using another data structure that avoids the need for this Dart
entry. See the TODO left in the code.
Bug: https://github.com/dart-lang/sdk/issues/47777
TEST=runtime/tests/vm/dart(_2)/isolates/fast_object_copy_test.dart
TEST=runtime/vm/object_test.cc
TEST=tests/ffi(_2)/vmspecific_native_finalizer_*
Change-Id: I8f594c80c3c344ad83e1f2de10de028eb8456121
Cq-Include-Trybots: luci.dart.try:vm-kernel-reload-rollback-linux-debug-x64-try,vm-kernel-reload-linux-debug-x64-try,vm-ffi-android-debug-arm64c-try,dart-sdk-mac-arm64-try,vm-kernel-mac-release-arm64-try,pkg-mac-release-arm64-try,vm-kernel-precomp-nnbd-mac-release-arm64-try,vm-kernel-win-debug-x64c-try,vm-kernel-win-debug-x64-try,vm-kernel-precomp-win-debug-x64c-try,vm-kernel-nnbd-win-release-ia32-try,vm-ffi-android-debug-arm-try,vm-precomp-ffi-qemu-linux-release-arm-try,vm-kernel-mac-debug-x64-try,vm-kernel-nnbd-mac-debug-x64-try,vm-kernel-nnbd-linux-debug-ia32-try,benchmark-linux-try,flutter-frontend-try,pkg-linux-debug-try,vm-kernel-asan-linux-release-x64-try,vm-kernel-gcc-linux-try,vm-kernel-optcounter-threshold-linux-release-x64-try,vm-kernel-precomp-linux-debug-simarm_x64-try,vm-kernel-precomp-obfuscate-linux-release-x64-try,vm-kernel-precomp-linux-debug-x64-try,vm-kernel-precomp-linux-debug-x64c-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/236320
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
This appears to be the more widely used term for formal parameters of the
form `this.x`, and the docs ought to reflect common usage.
Also, fixes a typo in one other message.
Change-Id: I261d05e78f813db91a1df072bd72356a5e366226
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/228600
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Fixes https://github.com/dart-lang/sdk/issues/45958
Move check out of old checker.dart, into (less old) error_verifier.dart
and move test case out of old checker_test.dart. Add valid test case.
Rename INVALID_SUPER_INVOCATION to SUPER_INVOCATION_NOT_LAST, and
correct comment on that code (it has a parameter).
Do not duplicate report that code with MULTIPLE_SUPER_INVOCATIONS or
with SUPER_IN_REDIRECTING_CONSTRUCTOR.
Change-Id: I26e28b345fd8cef8ed2c9ec89ab12b56ea1c2f37
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/218982
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Two error messages are affected:
1. When the user tries to access a static member of an extension
through an instance of a class that mentions the extension's "on"
type, and that extension is unnamed, we now report
INSTANCE_ACCESS_TO_STATIC_MEMBER_OF_UNNAMED_EXTENSION instead of
INSTANCE_ACCESS_TO_STATIC_MEMBER. The new error message is the same
as the old one (and uses the same sharedName), but it omits the
correction message suggesting to the user that they try accessing the
static method directly via the extension name, since this advice
doesn't apply.
2. When we report AMBIGUOUS_EXTENSION_MEMBER_ACCESS, if one of the
ambiguous members comes from an unnamed extension, we now report the
unnamed extension as "unnamed extension on '$type'" rather than
referring it to as an extension named `<unnamed>`.
Change-Id: I3ca3a1ccc9399b26b083040de20db8e4f691be32
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/217102
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
The errors HintCode.INVALID_VISIBLE_FOR_OVERRIDING_ANNOTATION and
CompileTimeErrorCode.EXTENSION_CONFLICTING_STATIC_AND_INSTANCE didn't
really need to name the enclosing declaration, since the user can
easily find the enclosing declaration from the location of the error
message. Without this change, there are some situations where an
error message would awkwardly refer to an unnamed extension as having
the name `<unnamed>`.
Change-Id: I4ddec389f18e78167464b1b5c35556e92dd1c15f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/216860
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
I think the headings are now 'correct' in the sense that they are
singular when there's a single example and plural when there is more
than one.
In the process I noticed that we have a similar problem with 'Common
fixes' in that sometimes there's one fix and sometimes multiple. I
don't think it would read well to say 'Common fix', so I'm disinclined
to change those, but it makes me wonder whether I should have just
used 'Examples' everywhere.
Change-Id: Idbfc3354b52cf1da677db51f4c626bb3269465b8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/215983
Commit-Queue: Kathy Walrath <kathyw@google.com>
Reviewed-by: Kathy Walrath <kathyw@google.com>
Previously, `pkg/analyzer/test/verify_diagnostics_test.dart` and
`pkg/analyzer/tool/diagnostics/generate.dart` extracted documentation
from the code of the analyzer error classes. However, since this code
is generated from `messages.yaml`, it's much cleaner to just extract
the documentation directly from the YAML.
Change-Id: I7dc3eb73abbf5d72f203abbf04e43856b60d2a89
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/215648
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Previously this logic was duplicated in two separate locations,
`verify_diagnostics_test.dart` and the code generator for
`diagnostics.md`. Unifying it will pave the way for a follow-up CL in
which I intend to parse the documentation directly from the
`messages.yaml` files (rather than from comments in the analyzer
classes that are generated from those files).
I've also taken this opportunity to add some more checks to the
parsing logic, so that mistakes in the documentation (e.g. misspelling
a section header) will be reported as errors rather than causing a
silent loss of functionality.
Change-Id: Icfcb52229eb94bb06bc57334e265ef4d6db299de
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/215580
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
For errors that are shared between the front end and the analyzer, we
move the `documentation` and `comment` fields from
`pkg/analyzer/messages.yaml` to `pkg/front_end/messages.yaml` (where
the rest of the information about the error is). This eliminates the
need to have any entries at all for these shared errors in the
`pkg/analyzer/messages.yaml` file, so we no longer need the boolean
flag `copyFromCfe` in this file.
This simplifies generation of analyzer error codes, so we go ahead and
take this opportuntity to remove the old `syntactic_errors.g.dart`
file, and instead code generate all the shared messages directly into
`syntactic_errors.analyzer.g.dart`.
In a follow-up CL I'll rename `syntactic_errors.analyzer.g.dart` back
to `syntactic_errors.g.dart` to reduce confusion.
Change-Id: I1e314e51c94ef595d9d6de8ba2b30e12a18382a8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/215155
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The tool `pkg/analyzer/tool/diagnostics/generate.dart` is very
particular about the format of documentation it recognizes. This CL
corrects a few minor inconsistencies that were causing it to miss some
documentation.
Change-Id: Iac937666426e987d597323e314f60971c15371be
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/214421
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Previously, if a CFE error contained a placeholder (such as
`#string`), that wasn't converted to the equivalent analyzer
placeholder, which meant that analyzer error reporting logic needed to
know whether the error being reported came from the CFE or the
analyzer in order to report the error correctly, otherwise the
placeholder text would just show up verbatim in the analyzer output.
Change-Id: If875de3a1a80048700b0edf458377c5fc87a15d0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213281
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This error message was previously reported by the analyzer's parser,
which presumably supplied an argument describing the modifier. It is
now reported by the shared parser, which doesn't supply any additional
information. As a result, the error message was showing up for the
user as "The modifier '{0}' can't be applied to the body of a setter."
(with a literal `{0}` visible to the user).
Changed the error message text to match what the CFE reports. There's
no real need for the message to describe the modifier since the error
message location is the modifier itself.
Change-Id: I538d49c1b693fe6cfb190f584bb5c9ab5cd3cf39
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213732
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Parker Lougheed