In https://dart-review.googlesource.com/c/sdk/+/299400, the parser was
adjusted so that it no longer accepts `when` and `as` as the names for
variable patterns in cases where there is a possible ambiguity
(e.g. `int when` is not accepted as a pattern because `int` is a
legitimate pattern, therefore `when` could introduce a guard
clause). This change further prohibits `when` and `as` from being the
names of variable patterns or identifier patterns even in the case
where there is no ambiguity. This is in line with the discussion at
https://github.com/dart-lang/sdk/issues/52199#issuecomment-1526297771,
and the spec change at
https://github.com/dart-lang/language/pull/3033.
Three new error codes are introduced, to cover the three circumstances
in which `when` or `as` might be used illegally: in a declared
variable pattern, in an assigned variable pattern, or in an identifier
pattern. I've also added analyzer tests to ensure that the parser
recovers from these errors nicely. Unfortunately, nice error recovery
is only feasible in the non-ambiguous cases.
I've also updated the language test expectations in
`tests/language/patterns/version_2_32_changes_error_test.dart` to
reflect the new error messages, and added a few more examples of uses
of `when` and `as` that are still permitted.
Fixes#52260.
Bug: https://github.com/dart-lang/sdk/issues/52260
Change-Id: I229f627aa639659c30b83c74895759207da279f7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/301482
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Currently the `InstanceGet` node result type for for
`Completer<bool>.future` is `Future<bool> Function()`, but it should be
`Future<bool>`.
This causes problems in CL 301020 where we generate temporaries for
nested `await` expressions and use the expression type for the types of
those temporaries. Incorrect expression type in `completer.future`
causes a temporary with incorrect type to be generated.
Change-Id: Ib8193c66afee9454a275c00fb958c11fd35cd3eb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/301382
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
When compiling `compile.dart` 74054 non-const scopes are created;
~78% have empty locals and ~99% have empty setters.
This CL creates the maps lazily instead, thus potentially saving ~130k
map creations (and possibly an unknown number of lookups in empty maps
etc).
In measurements (on AOT when compiling `compile.dart`) this has resulted
in changes in runtime ranging from -1.81601% +/- 1.39701% to
-4.60653% +/- 1.68463%, the latest run gave this:
Difference at 95.0% confidence
-0.151 +/- 0.0557737
-3.90231% +/- 1.44137%
(Student's t, pooled s = 0.0871402)
Change-Id: Ic65eeca253dccb871585c221798b59852de80616
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/301064
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This moves the implementation of BodyBuilderContext into the subclasses
where the methods are supported. Additionally a
BodyBuilderDeclarationContext for the implementation based on the
(enclosing) declaration/class builder.
Change-Id: I5084e87ae0c0882db94e4021971d86f8a149daa4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/301360
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
This adds individual [BodyBuilderContext] classes for the different
contexts and passes these at the root of the BodyBuilder creation.
Currently these are simple subtypes [BodyBuilderContext] but the plan
is to move implementation into the subclasses where the functionality
is actually supported.
Change-Id: I8ea22c5f563d9fa539cbd17ed02c919647a1aecd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/301000
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
This reverts commit 4919729f00.
This CL also adds back in logic to handle older package:js versions to avoid
failures in our static checking. It also supports dart:js_interop's @JS
annotation since it can now be used for @staticInterop classes.
CoreLibraryReviewExempt: Reland of backend-specific library changes.
Change-Id: I104653a9a6b2593f6bab658808287e2074c18550
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/294130
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
This change fixes parsing of case clauses such as:
case foo when !flag:
Constructions like this require some lookahead in order to parse
correctly, because the token `when` is valid both as an identifier and
as a part of the grammar for a case clause. Therefore, at the time
`foo` is encountered, the parser must decide whether it is looking at
a variable pattern (`foo when`, where `when` is the name of the
variable) or an identifier pattern (`foo`, where `when` begins the
case's guard clause). Previous to this fix, the algorithm for
disambiguating these two choices was as follows:
- If the token sequence starting at `foo` looked like a type, and the
token that follows was an identifier, the parser assumed it was
looking at a variable pattern with a type; otherwise it assumed it
was looking at an identifier pattern.
- EXCEPT that if the token that followed the supposed type was `when`
or `as` (both of which are valid identifiers), then it probed
further:
- If the token that followed `when` or `as` was a token that could
legitimately follow a pattern, then it assumed that it was looking
at a variable pattern with a type. (The tokens that could
legitimately follow a pattern are `,`, `:`, `||`, `&&`, `)`, `}`,
`]`, `as`, `when`, `?`, `!`).
- Otherwise it assumed that it was looking at an identifier pattern.
This didn't fully disambiguate, because the third bullet didn't
account for the fact that the tokens `as`, `when`, and `!` could
_either_ legitimately follow a pattern _or_ legitimately begin an
expression (or, in the case of `when`, a type), therefore constructs
like the following were incorrectly parsed:
- `case foo when as:` (where `as` is a local boolean variable)
- `case foo when when:` (where `when` is a local boolean variable)
- `case foo when !flag:` (where `flag` is a local boolean variable)
- `case foo as when:` (where `when` is the name of a type)
The solution is to simplify the disambiguation logic so that if if the
token that follows the supposed type is `when` or `as`, then the
parser assumes that it's looking at an identifier pattern, _not_ a
typed variable pattern.
The consequence of this is that the above four constructions are
parsed correctly; however it is no longer possible for a typed
variable pattern to name a variable `when` or `as`.
For consistency we would like to prohibit _any_ variable pattern from
naming a variable `when` or `as`, however to keep this change as small
as possible (and reduce the risk involved in a possible cherry-pick)
that will be postponed until a later CL.
Fixes#52199.
Bug: https://github.com/dart-lang/sdk/issues/52199
Change-Id: Ibab9b92f01e3e4020d7d64f1ff000a9b964a4564
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/299400
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
If enum values have used defined fields that use fromEnvironment constants
the enum values themselves are seen as unevaluated constants when
compiling with dart2js. This means that the enum value are not recognized
correctly in exhaustiveness checking.
This CL changes the enum value representation of the CFE to use the
enum class and the name of the enum element, derived either from the
instance constant or the unevaluated constant expression.
Change-Id: I7d5791a41349dacd20b588f5dbfca37d8755ef79
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/299100
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
This allows void typed switch expressions by allowed void typed
expressions in all subexpressions inferred through the shared type
analysis.
This might lead to allowing void in intended places but the current
approach employed by the CFE doesn't really scale so we need to revisit
it anyway.
In response to https://github.com/dart-lang/sdk/issues/52191
Change-Id: Iee53670d3c316764cfc1309dc76cf37bb3b03629
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/299020
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
When compiling "compile.dart" the type given to computeNonNull
is already non-nullable in ~42% of the cases, meaning it spends
time not doing anything.
Change-Id: I94598efceb3b46f0ac81ec36814c216d01a9e38b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/298823
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This adds a BodyBuilderContext to separate the BodyBuilder from its
[member], [declarationBuilder] and [sourceClassBuilder] fields. The
latter two are fully removes and trivial uses of [member] have been
removed.
This is a step towards a more clean implementation of inline class
members. The plan is to have the members create their own
BodyBuilderContext to use in the BodyBuilder which should the be
agnostic about the builders of its context.
Change-Id: Ic3b29693dd26aa8c57a9ac175b4a07ce4b0a15d7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/298860
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
InstanceAccessTarget calls "base.getGetterTypeForMemberTarget" a lot;
this CL caches the result which is almost always a new FunctionType,
thus creating fewer FunctionTypes.
When compiling compile.dart ~29% fewer:
Before this CL, compiling compile.dart created a little over 217k
FunctionTypes (down in a previous CL from almost 263k); with this CL
"only" ~153.5k FunctionTypes are created.
Change-Id: Ib110ed5e0d152a3b86044f20dc50f0924a083f46
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/298601
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
For instance running like this:
out/ReleaseX64/dart pkg/front_end/tool/flame/instrumenter.dart pkg/front_end/tool/_fasta/compile.dart --count
out/ReleaseX64/dart pkg/front_end/tool/_fasta/compile.dart.dill.instrumented.dill --omit-platform pkg/front_end/tool/_fasta/compile.dart
will now also print how often Constructors are executed, e.g. it contains
stuff like thid:
529,397: ast.dart|DartType.constructor:
715,197: ast.dart|Expression.constructor:
1,177,700: ast.dart|TreeNode.constructor:
2,001,460: ast.dart|Node.constructor:
Change-Id: I26ff69f8ad8a1453d6004e97952ce3b39bfff687
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/298540
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Previously this step happened during `buildOutlineNodes`, but since
`buildOutlineNodes` happens in source order, this means that anonymous
mixins would only get their sealed and final attributes properly
inferred if they appeared *after* their immediate supertypes in source
order. By moving this step to `checkSupertypes`, we ensure that the
computation is correct regardless of source order, because
`checkSupertypes` happens in class hierarchy order.
Fixes#52048.
Bug: https://github.com/dart-lang/sdk/issues/52048
Change-Id: Ib9f1f3dafded88681a26f09e4d21dfd44e70dfd3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/297901
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
When instrumenting one can use "--count" to instrument counting method
calls instead of instrumenting to create a flame graph.
From that I can for instance see that `Reference.node` is called 6+ mio
times when compiling compile.dart.
Example run:
out/ReleaseX64/dart pkg/front_end/tool/flame/instrumenter.dart pkg/front_end/tool/_fasta/compile.dart --count
out/ReleaseX64/dart pkg/front_end/tool/_fasta/compile.dart.dill.instrumented.dill pkg/front_end/tool/_fasta/compile.dart
Change-Id: I583f4b53a474c3777bb059ea89d932607b7c23ad
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/298100
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Could for instance be run like this:
out/ReleaseX64/dart pkg/front_end/tool/flame/instrumenter.dart pkg/front_end/tool/_fasta/compile.dart
out/ReleaseX64/dart pkg/front_end/tool/_fasta/compile.dart.dill.instrumented.dill --omit-platform pkg/front_end/tool/_fasta/compile.dart
out/ReleaseX64/dart pkg/front_end/tool/flame/instrumenter.dart pkg/front_end/tool/_fasta/compile.dart --candidates=cfe_compile_trace_candidates.txt
out/ReleaseX64/dart pkg/front_end/tool/_fasta/compile.dart.dill.instrumented.dill --omit-platform pkg/front_end/tool/_fasta/compile.dart
out/ReleaseX64/dart pkg/front_end/tool/flame/instrumenter.dart pkg/front_end/tool/_fasta/compile.dart --candidates=cfe_compile_trace_candidates_subsequent.txt
out/ReleaseX64/dart pkg/front_end/tool/_fasta/compile.dart.dill.instrumented.dill --omit-platform pkg/front_end/tool/_fasta/compile.dart
* The first command compiles and instruments "compile.dart" to record
all procedure calls.
* The second command runs the instrumented compiler on "compile.dart"
(but it could have compiled anything). Because every procedure is
instrumented this will take a lot longer than a usual run.
This produces a trace "cfe_compile_trace.txt" with every call taking
at least 1000 microseconds. This can be displayed via Chromes
about://tracing tool.
It also produces a file "cfe_compile_trace_candidates.txt" with a map
of the procedures that on average took at least 500 microseconds.
* The third command compiles and instruments "compile.dart", this time
only instrumenting the procedures mentioned in the map
"cfe_compile_trace_candidates.txt".
* The forth command runs the instrumented compiler on "compile.dart".
This run shouldn't take significantly longer than a non-instrumented
run. It produces a new "cfe_compile_trace.txt" which this time is
not filtered. It also produces a file
"cfe_compile_trace_candidates_subsequent.txt" of recorded procedures
that on average took at least 50 microseconds.
* The fifth and sixth commands repeats the third and forth but
instrumenting only the procedures mention in
"cfe_compile_trace_candidates_subsequent.txt".
The third iteration might not be needed, but if the first run was on a
smaller input (which it isn't in this example) there might be some calls
that on average took long enough to be included in the candidate list
because the first call was slow and there were only very few of them,
making the second trace very big because there are now a lot of - as it
turns out - very quick calls recorded. Adding the third iteration will
filter (at least some of) those out.
Change-Id: I702c5c9142e525502b02f37744fcdc9d2b0f9b20
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/296902
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This CL adds more benchmarking points, specifically giving more insight
into where body_buildBodies time goes.
It furthermore changes how overlapping subdivides are handled.
Previously only the first subdivide was actually recorded, meaning that
if a subdivide `a` contained a subdivide `b` only subdivide `a` would
have any time recorded for it. Now instead subdivide `b` will get data
recorded for the time it runs; this time will then _not_ be added to
`a`s total. For instance if subdivide `a` spends one second, then
(while still being in subdivide `a`) we enter subdivide `b` and spend
one second there, exit it, and spend yet another second before we exit
subdivide `a` before we would just have recorded 3 seconds for subdivide
`a`, now we will instead record 2 seconds for subdivide `a` and 1 second
for subdivide `b`.
Additionally a "system subdivide" is automatically added summarizing
any unaccounted for subdivide time, and an extra entry describing the
estimated subdivide recording overhead figues too.
As an additional note, enabling benchmarking seems to add ~6-7% runtime,
and because we specifically add additional parsing phases to measure
that separately the token stream can change before doing the actual
parsing, meaning that when enabling benchmarking some errors might be
swallowed.
Change-Id: I07ef42657c385031e8bb8680738442cf04fe2263
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/295540
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This CL replaces https://dart-review.googlesource.com/c/sdk/+/296900
The `List` constructor is removed in Dart 3.0.
Some of the `@patch` implementations were not removed.
This is *high priority*. It seems the left-over `@patch factory List` constructor did not cause any errors, instead it *added* a constructor to `List` that can be used in web compiled code. Even if `List` doesn't have such a constructor in the SDK code proper.
The VM and analyzer will say the invocation is an error, but dart2js happily compiles it and runs.
(It used to be that patches couldn't add public members, that security seems to have been removed.)
Also removes code which tries to detect "the unnamed List constructor",
which is no longer a thing, and a number of invocations of the constructor, where it's not clear that the test is aware that the constructor no longer exists, and is not marked as `@dart=2.x` with x < 12.
TEST=ci
Change-Id: I4ffaf3ae2c4e75ca06e7ba0bf19187b6376f3888
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/297100
Reviewed-by: Brian Quinlan <bquinlan@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
In order for an analyzer quick fix to aid the user in correcting
exhaustiveness errors, it needs to know not just the text of the
witness pattern that needs to be inserted, but also which elements are
referenced by the identifiers in that pattern. This will allow it to
add in imports if the user's code doesn't yet import the necessary
library, or insert import prefixes in the case where the user is
already importing the necessary library in a prefixed fashion.
To reduce the effect on the exhaustiveness logic (which was designed
with the intention of building up the witness pattern into a
StringBuffer), we introduce a new type, `DartTemplateBuffer`, which
behaves similarly to StringBuffer but also captures the necessary
semantic information so that the analyzer will be able to fix up
imports in an appropriate way.
This change is mostly isolated to the _fe_analyzer_shared package; it
doesn't add the necessary logic to the analyzer to capture the
elements; it simply plumbs them up to the API boundary between the
packages. Future CLs will add the necessary analyzer logic to make
use of the information.
Change-Id: I7c030fc49a2510acbefd6aeb567e0e7b7102855a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/296385
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Johnni Winther