- Adds a new instruction intended for recompiles during a hot
restart. This is desired so that DDC can differentiate between
the two recompiles and emit errors for hot reload. The VM only
ever recompiles during a hot reload, so they won't need this.
- Adds some tests to make sure recompile-restart doesn't trigger
errors that recompile will. Also tests that they're virtually
similar otherwise.
- Fixes a small issue in the delta inspector to use importUris
instead of fileUris when computing the LibraryIndex.
Change-Id: Ic375167ec72934cd380c4f538b45566bd87de433
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/406200
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
to compile every entrypoint
This is necessary to ensure that the options used when performing
compilation during expression evaluation or hot reload match the options
that were used to compile the running program before it was started.
TEST=test case added to pkg/dartdev/test/commands/run_test.dart, CI
CoreLibraryReviewExempt: This CL does not include any core library API
changes, only VM Service implementation changes in
sdk/lib/vmservice/running_isolates.dart.
Change-Id: If11207e090d9b02d5a6a8396e09dc90d0c874f58
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/403240
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Derek Xu <derekx@google.com>
With the new (and eventually, only) module format, we refer
to collections of libraries as bundles rather than modules.
This convention is a better fit as the frontend server
already treats modules as a collection of libraries.
Furthermore, places where we use the word "module" may be
better communicated by using "library bundle import" (the
component URI) or "library bundle name" (the synthesized
name we give library bundles).
This CL leaves usages of modules that are tied to user-facing
flags for clarity, e.g. "module format" and "useDebuggerModuleNames".
It also ignores usages where the intention is very much tied
to a module e.g. when using require.js.
Change-Id: I363b1eac955f710accece9fa3a8ea2624c751430
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/397200
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
This reverts commit 817306a735.
Reason for revert: Later patchset includes fix for `frontend_server_circular_evaluate_test`.
The fix is to cache the bundle/program compiler for all the
libraries in the strongly connected component, and not just
for the initial one that determines the component uri.
Original change's description:
> Revert "[frontend_server] Soft-deprecate moduleName for compileExpressionToJS"
>
> This reverts commit 294a50fc6f.
>
> Reason for revert: This breaks `frontend_server_circular_evaluate_test` in DWDS.
>
> Original change's description:
> > [frontend_server] Soft-deprecate moduleName for compileExpressionToJS
> >
> > https://github.com/dart-lang/sdk/issues/58265
> >
> > The DDC library bundle format does not give names to modules.
> > Therefore the frontend server should try and find the compiler
> > associated with the library and not the module to be consistent.
> > This then means that moduleName becomes entirely unused, and
> > therefore we can soft-deprecate it.
> >
> > Change-Id: I241c63a346d046405599384409a373ab12be2654
> > Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/396102
> > Commit-Queue: Srujan Gaddam <srujzs@google.com>
> > Reviewed-by: Johnni Winther <johnniwinther@google.com>
>
> Change-Id: I74b096f7ebc322c9d4428d236ab226ef1adcb6b9
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/396567
> Reviewed-by: Nicholas Shahan <nshahan@google.com>
> Reviewed-by: Johnni Winther <johnniwinther@google.com>
> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
> Commit-Queue: Srujan Gaddam <srujzs@google.com>
Change-Id: I45852c29a0b5735976f6a5f649f3ee84b26ef76c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/396572
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
https://github.com/dart-lang/sdk/issues/58265
The DDC library bundle format does not give names to modules.
Therefore the frontend server should try and find the compiler
associated with the library and not the module to be consistent.
This then means that moduleName becomes entirely unused, and
therefore we can soft-deprecate it.
Change-Id: I241c63a346d046405599384409a373ab12be2654
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/396102
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Johnni Winther <johnniwinther@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>
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>
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>
Johnni Winther