Running DDC + FES in incremental mode was causing FES state machine responses to fail whenever DDC emits an error. These should be captured and reported (and potentially rejected manually).
Change-Id: Ic409dd8986c984b858fec21c6f67bd52147b367d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/384824
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Mark Zhou <markzipan@google.com>
Add a simple implementation that throws out all libraries and runs the
main method again which triggers all libraries to be initialized with
fresh values.
Move the hot reload tests to the ddc canary test configuration
since that is where the support works at this time.
Update frontend server to use the use the new version of the DDC
LibraryCompiler when the emit library bundle option is true.
Change-Id: I6eba613106672536ef8bfcb0ff0a55749e2fb63c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/381902
Reviewed-by: Kevin Moore <kevmoo@google.com>
Reviewed-by: Nate Biggs <natebiggs@google.com>
Reviewed-by: Mark Zhou <markzipan@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This CL primarily adds a lint for fields with `StackTrace.current`
which is often useful for debugging, but shouldn't be left in.
* Add an ast visitor after the "explicit creation test",
finding - for now - `StackTrace.current` calls in fields.
This should have caught the left-in debug such in
https://dart-review.googlesource.com/c/sdk/+/379281.
* Renamed explicit_creation to compile_and_lint
* Remove (for some time) unused "smoke_test_quick" files.
* Add kernel to the compile_and_lint suite, but ignore it for explicit
creation (i.e. kernel will also be checked for fields
with `StackTrace.current`).
Change-Id: Ib886d23a8945e7063dc673a7f99cbb3a6adc1139
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/382361
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
DDC hot reload requires a new module format. This is
represented by the intersection of the DDC module format
and canary. Currently, this test file only tests the AMD
module format by default. This change duplicates all the
existing tests with the AMD format and tests them with the
DDC module format + canary.
Also cleans up a TODO to use named parameters for
compileExpressionToJs.
Change-Id: Ic93a748f6efef9463cb343cb19f243d895dac3b6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/377765
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Dynamic interface annotator now automatically annotates classes and
members which are used implicitly:
* Targets of redirecting factories.
* Classes and members used in constants.
* Instance fields of classes used in instance constants or
having a callable const constructor.
* Everything used in the bodies of extendable mixin declarations and
mixin classes.
* Possible dispatch targets of instance calls
(overrides/implementations).
Front-end server now also exposes '--dynamic-interface' option,
similar to gen_kernel tool.
Also, this change includes a couple of minor fixes:
* Typo in ast.dart.
* In the front-end server, additional dill file specified with
'--import-dill' option is not ignored when '--link-platform' is
also used.
TEST=pkg/vm/testcases/transformations/dynamic_interface_annotator
Change-Id: I705b64efb1834dec6e0bdc5873025607f3472139
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/377761
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
This is a reland of commit d84f908641
Includes fixes:
--- Catch scope fix ---
Each catch block should define its own scope, but the compiler was not treating the body of these catch blocks as a scope. This was leading to incorrect variable renaming.
--- Duplicate label fix ---
Labels weren't being removed from the _labelNames Map after being used so multiple nodes were getting tagged with the same label. Note: This didn't actually cause any bugs because the label closer to the break statements using those labels was the correct one.
--- addAsyncCallback cleanup ---
The new async semantics actually don't require managing addAsyncCallback and removeAsyncCallback calls (proxies for async_helper.asyncStart and async_helper.asyncEnd). None of the other backends manage these themselves. It's up to tests to ensure they call async_helper.asyncStart and async_helper.asyncEnd.
Original change's description:
> [ddc] Update DDC compiler to start using the new async transform.
>
> Updates compiler.dart to use the new async transformation.
>
> Some key things to note:
> - Dart Let and BlockExpression expressions are represented as IIFEs in DDC compiled code. For non-async code this works fine but this doesn't work when they contain "await" expressions. When these expressions contain awaits we use the same lowering as we would for an async function, but instead apply it to the IIFE function. Then we simply await the IIFE Call expression as the IIFE will return a future after the transform.
> - For async/sync*/async* functions we want to make sure parameter initialization happens synchronously before any of the async logic is hit. To do this we first apply the async transform the user-code function body. We then prepend the paramter initialization logic to the body of the transformed function.
> - We add support for JS_RAW_EXCEPTION which allows the machinery in async_patch to access the wrapped JS exception in a catch block rather than the unwrapped Dart exception.
> - Stacktraces and sourcemaps have some differences. There is still room for improvement in these but they should at least allow users to reasonably step through parts of the async code.
>
>
> There are also several test fixes/updates associated with this change. The test_runner wrapper no longer has to inject in asyncStart/asyncEnd calls, these are handled by the new async logic.
>
> Change-Id: I0f9f547cd9eb52ff7d850d277876d4d57568a14e
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/374444
> Reviewed-by: Bob Nystrom <rnystrom@google.com>
> Reviewed-by: Mark Zhou <markzipan@google.com>
> Reviewed-by: Johnni Winther <johnniwinther@google.com>
> Reviewed-by: Nicholas Shahan <nshahan@google.com>
Change-Id: Idfe05c0628b2b91f474d08d99427961381debeb5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/376000
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Mark Zhou <markzipan@google.com>
This reverts commit d84f908641.
Reason for revert: Causing internal failures.
Original change's description:
> [ddc] Update DDC compiler to start using the new async transform.
>
> Updates compiler.dart to use the new async transformation.
>
> Some key things to note:
> - Dart Let and BlockExpression expressions are represented as IIFEs in DDC compiled code. For non-async code this works fine but this doesn't work when they contain "await" expressions. When these expressions contain awaits we use the same lowering as we would for an async function, but instead apply it to the IIFE function. Then we simply await the IIFE Call expression as the IIFE will return a future after the transform.
> - For async/sync*/async* functions we want to make sure parameter initialization happens synchronously before any of the async logic is hit. To do this we first apply the async transform the user-code function body. We then prepend the paramter initialization logic to the body of the transformed function.
> - We add support for JS_RAW_EXCEPTION which allows the machinery in async_patch to access the wrapped JS exception in a catch block rather than the unwrapped Dart exception.
> - Stacktraces and sourcemaps have some differences. There is still room for improvement in these but they should at least allow users to reasonably step through parts of the async code.
>
>
> There are also several test fixes/updates associated with this change. The test_runner wrapper no longer has to inject in asyncStart/asyncEnd calls, these are handled by the new async logic.
>
> Change-Id: I0f9f547cd9eb52ff7d850d277876d4d57568a14e
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/374444
> Reviewed-by: Bob Nystrom <rnystrom@google.com>
> Reviewed-by: Mark Zhou <markzipan@google.com>
> Reviewed-by: Johnni Winther <johnniwinther@google.com>
> Reviewed-by: Nicholas Shahan <nshahan@google.com>
Change-Id: Ia939fe5a9dfd3a5031b06a7ea26c52e58b89f011
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/375701
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Mark Zhou <markzipan@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Updates compiler.dart to use the new async transformation.
Some key things to note:
- Dart Let and BlockExpression expressions are represented as IIFEs in DDC compiled code. For non-async code this works fine but this doesn't work when they contain "await" expressions. When these expressions contain awaits we use the same lowering as we would for an async function, but instead apply it to the IIFE function. Then we simply await the IIFE Call expression as the IIFE will return a future after the transform.
- For async/sync*/async* functions we want to make sure parameter initialization happens synchronously before any of the async logic is hit. To do this we first apply the async transform the user-code function body. We then prepend the paramter initialization logic to the body of the transformed function.
- We add support for JS_RAW_EXCEPTION which allows the machinery in async_patch to access the wrapped JS exception in a catch block rather than the unwrapped Dart exception.
- Stacktraces and sourcemaps have some differences. There is still room for improvement in these but they should at least allow users to reasonably step through parts of the async code.
There are also several test fixes/updates associated with this change. The test_runner wrapper no longer has to inject in asyncStart/asyncEnd calls, these are handled by the new async logic.
Change-Id: I0f9f547cd9eb52ff7d850d277876d4d57568a14e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/374444
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Mark Zhou <markzipan@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
This allows internal Set classes to be referenced by our runtime.
Context: incoming changes to our generic types (required for hot reload) requires that RTIs be passed to generic classes on instantiation. Moving our Set implementation into our private runtime and making their classes public allows us to directly reference them without clobbering names externally.
Change-Id: Ie47b3263ebbf2650d314b5285a2d50f3abd1a664
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/373327
Commit-Queue: Mark Zhou <markzipan@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
In https://dartbug.com/55357 a crash is reported happening after a hot
restart (not reload!) with a compilation error. This causes a "reject"
call, which means we create a new incremental compiler, initializing it
from the component of the previous good world.
World 1: Initial state.
World 2: The library is new, but (most) references are reused because
of advanced invaidation. References of unnamed extensions are
not reused. Instead the canonical names are unbound (so they
can successfully be bound to the new reference).
We now have:
* ref1 (from world1) pointing to no canonical name.
* ref2 (from world2) pointing to the canonical name.
* The canonical name pointing to ref2.
This world is rejected.
World 3: We start from the world 1 state, but because world 2 *did*
happen and that only most references (i.e. not references for
unnamed extensions) were reused, when about to unbind the
unnamed extenesion we are looking at ref1 and have nothing
to unbind.
Compiling creates ref3 (from world 3).
Upon attempt to serialize we try to bind the canonical name to
"ref3", but it is already bound to "ref2" and we crash.
The main problem here is that not only `Reference`s are reused,
but because `Reference`s point to `CanonicalName`s these are reused too.
This CL clears the canonical name in the references in the libraries that are reused, meaning that a whole new canonical name tree for those
libraries will be created. This is more in line with what the
non-advanced-invalidation does (by it not reusing references and
naturally getting a whole new canonical name tree).
In my opinion it even makes more sense --- and the fact that the
canonical names were reused was probably more me not thinking about it,
than it was a deliberate design decision.
Fixes https://github.com/dart-lang/sdk/issues/55357
Change-Id: I90bd579984f4aefad78243e8366ac0ab91a905bf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/363563
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This CL adds a `--native-assets-only` CLI option to the
frontend_server startup for single shot compilation.
This CL adds a `native-assets-only` instruction to the
frontend_server protocol.
TEST=pkg/frontend_server/test/native_assets_test.dart
Unit test producing kernel file.
Closes: https://github.com/dart-lang/sdk/issues/55503
Change-Id: Ice6281162460032e669d2dda2a128b357e81bc50
Cq-Include-Trybots: dart/try:pkg-linux-debug-try,pkg-linux-release-arm64-try,pkg-mac-release-try,pkg-mac-release-arm64-try,pkg-win-release-try,pkg-win-release-arm64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/363567
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Dill concatenation is supported in AOT now. So remove the workaround
in the frontend_server.
TEST=pkg/frontend_server/test/native_assets_test.dart
Unit test producing kernel file.
TEST=tests/ffi/native_assets/asset_relative_test.dart
VM unit test consuming AOT kernel files.
TEST=pkg/dartdev/test/native_assets/build_test
Integration test using `dart build`.
Bug: https://github.com/dart-lang/sdk/issues/50152
Change-Id: Id5c807e644cd2485fd2fb9061be0c619e95aa082
Cq-Include-Trybots: dart/try:vm-aot-linux-debug-x64-try,vm-aot-linux-debug-x64c-try,vm-aot-mac-release-arm64-try,vm-aot-mac-release-x64-try,vm-aot-obfuscate-linux-release-x64-try,vm-aot-optimization-level-linux-release-x64-try,vm-aot-win-debug-arm64-try,vm-aot-win-debug-x64-try,vm-aot-win-debug-x64c-try,pkg-linux-debug-try,pkg-linux-release-arm64-try,pkg-mac-release-try,pkg-mac-release-arm64-try,pkg-win-release-try,pkg-win-release-arm64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/363564
Reviewed-by: Jens Johansen <jensj@google.com>
The modular parts in package:vm/modular/** will only depend on
* package:kernel
* package:front_end
=> Only for auto-generated error code messages
=> Those error codes can be their own dart_library() in g3
Based on https://dart-review.googlesource.com/c/sdk/+/353980, with
changes:
* Exclude package:kernel from "no exports" CFE presubmit.
* Add package:vm/modular to CFE "allowed deps".
* Fix import in `front_end/tool/perf_common.dart` and various others.
Tested: no code changes, only moves.
Change-Id: I9a44ac6ee05478812a9c8af31f6c4bbcf44b7c42
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/354221
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Morgan :) <davidmorgan@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This CL optimizes how CFE et al presubmits are run.
In the examples below we'll that it takes the presubmit time from 31+
to ~13 seconds, from 31+ to ~20 seconds and from 30+ to ~19 seconds on
a few simple cases and from 76+ to ~27 seconds in a case where files in
both _fe_analyzer_shared, front_end, frontend_server and kernel are
changed.
Before this CL, if there was changes in both front_end and
frontend_server for instance it would run one smoke-test for each.
They would each technically only test things in their own directory,
but they would do a lot of overlapping work, e.g. compiling
frontend_server also compiles front_end; the startup cost of a script
is done several times etc.
The bulk of the change in this CL is thus to only run things once.
Now, if there is a change in both front_end and frontend_server the
python presubmit will still launch a script for each, but it's just a
light-weight script that will take ~400 ms to run (on my machine) if it
decides to not do anything. What it does is that it looks at the
changed files, from that it will know which presubmits will be run and
decide which of them will actually do the work - the rest will just
exit and say "it will be tested by this other one".
Furthermore it then tries to run only the smoke tests necessary.
For instance, if you have only changed a test in front_end it will only
run the spell checker (and only for that file).
Note that this is not perfect and there can be cases where you should
get a presubmit error but wont. For instance if you remove all content
from the spellchecking dictionary file it should give you lots of
spelling mistake errors, but it won't because it won't actually run the
spell checker (as no files it should spell check was changed).
Probably you have to actively try to cheat it though, so I don't see it
as a big problem. Things will still be checked fully on the CI.
Additionally
* the generated messages will have trailing commas which speeds up
formatting of the generated files (in the cases where the
generated files will have to be checked).
* the explicit creation testing tool will do the outline of everything,
but only do the bodies of the changed files.
* building the "ast model" only compiles the outline.
Left to do:
* If only changing a single test, for instance, it will only run the
spell checker on that file, but launching the isolate its run in
still takes ~7 seconds because it loads up other stuff too. Maybe we
could have special entry points for cases where it only should run an
otherwise simple test.
* The presubmit in the sdk dir (not CFE related) doesn't do well with
many (big) changed files and testing them for formatting errors can
easily take 10+ seconds (see example below where it contributes ~5
seconds for instance). Maybe `dart format` could be made faster, or
maybe the script should test more than one file at once.
*Example runs before and after*:
Change in a single test file in front_end
=========================================
Now:
```
$ time git cl presubmit -v -f
[I2024-01-25 09:46:08,391 187077 140400494405504 presubmit_support.py] Found 1 file(s).
Running Python 3 presubmit commit checks ...
Running [...]/sdk/PRESUBMIT.py
Running [...]/sdk/pkg/front_end/PRESUBMIT.py
Presubmit checks took 11.5s to calculate.
Python 3 presubmit checks passed.
real 0m12.772s
user 0m16.093s
sys 0m2.146s
```
Before:
```
$ time git cl presubmit -v -f
[I2024-01-25 10:07:08,519 200015 140338735470464 presubmit_support.py] Found 1 file(s).
Running Python 3 presubmit commit checks ...
Running [...]/sdk/PRESUBMIT.py
Running [...]/sdk/pkg/front_end/PRESUBMIT.py
28.3s to run CheckChangeOnCommit from [...]/sdk/pkg/front_end/PRESUBMIT.py.
Presubmit checks took 30.0s to calculate.
Python 3 presubmit checks passed.
real 0m31.396s
user 2m9.500s
sys 0m11.559s
```
So from 31+ to ~13 seconds.
---------------------------------------------------------------------
Change in a single test file and a single lib file in front_end
===============================================================
Now:
```
$ time git cl presubmit -v -f
Running Python 3 presubmit commit checks ...
Running [...]/sdk/PRESUBMIT.py
Running [...]/sdk/pkg/front_end/PRESUBMIT.py
15.9s to run CheckChangeOnCommit from [...]/sdk/pkg/front_end/PRESUBMIT.py.
Presubmit checks took 18.0s to calculate.
Python 3 presubmit checks passed.
real 0m19.365s
user 0m33.157s
sys 0m5.049s
```
Before:
```
$ time git cl presubmit -v -f
[I2024-01-25 10:08:36,277 200953 140133274818432 presubmit_support.py] Found 2 file(s).
Running Python 3 presubmit commit checks ...
Running [...]/sdk/PRESUBMIT.py
Running [...]/sdk/pkg/front_end/PRESUBMIT.py
27.9s to run CheckChangeOnCommit from [...]/sdk/pkg/front_end/PRESUBMIT.py.
Presubmit checks took 30.0s to calculate.
Python 3 presubmit checks passed.
real 0m31.311s
user 2m9.854s
sys 0m11.898s
```
So from 31+ to ~20 seconds.
---------------------------------------------------------------------
Change only the messages file in front_end (but with generated files not changing)
==================================================================================
Now:
```
$ time git cl presubmit -v -f
[I2024-01-25 09:53:02,823 190466 140548397250432 presubmit_support.py] Found 1 file(s).
Running Python 3 presubmit commit checks ...
Running [...]/sdk/PRESUBMIT.py
Running [...]/sdk/pkg/front_end/PRESUBMIT.py
15.6s to run CheckChangeOnCommit from [...]/sdk/pkg/front_end/PRESUBMIT.py.
Presubmit checks took 17.0s to calculate.
Python 3 presubmit checks passed.
real 0m18.326s
user 0m38.999s
sys 0m4.530s
```
Before:
```
$ time git cl presubmit -v -f
[I2024-01-25 10:10:04,431 201892 140717686302592 presubmit_support.py] Found 1 file(s).
Running Python 3 presubmit commit checks ...
Running [...]/sdk/PRESUBMIT.py
Running [...]/sdk/pkg/front_end/PRESUBMIT.py
28.0s to run CheckChangeOnCommit from [...]/sdk/pkg/front_end/PRESUBMIT.py.
Presubmit checks took 29.2s to calculate.
Python 3 presubmit checks passed.
real 0m30.550s
user 2m9.488s
sys 0m11.689s
```
So from 30+ to ~19 seconds.
---------------------------------------------------------------------
Change several files:
```
$ git diff --stat
pkg/_fe_analyzer_shared/lib/src/messages/codes_generated.dart | 4 ++--
pkg/_fe_analyzer_shared/lib/src/parser/listener.dart | 2 ++
pkg/front_end/lib/src/api_prototype/incremental_kernel_generator.dart | 2 ++
pkg/front_end/lib/src/base/processed_options.dart | 2 ++
pkg/front_end/messages.yaml | 2 +-
pkg/front_end/tool/dart_doctest_impl.dart | 2 ++
pkg/frontend_server/lib/compute_kernel.dart | 2 ++
pkg/kernel/lib/ast.dart | 2 ++
8 files changed, 15 insertions(+), 3 deletions(-)
```
====================
Now:
```
[I2024-01-25 09:57:53,270 193911 140320429016960 presubmit_support.py] Found 8 file(s).
Running Python 3 presubmit commit checks ...
Running [...]/sdk/PRESUBMIT.py
Running [...]/sdk/pkg/_fe_analyzer_shared/PRESUBMIT.py
17.8s to run CheckChangeOnCommit from [...]/sdk/pkg/_fe_analyzer_shared/PRESUBMIT.py.
Running [...]/sdk/pkg/front_end/PRESUBMIT.py
Running [...]/sdk/pkg/frontend_server/PRESUBMIT.py
Running [...]/sdk/pkg/kernel/PRESUBMIT.py
Presubmit checks took 25.3s to calculate.
Python 3 presubmit checks passed.
real 0m26.585s
user 1m8.997s
sys 0m8.742s
```
Worth noting here is that "sdk/PRESUBMIT.py" takes 5+ seconds here
Before:
```
[I2024-01-25 10:11:39,863 203026 140202046494592 presubmit_support.py] Found 8 file(s).
Running Python 3 presubmit commit checks ...
Running [...]/sdk/PRESUBMIT.py
Running [...]/sdk/pkg/_fe_analyzer_shared/PRESUBMIT.py
14.6s to run CheckChangeOnCommit from [...]/sdk/pkg/_fe_analyzer_shared/PRESUBMIT.py.
Running [...]/sdk/pkg/front_end/PRESUBMIT.py
28.0s to run CheckChangeOnCommit from [...]/sdk/pkg/front_end/PRESUBMIT.py.
Running [...]/sdk/pkg/frontend_server/PRESUBMIT.py
20.9s to run CheckChangeOnCommit from [...]/sdk/pkg/frontend_server/PRESUBMIT.py.
Running [...]/sdk/pkg/kernel/PRESUBMIT.py
Presubmit checks took 75.6s to calculate.
Python 3 presubmit checks passed.
real 1m16.870s
user 3m48.784s
sys 0m23.689s
```
So from 76+ to ~27 seconds.
In response to https://github.com/dart-lang/sdk/issues/54665
Change-Id: I59a43f5009bba8c2fdcb5d3a843b4cb408499214
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/348301
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Introduce `MacroException` base type that is serializable as a `RemoteInstance`. This means that if a macro implementation does not catch the exception then the exact same instance will be recovered on deserialization.
Add `UnexpectedMacroException`, `MacroImplementationException` and `MacroIntrospectionCycleInspection`.
Update API docs, analyzer and CFE to throw MacroImplementationException instead of ArgumentError.
To do after this PR: update spec, analyzer and tests `StateError`->`MacroIntrospectionCycleInspection`.
R=jakemac@google.com
Change-Id: I76be4ef7687a5f5611c963be40fb0918ac3fb7ea
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/347680
Reviewed-by: Jake Macdonald <jakemac@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Morgan :) <davidmorgan@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Generally the test loads a big dill thats 90+% the same content as the
previous load, then verifies it.
This CL loads smarter and verifies less.
Before this CL, locally, running
pkg/frontend_server/test/frontend_server_flutter.dart took
real 24m56.080s
user 48m42.422s
sys 1m2.360s
and the suite edition (using 4 shards in isolates) took
real 15m9.196s
user 53m41.118s
sys 1m30.045s
With this CL, locally running
pkg/frontend_server/test/frontend_server_flutter.dart takes
real 5m0.206s
user 9m23.933s
sys 0m20.984s
and the suite edition takes
real 3m24.243s
user 12m0.069s
sys 0m28.131s
On the try-bot the runtime seems to have gone from ~40 minutes
to ~20 minutes, the "compile flutter tests" step from ~30 minutes to
~10 minutes and the portion of time actually running the
dart-code that compiles, loads and verifies, from ~26 minutes
to ~7 minutes.
Change-Id: I6db225c33e1c0ee817f3880327e720446150ad7d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/347282
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This allows using the new scope finder and facilitates expression
compilation with and in extension types.
For now the script uri is optional (and only passable in the new json
input via package:frontend_server), and only if the script uri is passed
we'll use the new scope finder.
Flutter etc should be updated to pass the new data.
Change-Id: I36eed1ea76a825e63e4c5b9ea60daf18aee39f3d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/342400
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Anna Gringauze <annagrin@google.com>
This is done via the new json communication channel, which initially
also added support for sending "scriptUri" and "offset".
The js version of expression compilation still needs updating.
Flutter etc will also still have to be updated.
Change-Id: I428bda68aaa13aa947b57e87f7a5bfb28802cf95
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/341921
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This adds an option to compile expressions (vm ones and javascript ones)
by communicating via json. This allows for future expansion without
destroying the communication channel.
For now the old versions will continue to exist, again to not destroy
alreadyy used communication channels.
Flutter etc. should be updated to use this new json communication,
but it can wait until plumbing in passing offset and scriptUri anyway.
Change-Id: Ifbff752527fea35e09a73e0bb210072d8ab81cdc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/342340
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
First of we apply the wanted lints etc we prefer.
This includes but isn't limited to using types (i.e. no "var") and
being explicit about creation (i.e. no missing "new").
Change-Id: I516bccdac9760221ea5311af4567466bb4a65c77
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/341960
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Nicholas Shahan