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>
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>
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>
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>
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>
A redirecting factory is normally encoded as something like
```
static factory •({required self::HelperClass bar = #C1}) → self::Bar
return new self::Foo::•(bar: bar);
```
which the CFE also expects to recreate its internal state when loading
a dill file.
The Finalizable transformation from FFI can change that to something
like:
```
static factory •({required self::HelperClass bar = #C1}) → self::Bar {
return block {
final synthesized self::Foo :expressionValueWrappedFinalizable = new self::Foo::•(bar: bar);
_in::reachabilityFence(bar);
} =>:expressionValueWrappedFinalizable;
}
```
though, which the CFE doesn't understand and subsequently crashes as
in https://github.com/flutter/flutter/issues/124369
This CL makes the CFE understand this transformed version,
fixing the crash.
TEST=Existing tests; added incremental compiler test.
Change-Id: I5e7a5fc6201e4419e9ec1ca69d5522d5190f1f83
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/294761
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This includes introspection support, support for annotating and executing macros targeted at enums and enum entries, and support for creating library augmentations of enums with proper syntax (including enum entries).
I also refactored some of the Class support to be more general so we can share interfaces where appropriate.
Change-Id: Ie9111ff280405496e55e32478a19c104341aee37
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/294100
Commit-Queue: Jake Macdonald <jakemac@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
This handles Never, and as a consequence, empty sealed types in
exhaustiveness. Since these contain no value, we should not try to
exhaust them. This avoid invalid non-exhaustive errors in these cases.
Included is handling of a scrutinee with invalid type as Never in the
CFE, thus avoid cascading non-exhaustive or unreachable errors.
Change-Id: Ife097731bb5399c42bf83f1d77aff773346adfb6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/293682
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
In unsound null safety a throw expression is added as the last case
of switches without default to ensure that `null` doesn't fall through.
A break statement needs to be inserted in the last case if it doesn't
itself terminate.
Closes#51957
Change-Id: Ib63059aa2a00ebf1d7e49941af3b1c8acfc696f4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/293603
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
This updates the message report for non-exhaustive switch statements
and expressions to include the witness in the problem message and
a reduced witness, which doesn't include properties that fully cover the
static type. The message is also split into two messages; one for
switch statements and one for switch expressions, allowing for a
better wording regarding the default/wildcard pattern case.
Change-Id: I17db657ef12ade5d47fa96bf69b8807e33ed5b8c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/293040
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Johnni Winther