I recently introduced this deletion logic but was deleting the wrong
file; this was deleting the `plugin.dart` file that `plugin.aot` is
compiled from. Over the weekend I found this issue with manual testing.
I've also verified this fix with manual testing.
Change-Id: I3f570368068117e6bb952ada0707a09ee97b765c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/506320
Auto-Submit: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This prevents a null exception that could otherwise occur during code
completion. I think that this only impacts internal users.
It's not ideal. As you can see from the tests OpType is deciding that
we should be suggesting type names in places where they can't exist,
but I think that's a theoretic issue because I believe that the code
completion code won't access the OpType in these situations.
If I'm wrong, then the failure mode will be to suggest type names
that shouldn't be suggested in a couple of situations. If users do
notice this behavior it should be relatively easy to tighted up the
computation to only suggest the valid completions.
Change-Id: I6ceb9615384371f9dcc4fd30d914c7574ed6e304
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/506340
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Extension type augmentations do not have representation declarations, so
an `ExtensionTypeDeclaration` can no longer always expose its name
through a primary constructor. Add `ExtensionTypeDeclaration.namePart`
as the canonical API for the declared name and type parameters, and keep
`primaryConstructor` as a deprecated compatibility API for introductory
declarations.
Report `extensionTypeAugmentationHasRepresentation` when an augmentation
writes representation syntax. This keeps the parser recovery explicit:
the augmentation still gets a plain `namePart`, while the invalid
representation is diagnosed instead of being modeled as the
declaration's primary constructor.
Synthesize recovery representation and primary constructor fragments
only for the element model when an extension type has no introductory
declaration.
Migrate analyzer, analysis server, analyzer plugin, and linter clients
to read extension type names and type parameters from `namePart`.
Change-Id: I59dd957ac38f087c861b993caf246986dcdac713
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/505067
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
If the version is unchanged, don't write to the file. Ninja will notice the modification time is unchanged and avoid rebuilding the target's dependents.
In particular, this means merely adding or amending a commit will no longer make the VM and all SDK snapshots dirty.
Change-Id: I25617c6c584d1d1094a339fe14716d18b28c688f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/506101
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
When the unoptimized code of a function exceeds 1 MB, start its
optimized compile with far_branch_level=1 instead of 0. Without this,
the assembler fails on out-of-range conditional branches at level=0,
longjmps out of the optimizing pipeline, and the whole pipeline reruns
at level=1 from scratch.
Measured on a naive 49 KLOC generated lexer with --huge_method_cutoff
gates lifted: JIT compile drops from ~26.6s to ~13.2s (about 50%).
Work towards https://github.com/dart-lang/sdk/issues/63230
TEST=ci
Change-Id: I2608a23ef899603a46b401b71be7322b7a8dd44b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/506120
Auto-Submit: Modestas Valauskas <valauskasmodestas@gmail.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
Add a syntactic diagnostic for extension type augmentations that declare
representation fields. Extension type augmentations may augment the
declaration, but they must not redeclare the representation.
Thread an explicit parser option through primary constructor parsing so
extension type augmentations can omit a representation without producing
the usual missing-primary-constructor diagnostics, while still reporting
an error when a representation is present.
Register the new diagnostic in the shared and analyzer generated
diagnostic tables and add it to fix status tracking.
Change-Id: I84815bb0669a76126564e590760e93096a3af046
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/505860
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
SLSA-Policy-Verified: SLSA Policy Verification Service <devtools-gerritcodereview-exitgate@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Fixes#63418
When IOOverrides are active, `fseGetType` and `fseGetTypeSync` used
`utf8.encode(path)` which does not null-terminate the path. Native
APIs require null-terminated paths. Through luck the sync path worked
but the async path failed with `notFound`.
Update them to use `FileSystemEntity._toUtf8Array(path)` which correctly
null-terminates the path.
Tested: added a regression test to tests/standalone/io/io_override_test.dart
TAG=agy
CONV=ab6af504-d536-4a8d-88be-bc487b60e24d
R=bkonyi@google.com
CoreLibraryReviewExempt: No API changes.
Change-Id: I24e31efdcbecc703800b96a144e41a095a445cff
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/505201
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Nate Bosch <nbosch@google.com>
Auto-Submit: Nate Bosch <nbosch@google.com>
The element matcher threw a null check exception when getting a matcher
in the argument list of a constructor redirect in a secondary
constructor declaration with no explicit type name. This fixes it so
that no exception will be thrown.
That said, it isn't clear to me that this code could ever be reached
outside of the tests. There might be a lot of unreachable code in
ElementMatcher. I just can't prove that this particular bug would never
have occurred.
Change-Id: I5adf9ab5d4f79686110099054902a28535483f4d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/505921
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Stop storing the most recently resolved unit in ResolutionTest. Make
test helpers operate on explicit result objects instead, so each
assertion uses the diagnostics, type provider, type system, and
inheritance manager from the result it is checking.
This makes the tests less order-dependent and easier to reason about. A
test can now resolve more than one file or unit without later assertions
implicitly depending on whichever result happened to be stored last. It
also makes helper APIs more local: the data needed by an assertion is
passed directly, rather than recovered from mutable test state.
Update tests to keep the returned result when they need access to the
resolved AST or result-derived utilities. Add convenience accessors on
the result wrappers to preserve common lookup patterns without
reintroducing shared mutable state.
Change-Id: Ib45c52f8fd104b668f9fdd1ec6b1442927cd7e61
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/505920
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
This CL is to resolve a TODO. I couldn't find a way to trigger any bugs
in the code, but I did add a test. I believe that the reason I couldn't
trigger a bug is because any constructor that has a null `typeName`
will not have a simple identifier in a place that would allow
`_isConstructorDeclarationReturnType` to be invoked.
I realized, while looking at the code, that the type check is
unnecessary. If the type name is null, then the test will somply return
`false`, which is what we'd expect it to do. Given that it isn't needed,
I decided to remove it.
Change-Id: Ib36aaf16475db0db5817e65a8b8bfbb8aa834dbd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/505501
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This adds some classes for processing interactive forms (I'm splitting this from the CL that updates refactorings to simplify reviewing).
The `InteractiveForm` class managers a whole form (all fields), and processes a set of fields/answers that come back from the client (which may be the full set, or a subset). It produces a list of the outstanding fields (which need to be go back to the client) as well as maintaining the full set of answers for the master field list (to use as arguments for a command, for example).
I've also commented out enums/lists from the protocol code for now, because I made the field kinds `sealed` so we get exhaustiveness checking in the validation, but want to delay fully implementing those for now.
See https://github.com/dart-lang/sdk/issues/63371
Change-Id: Icc4dcea8c9eab20ffbdd19ebbc69e1285464f7ec
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/505683
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Stop exposing common type and element shortcuts from ResolutionTest so
tests use the resolved unit's TypeProvider and library state directly.
This keeps the shared resolution test mixin focused on resolution
utilities instead of duplicating accessors for analyzer internals.
Move the affected flatten coverage out of StaticTypeAnalyzerTest and
into the dedicated built-type tests. This keeps flatten, futureType, and
unionFreeType behavior together in FlattenTypeTest and related test
classes, including coverage for recursive hierarchies and conflicting
Future interfaces.
Update remaining callers to read the library feature set from the
resolved result, and remove assertions that depended on the deleted
ResolutionTest element shortcuts.
Change-Id: I714aec736636500b293b547972a64dc0541172a1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/505500
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
This will avoid some merge conflicts in a follow-up CL I'm working on
that will enable the lints `unnecessary_type_name_in_constructor` and
`unnecessary_const_in_enum_constructor` (and will fix declarations
accordingly).
Change-Id: Ib8be02dc241732a0eb50727618bb2dda6a6a6964
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/505043
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
(Part of https://github.com/dart-lang/sdk/issues/63288)
Updates the `CodeGenerator` mixin so that it outputs `ignore_for_file`
comments to ignore the following lints:
- unnecessary_type_name_in_constructor
- unnecessary_ignore
- duplicate_ignore
This mixin is used by the code generators that produce the Dart
wrappers for the analysis server and analyzer plugin wire protocols.
This is a first step towards migrating the packages `analysis_server`,
`analysis_server_client`, and `analyzer_plugin` packages to use the
new constructor declaration syntax, since it will allow the
`unnecessary_type_name_in_constructor` lint to be enabled without
breaking generated code.
Once all the packages have had their SDK constraints bumped to a
language version that supports the new syntax, I'll update the code
generator to use the new syntax, and remove the ignores.
For more information about the new constructor declaration syntax, see
https://github.com/dart-lang/language/blob/main/accepted/future-releases/primary-constructors/feature-specification.md#abbreviations-of-in-body-constructor-declarations.
Change-Id: Ied17e3ea772546675aad48efc324f6f16a6a6964
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/505521
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
This fixes an exeception when code completing before the `new` or
`factory` keyword in a constructor and the type name is not explicitly
used. The exception prevents any suggestions from being returned, so
it's fairly serious.
Change-Id: I2f5028812ee1945ac9635f55953fb800b19a48c5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/505620
Auto-Submit: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
We still have `late ResolvedUnitResultImpl result` for now, but many
tests migrated to explicit `TestResolvedUnitResult` and its getters.
Start migrating analyzer resolution tests away from the implicit
ResolutionTest state. Store the TestResolvedUnitResult returned by
resolve helpers in local variables, then read nodes and elements through
that result.
Update helper methods to take the resolved result explicitly when they
need access to findNode or findElement. Also return resolved results
from small wrapper helpers so their callers do not have to depend on
shared state.
This keeps each test tied to the unit it resolved and prepares the test
harness for removing the remaining stored resolution result.
Change-Id: I5e9331fb574d962473e5d36922107f674d7340cc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/505621
SLSA-Policy-Verified: SLSA Policy Verification Service <devtools-gerritcodereview-exitgate@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
This will avoid some merge conflicts in a follow-up CL I'm working on
that will enable the lints `unnecessary_type_name_in_constructor` and
`unnecessary_const_in_enum_constructor` (and will fix declarations
accordingly).
Change-Id: I0a8f660c3c4d722dbeda440009e565f96a6a6964
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/505047
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The tests in `tests/standalone/package/` don't use the top level
`package_config.json` file; they use their own internal file, which
apparently hasn't been updated recently. This change bumps the version
of `package:expect` in that file to version 3.13, which will allow
`package:expect` to start using Dart language 3.13 features without
breaking tests.
Change-Id: Ia2975d540aa503e8f69944e0e1c275c56a6a6964
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/505580
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Stacks on top of the int.{trailingZeroBitCount,oneBitCount} API CL
(commit 754239b077). Both getters route through OTHER_RECOGNIZED_LIST
when a hardware fast path is available; otherwise the newly added
Dart bodies inline at call sites via vm:prefer-inline. The C++
natives are removed.
Backend codegen
---------------
ARM64: NEON CNT + UADDLV (popcount); RBIT + CLZ (ctz).
ARM: NEON CNT + VPADDL chain (popcount); RBIT + CLZ on the
register pair (ctz).
x64: popcntq when TargetCPUFeatures::popcnt_supported();
LoadImmediate(64) + rep_bsfq for ctz (decodes as tzcnt
on BMI1+, preserves dest on zero otherwise).
RISC-V 64: cpop / ctz when RV_baseline includes Zbb.
Per-arch availability is encapsulated in
UnaryInt64OpInstr::IsSupported(Token::Kind).
Apple M-series ARM64, AOT (us/iter, lower is better):
cardinality.swar 371
cardinality.accelerated 154 (2.4x)
forEachSetBit.swar 19031
forEachSetBit.accelerated 4988 (3.8x)
select.swar 199
select.accelerated 77 (2.6x)
complementCardinality.swar 399
complementCardinality.accel 152 (2.6x)
Work towards https://github.com/dart-lang/sdk/issues/6486 (popcount
and ctz intrinsification).
Work towards https://github.com/dart-lang/sdk/issues/1053 (efficient
BitSet implementation).
Fixes https://github.com/dart-lang/sdk/issues/52673
Fixes https://github.com/dart-lang/sdk/issues/38346
Issue https://github.com/dart-lang/sdk/issues/10212
Issue https://github.com/dart-lang/sdk/issues/5798
TEST=tests/corelib/int_bit_count_test
Cq-Include-Trybots: luci.dart.try:vm-aot-linux-release-simarm_x64-try,vm-aot-linux-debug-simarm_x64-try,dart-sdk-linux-riscv64-try
Change-Id: I9c2c4225fd63d54e190398a0fb6649366317dd17
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/504221
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Auto-Submit: Modestas Valauskas <valauskasmodestas@gmail.com>
Some features in `dart:_wasm` are relevant for all WebAssembly targets
(like interop types or memory intrinsics). Others, in particular the
helper methods to convert between `WasmExternRef` and `JSAny`, don't
make sense for the standalone target.
To be able to remove the `js_interop` library from the standalone
target, we need to stop importing it from `dart:_wasm`. To prepare that
step, this moves the helpers to a new library (`dart:_js_interop_wasm`)
and re-exports them from `dart:_wasm`.
Once Flutter has migrated to the new import, the export can be removed.
Bug: https://github.com/dart-lang/sdk/issues/63166
Change-Id: I13fe875e509a13d16c48d420a5927d3130b90736
Cq-Include-Trybots: luci.dart.try:flutter-analyze-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/505080
Reviewed-by: Martin Kustermann <kustermann@google.com>
Auto-Submit: Simon Binder <oss@simonbinder.eu>
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
Generalize DefinitionWorklist into a Worklist<T, E> template and use a
new BlockEntryWorklist (keyed by preorder_number) to drive the WBE
dataflow. The bitvector-backed membership set prevents the same block
from being enqueued many times, which is what caused compile time to
blow up on large generated programs.
Measured on a naive 49 KLOC generated lexer with --huge_method_cutoff
gates lifted and with synchronous compilation: AOT compile drops from
~42s to ~19s.
Work towards https://github.com/dart-lang/sdk/issues/63230
Fixes https://github.com/dart-lang/sdk/issues/63426
TEST=ci
Change-Id: I56c5dc40f534e4b28fe6b608a3b7f49e14957ef7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/505461
Commit-Queue: Martin Kustermann <kustermann@google.com>
Auto-Submit: Modestas Valauskas <valauskasmodestas@gmail.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Ryan Macnak