This CL introduces support for anonymous block methods (that is,
`e.{ print(this); }` as opposed to `e.=> print(this);`). It introduces
the notion of a `ReturnContext` which is used to change the semantics
of a return statement when it returns from an anonymous method (where
it works like a `break` that terminates the execution of the block
which is the body of the enclosing anonymous method), but keeps the
semantics of return statements returning from a function (including
function literals) still have the same semantics as today.
Change-Id: I404459361fbb7c2e495e46d1bd29924063f3aac4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/503800
SLSA-Policy-Verified: SLSA Policy Verification Service <devtools-gerritcodereview-exitgate@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
The dart2wasm compiler can use three different SDK platforms depending
on compiler options: The default one, a JS compatibility target and a
standalone target.
Code for these platforms used to be in `_internal/` subdirectories, but
parts of `_internal/wasm/lib` were also used by the other targets.
To make it clearer which patches/internal libraries belong to which
target, this restructures `_internal/wasm` as follows: Files only
relevant for one target are in `js`, `js_compatibility` and
`standalone`. Files used by all targets are in `common`, files used in
the default and the JS compatibility target are in `js_common`.
TEST=Refactor, covered by existing tests
Change-Id: I2c63c04a5fd5ca88cd640889aa295bd1fb8cfc95
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/505441
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
SLSA-Policy-Verified: SLSA Policy Verification Service <devtools-gerritcodereview-exitgate@google.com>
This adds serialization of the new local variables, VariableStatement and VariableDeclaration. This prepares for replacing LegacyVariable with the new variables in all backends.
TEST=existing
Change-Id: I9bbebfbfd372042d6b7027f0fabd24c165699832
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/506240
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This adds a VariableDeclaration node which is used in ForStatement instead of VariableStatement.
This is a step towards removing the initializer from Variable. Long term, VariableDeclaration will own the initializer expression for variables and function parameters will have a defaultValue property instead of using the initializer property for the default value.
TEST=existing
Change-Id: I4a663eeb6006a0f9f098fb2b3e3b502d2ae583b0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/505681
Reviewed-by: Stephen Adams <sra@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
This was done while trying to implement loading additional dill modules
via the incremental compiler, but I believe I've removed all that and
only left the refactoring in this CL.
Change-Id: I047940b5dfe526ddfbc11627a29fc80eb82c3049
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/505260
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
On Mac and Linux, the makes the output of non-RBE, RBE local and RBE remote builds identical, and also independent of the build directories path. On Windows, non-RBE and RBE builds still disagree because paths are rewritten from \ to / to run on the Linux workers.
Bug: b/316893839
Change-Id: I5935785489c73445e4c6ca275020e6cf7464433d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/506281
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
On mac with two WorkSet classes, WorkSet destructor from lib/isolate.cc is invoked instead of WorkSet destructor from vm/object.cc. This results in consistent assertion failures on flutter dart-debug builds on mac.
Might help with https://github.com/flutter/flutter/issues/186134
TEST=flutter test with dart-debug build
Change-Id: I9a0a0c9d02ee013da900807b8726df26a3660cc7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/505661
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
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>
Ryan Macnak