This separates VariableDeclaration from Statement. VariableDeclaration no longer implements Statement and variable declared in a block or in a for-statement are now wrapped by a VariableStatement.
Currently there are two VariableStatement implementations; LegacyVariableStatement for variables in the current model, called LegacyVariable, and VariableInitialization for variables used in the new, still experimental, encoding that supports scope computation.
This CL is a step towards realigning the AST nodes to the new model in which each kind of variable has its own distinct subclass. (LocalVariable, PositionalParameter, NamedParameter, SyntheticVariable, etc.)
Note that it is not the intent to use VariableStatement in ForStatement going forward but that will be handled in a follow-up.
TEST=existing.
Change-Id: I5b309cd62c9b138f95b74fb054686edffa49a393
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/502681
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Adds a benchmark exercising int.oneBitCount and int.trailingZeroBitCount
(landed in CL 498041) and a representative set of Int32x4 SIMD bitwise
kernels, through a small bit-array implementation built on a Uint32List
word store.
Kernels:
- cardinality: popcount across the array.
- forEachSetBit: Brian-Kernighan iteration via ctz.
- select(k): position of the k-th set bit using popcount + ctz.
- complementCardinality: popcount of bitwise-NOT per word.
- totalBitLength: sum of int.bitLength per word.
- intersection / union / xor / difference: pair-op bitwise kernels using
Int32x4 SIMD with a scalar tail.
- complement: single-input bitwise NOT via Int32x4 XOR-with-all-ones.
Each kernel has a Swar baseline using portable bit-twiddle code and an
Accelerated variant that uses the new int getters or Int32x4 SIMD, so
the speedup attributable to the hardware/intrinsic path is visible
directly. main() first runs a correctness check that asserts both
implementations agree across a representative range of sizes and bit
densities, then reports timings via the standard BenchmarkBase harness.
Work towards https://github.com/dart-lang/sdk/issues/1053 (efficient
BitSet implementation).
Bug: https://github.com/dart-lang/sdk/issues/52673
Change-Id: I5ae5bc0b9d07f6de3e11907ac1fae80f02e77119
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/503020
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Auto-Submit: Modestas Valauskas <valauskasmodestas@gmail.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Treat field fragments marked as augmentations like other augmented
members when collecting local member names. Do not add their getter and
setter fragments to the instance or static duplicate scopes, because
they augment existing declarations rather than introduce new local
members.
This avoids secondary duplicateDefinition and conflicting member
diagnostics when a field augmentation targets an existing declaration.
Non-augmenting declarations in augmentation blocks are still checked as
new declarations, so real duplicates continue to be reported.
We don't have yet checks for completed getter / setter from fields and
variables, so tests miss several errors.
Change-Id: I6901aea1770891917c966c11b59cb647aaf4ed86
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/503840
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
This will allow use of Dart 3.13 features (such as primary
constructors) within the SDK itself.
Note that some generated files required benign updates due to
formatter behavior changes.
Change-Id: I595554e9cff3dbaa3f11da407d6c26036a6a6964
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/503662
Auto-Submit: Paul Berry <paulberry@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Report new diagnostics when an introductory function, member, or factory
constructor is still incomplete after applying all augmentations.
Keep the existing missing-body diagnostics for declarations that have no
augmentations, but report augmentation-specific diagnostics when an
augmentation chain exists and none of the fragments provides a body or
factory redirection.
Move the checks into error verification so that extension and extension
type members can participate in augmentation completion before reporting
the existing abstract-member diagnostics. Also suppress the
corresponding shared parser diagnostic when it is reported by the
verifier.
Consolidate body-related tests by declaration shape instead of by
individual diagnostic. This keeps missing bodies, external bodies,
augmentation completion, and already-complete checks side by side,
making the interaction between these rules easier to review and extend.
Move the constructorAlreadyComplete coverage from its dedicated test
file into constructor_body_test.dart, and add the factory body
completeness cases there as well. Add executable_body_test.dart for
function and member body coverage, including top-level declarations,
static members, extension members, and extension type members.
Add diagnostic definitions and fix-status entries for the new
diagnostics.
Change-Id: I9ee803c1e767ff47a608c86413ef7ffc71518cfd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/503540
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Teach the analysis index and referenced-name computation to recognize
`// [diag.foo]` expectation comments embedded in string literals in
analyzer tests. Resolve `foo` through the analyzer diagnostic library
and record it as a qualified reference to the diagnostic variable.
This lets reference search find diagnostics that are used only in test
expectation strings, when developing analyzer itself.
Change-Id: I91fa020ccd2cfe49fa6e890c8f6796a5b8ca4d1f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/503663
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
The correction producer implements a fix. Pending discussion we might
choose to extend it to produce an assist, either in addition to the fix
(if we keep the lint) or instead of a fix (if we drop the lint).
Whatever we choose, I'd like to do that in a separate CL because I want
this to be available for testing purposes as soon as possible.
Change-Id: Icdd17ba0130149fc785c196be69e9ef990529800
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/503520
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
I'm honestly unsure why this is not reported by my IDE, or CI. But it
is reported internally in Google. I'm sure it has to do with the SDK
starting to add some extension methods in the core libs, which were
previously only available in package:collection. But this is still safe,
as analyzer's minimum SDK is Dart 3.11.0.
Change-Id: Ibbb0078e463df03b31749296e1d2f474afb183ec
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/503582
Auto-Submit: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Fixes https://github.com/dart-lang/sdk/issues/62649
This change overhauls what the PluginServer does when it receives requests from DAS like watch events, overlay changes, setting context roots, and setting priority files, to use the AnalysisDriver APIs. These APIs provide a much smarter, more fine-grained mechanism for determining which files need to be re-analyzed.
This requires a lot of changes that really don't seem obvious (or just,
to me, they are not intuitive), because they relate to Streams being
processed, drained, read, etc. So I'll summarize as much as I can:
* In order to track that results coming from AnalysisDriver are
definitely for the same AnalysisSession we are concerned with, at
any given time, we add `_filesBeingAnalyzed` and
`_filesBeingResolved`. These two maps are cleared any time the plugin
isolate is notified of changes, so there is not a memory concern.
* We add a `waitForIdle` method which is just used by tests
occasionally, in order to ensure analysis is complete.
* We tackle a related bug mentioned in the issue thread regarding
adding or removing overlays without changing the source contents.
There are now a few checks that old-content is not equal to
new-content.
* Due to the more async nature of reading events off of the analysis
driver, we have to be more particular in tests about sending
`AnalysisSetContextRootsParams` and reading from the notification
stream, so there are a lot of changes in tests to re-position these
calls.
This results in massive savings in re-analysis time. Using the example in https://github.com/dart-lang/sdk/issues/62649, typing in the
`build_runner/lib/src/logging/build_log_logger.dart` file, I see the
following:
* Before this fix, every keystroke results in 183 files being
re-analyzed by the plugin (always 183).
* After this fix:
* keystrokes that do not result in a summary change (or maybe
fine-grained deps analysis), like whitespace, results in 1 file
being re-analyzed (the file I'm editing).
* A keystroke that results in slightly changed summary, like changing
an import to something invalid, results 2 or 4 files being
re-analyzed.
* A keystroke that changes the name of class BuildLogLogger (large
change to summary) results in 9-10 files being re-analyzed.
Change-Id: Ie35053b0d90457b5b4b53bc8803188def0308d2a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/503040
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
This file is no longer published and has no other value. Removing it
removes one step from the process of writing a new lint, which improves
our velocity.
Change-Id: Ie81b914bfa59aa8ec2c8fb2921eec2e9963bd601
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/503620
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
The session log normalizer replaces known paths/URIs in JSON but doesn't take into account different URI encoding between the client and the server. For example VS Code will encode ampersands whereas Dart does not:
```
file:///c:/uri&encoding&quirks
file:///c:/uri%26encoding%26quirks
```
This means not all file URIs are correctly normalized.
Adding additional groups for each potentially-encoded characters make the regex many times slower (the benchmark test here goes from around 25ms to over 1s per iteration), so instead this change has the normalizer accept the original JSON map and uses jsonEncode()s `toEncodable` option to normalize any URIs (by converting them to their file paths and then encoding using Dart's Uri class) so they will always be consistent before the replacement.
(I tried doing the replacement also in `toEncodable`, but invoking the regex many times also slowed things down a lot).
There is a small time increase (2-3ms) for a payload of 2MB. The "before" times quoted here are slightly higher than previously quoted, but that's because `jsonEncode()` was previously done inside `SessionLoggerFileSink` (and therefore excluded from the timings before), but is now done inside the normalizer to allow normalizing the URI escaping.
Replacing 250 paths in payload of 2097152 bytes
Iteration #1, First: 57ms, Rest: 40ms
Iteration #2, First: 49ms, Rest: 41ms
Iteration #3, First: 45ms, Rest: 41ms
Iteration #4, First: 47ms, Rest: 40ms
Iteration #5, First: 40ms, Rest: 40ms
Replacing 250 paths in payload of 2097152 bytes
Iteration #1, First: 59ms, Rest: 43ms
Iteration #2, First: 53ms, Rest: 44ms
Iteration #3, First: 52ms, Rest: 44ms
Iteration #4, First: 49ms, Rest: 43ms
Iteration #5, First: 49ms, Rest: 43ms
Fixes https://github.com/dart-lang/sdk/issues/63331
Change-Id: Ice2dc7ceceaa6c08e2ff634d7564efe9f0f7de44
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/502940
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Keerti Parthasarathy <keertip@google.com>
This updates the IOHandle type in eventhandler_fuchsia to use
zx_port_cancel_key to cancel outstanding asynchronous waits instead of
the (older) zx_port_cancel. The cancel_key operation requires only the
key used to register the initial wait and not the originating handle.
This means that the IOHandle operation no longer has to store the
original handle or worry about its lifetime.
Tested: Patched locally in a test embedder using this logic
Change-Id: Iec0ec632a7dd438a34e482a12b5b298be56ce476
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/501840
Reviewed-by: Zijie He <zijiehe@google.com>
Auto-Submit: James Robinson <jamesr@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
At this time, this flag is mainly going to be used to enable partial
testing of the JIT runtime when loading applications from kernel
snapshots.
Bug: b/448095881
TEST=none yet, will be added in upcoming CL
Change-Id: I272d43cdab0c9a9c3653cccc9e96961c1122bbd7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/503460
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
This change introduces flags to allow the use of dynamic calls now that
they have their corresponding validation and runtime check. This will
enable us to add end-to-end tests next.
TEST=none yet - will be added in subsequent CL (see CL chain)
Bug: b/448095881
Change-Id: I82448824e94dd940ce5346f79554d34847ecb610
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/498320
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Unlike other calls from Dynamic Modules, dynamic calls cannot be
validated entirely at compile time. While we check that the selector
used matches a selector that was allowed (either because a method with
that selector name was exposed as dynamically callable or because the
selector was allowlisted during bytecode compilation), the compiler
doesn't know statically whether the target of the call is exposed.
In prior changes we modified the annotator to add a pragma indicating
whether a member is dynamically-callable or
implicitly-dynamically-callable. Here we use that information to set a
bit on functions and their corresponding dynamic invocation forwarders,
which is verified by the interpreter to make sure the dynamic call is
still allowed.
TEST=none yet - will be added in subsequent CL (see CL chain)
Bug: b/448095881
Change-Id: I27acb4e690a68e08fe1f1ca94e0d77cc7dc4d11e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/498300
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Auto-Submit: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Adds isSystemIsolate in the isolate startup message sent to the
VM service, allowing for the service to identify the first non-system
isolate as the root isolate.
TEST=Existing tests
CoreLibraryReviewExempt: dart:vmservice is internal.
Change-Id: I0a982a1fc06bd0be0426ad9d1401e89375cbed40
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/500000
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Jessy Yameogo <yjessy@google.com>
Brian Wilkerson