Improved inferrer to handle some cases of JS-fragments.
The JS-fragment to copy the array caused the inferrer to be too
pessimistic about list-tracing into List.of.
Change-Id: I0cb4f7610d971d7927d973bd2b0b532d4cef9a7e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/173883
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
In preparation for some flow anaylsis work I intend to do this month,
I want to make the flow analysis unit tests easier to understand and
maintain. This CL creates an AST representation that models just
enough of the Dart language to be able to do flow analysis testing, so
that when reading or writing a flow analysis unit test, instead of
having to remember the correct sequence of calls to FlowAnalysis to
model a given construct, you can just create a mini-AST representation
of the given construct and pass it to the flow analysis test harness.
The mini-AST model for expressions contains methods that can be used
to build larger expressions out of smaller ones, so a lot of code can
be modeled compactly. For example, to create a mini-AST model of the
statement `x = y && z == null;`, call
`x.write(y.read.and(z.read.eq(nullLiteral()))).stmt`.
Change-Id: I11e3882078fdc5797176019398db48011232cf35
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/174560
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
It started as a way to speed up IgnoreValidator, becaus computing
uniqueName as a concatenation of 'runtimeType' and 'name' was expensive.
We solved it in a better way, but I think this change is still useful.
Change-Id: I7d3cb8c91f4ca27a0aa3b93f8572cf12c6757bae
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/174322
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Since the EdgeBuilder overrides VisitNode, it wasn't getting the
benefit of the error recovery behavior provided by the
PermissiveModeVisitor mixin. This CL replicates some of the
functionality of PermissiveModeVisitor in the EdgeBuilder._dispatch
method so that it applies throughout the EdgeBuilder's visiting
process.
This uncovered a second bug: when an exception is reported, and the
user hasn't passed in the `--ignore-exceptions` flag, the migration
tool tries to exit immediately by throwing an error of type
MigrationExit, but this was being caught by the error recovery logic,
so the tool wouldn't actually stop reliably. This CL changes the
exception reporting code so that it re-throws MigrationExit when
necessary to ensure quick termination.
Change-Id: Ifd2faf8edb7cd0087c45e20a747ab7f1790ef1c2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/174420
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This reverts commit 5370c56c80.
Reason for revert: Failures on
dartk-android-product-arm
dartk-android-product-arm
dartkp-linux-release-arm-qemu
like this:
sizeof(ScriptLayout) got 64, Script_InstanceSize expected 56
../../runtime/vm/dart.cc: 160: error: CheckOffsets failed. Try updating offsets by running ./tools/run_offsets_extractor.sh
sizeof(ScriptLayout) got 64, AOT_Script_InstanceSize expected 56
../../runtime/vm/dart.cc: 160: error: CheckOffsets failed. Try updating offsets by running ./tools/run_offsets_extractor.sh
Original change's description:
> [VM] Read and report constant constructor coverage from dill
>
> This CL makes use of the now included constant constructor coverage
> in the dill file.
>
> It works like this:
> * When the CFE evaluates constants, every constant constructor
> invocation evaluated saves the reference to the constructor in the
> `Source` (from the Components uri to source table) for the callers
> Library.
> * This data is loaded into the VM in a "raw" format.
> * When a request for coverage comes in, the VM - on top of the normal
> coverage processing - goes through all scripts to find constant
> constructor coverage for the requested script and offset. Note that
> all scripts must be checked because library A can have evaluated a
> constructor from library B - so even if only coverage for library B
> was requested, library A has to be checked.
> For all constructors found the start and end position is reported as
> covered. Note that this does not mark any initializes and there are
> (at least currently) no good way of marking which initializes were
> evaluated (because it has to be stable across edits even when the
> `advanced invalidation feature` is enabled).
> * Note that the reason for the coverage to work on references - as
> hinted above - is because we want it to be stable across hot reloads
> even if/when advanced invalidation is enabled. This means, that
> library A cannot record "positional coverage" for library B because
> library B might get (for instance) new comments that will make any old
> offsets invalid. By using references we always lookup in the current
> world and use the correct offsets.
>
> https://github.com/dart-lang/sdk/issues/38934
>
> TEST=Existing test suite, new tests for the new coverage added.
>
> Change-Id: I925963d1a9b9907efe621c72deb7348fa3be5ae8
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/171949
> Commit-Queue: Jens Johansen <jensj@google.com>
> Reviewed-by: Ben Konyi <bkonyi@google.com>
> Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
TBR=vegorov@google.com,bkonyi@google.com,jensj@google.com
Change-Id: I5187e6749d59ded250ec0933a94db0536485b70a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/174470
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This CL makes use of the now included constant constructor coverage
in the dill file.
It works like this:
* When the CFE evaluates constants, every constant constructor
invocation evaluated saves the reference to the constructor in the
`Source` (from the Components uri to source table) for the callers
Library.
* This data is loaded into the VM in a "raw" format.
* When a request for coverage comes in, the VM - on top of the normal
coverage processing - goes through all scripts to find constant
constructor coverage for the requested script and offset. Note that
all scripts must be checked because library A can have evaluated a
constructor from library B - so even if only coverage for library B
was requested, library A has to be checked.
For all constructors found the start and end position is reported as
covered. Note that this does not mark any initializes and there are
(at least currently) no good way of marking which initializes were
evaluated (because it has to be stable across edits even when the
`advanced invalidation feature` is enabled).
* Note that the reason for the coverage to work on references - as
hinted above - is because we want it to be stable across hot reloads
even if/when advanced invalidation is enabled. This means, that
library A cannot record "positional coverage" for library B because
library B might get (for instance) new comments that will make any old
offsets invalid. By using references we always lookup in the current
world and use the correct offsets.
https://github.com/dart-lang/sdk/issues/38934
TEST=Existing test suite, new tests for the new coverage added.
Change-Id: I925963d1a9b9907efe621c72deb7348fa3be5ae8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/171949
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
This adds the recorded constant coverage to the dill file.
runtimes for constant evaluation:
dart2js: No difference proven at 95.0% confidence
flutter gallery: No difference proven at 95.0% confidence
big internal app: No difference proven at 95.0% confidence
sdk sizes:
vm: ~0.0182%
dart2js: ~0.0137%
flutter: ~0.0197%
compile sizes:
dart2js: ~0.0179%
flutter gallery: ~0.0162%
big internal app: ~0.0414%
TEST=test was fixed.
Change-Id: I347751e4d96d4d62140d26ebe37960f46a0dfbfa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/171948
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This is second try of https://dart-review.googlesource.com/c/sdk/+/171284
that was reverted to to faulty logic in main_options.
Some other refactorings are piggy-backed along.
TestProject.runSync no longer takes a 'command' argument. It was anyway
often not an argument.
Also stop the messy handling of pub arguments. It is no longer needed.
BUG: https://github.com/dart-lang/sdk/issues/44135
Change-Id: I49abf5810d9ea262409ba9d93f0471037cb8a753
TEST=The VM change is tested via all the pkg/dartdev/test/command/* tests that invoke dart with the --no-analytics flag.
TEST=Furthermore manual test that the --no-analytics flag is passed to dartdev.
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/174261
Reviewed-by: Jonas Jensen <jonasfj@google.com>
Commit-Queue: Sigurd Meldgaard <sigurdm@google.com>
This CL records which const constructors were evaluated
(i.e. contributes coverage) but doesn't actually
save the coverage into the dill file.
runtimes for constant evaluation:
dart2js: No difference proven at 95.0% confidence
flutter gallery: No difference proven at 95.0% confidence
big internal app: No difference proven at 95.0% confidence
sdk sizes:
vm: no change
dart2js: no change
flutter: no change
compile sizes:
dart2js: no change
flutter gallery: no change
big internal app: no change
Change-Id: I2567446c1b78180d73fd7613bc9e780e1a067f5b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/170435
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
E.g. one can run a benchmark via something like
`out/ReleaseX64/dart pkg/front_end/test/constant_evaluator_benchmark.dart --platform=out/ReleaseX64/vm_platform_strong.dill pkg/compiler/bin/dart2js.dart --target=VM`
Change-Id: Ie9202bbd8a390a461a31625880bbb182f845261e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/168485
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
All existing embedders have been opted into --lazy-async-stacks, the
VM also uses it as it's default in all configurations.
After this CL, any user of --causal-async-stacks will get an error
message when trying to use it.
=> In any such case, please simply remove the flag.
TEST=Exhaustive CQ.
Bug: https://github.com/dart-lang/sdk/issues/37668
Change-Id: Ia440afcf2dba464aa8b8cf381b93bbac8eb9f8dc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/172564
Commit-Queue: Clement Skau <cskau@google.com>
Reviewed-by: Clement Skau <cskau@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This is consistent with what we do for user project.
Null safety is not an experiment anymore.
OTOH, any future experiments should be applied on top of the latest
language version.
Change-Id: I6dcbc954aefefb1f7a03c9ceaf1d25be28e7adf4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/174488
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
This is needed, for example, when renaming an optional named parameter
when a simple 'renameParameter' isn't sufficient. The existing arguments
need to be preserved.
This also removes the 'statements' style of code template because it
wasn't fully supported and isn't currently needed.
Change-Id: I66035c88fcffef77f7de9eedff4efbaf2720ccb1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/174482
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
These tests were passing by a wrong reason.
It is not possible to express a recursive typedef anymore.
When we try to instantiate `G` in `typedef F = G Function()`, it
will instantiate `typdef G = F Function()` right now, directly into
the corresponding FunctionType, but because we are in the process
of setting the return type of `F` right now, `G` is not yet referenced
in `F`, so is not referened by `G` itself.
Such recursion is possible during linking, but then we break it.
We still report errors, and resolved AST still has necessary references.
Change-Id: I47b18f80b00edd01268c65c3e1786892ad0d5091
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/174381
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
- Ensure the lexer is running at the latest language version. Before, it
would fail to handle files that used extension methods since it didn't
tokenize "extension" correctly.
- Don't visit files that produce parse errors. It was reporting the
errors but still going ahead and parsing them... which actually
worked surprisingly well (yay error recovery) but could lead to
dubious results.
Change-Id: I0e94b5c56efaeb3c2ccde0fbf20c09733aac4998
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/174021
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Phil Quitslund <pquitslund@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
This should be slightly more efficient because we read bytes from
the OS file. We need both bytes (to compute hash) and string (as code).
So, it seems silly to read bytes, decode into string, then again
encode into bytes.
Change-Id: I3ee7c7282cf4f72dc32bcf9b8ffe68899a2ca3c7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/174341
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
I saw from 4% to 6% analysis time used by IgnoreValidator constructor.
We did quite a few expensive operations each time, for each file.
Now we will do it once for each bucket.
Change-Id: Ia7c79b777269c9e4c10a9fb9f2864cc7249eacf9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/174230
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Robert Nystrom
