Nate Biggs
8bd3690ab0
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>
Testing of source maps
This folder contains two types of tests for validating sourcemaps: the debugging behavior and the stacktrace behavior.
Running the tests requires building the sdk target: ddc_stable_test.
Except for that, running them should simply be a matter of executing the *_suite.dart files.
All tests are plain Dart files and goes in "testfiles" (debugging tests) or "stacktrace_testfiles" (stacktrace tests). They are automatically picked up by the testing framework.
Debugging tests (step tests)
See README.md in pkg/sourcemap_testing.
Debugging a test
One can filter which tests are run by running (from the sourcemap folder):
dart sourcemaps_suite.dart -- sourcemaps/printing_class_fields
One can additionally get debug output for failing tests (i.e. tests with different outcome than expected), e.g.:
dart sourcemaps_suite.dart -Ddebug=true -- sourcemaps/printing_class_fields
The latter is also useful in combination with /*fail*/ when adding new tests to see all the places
where the debugger stopped (both in JS positions and translated to dart positions).
For instance -Ddebug=true -- sourcemaps/next_through_catch_test with a /*fail*/
currently gives output like the following:
Stop #1
test.main = function() { | main() {
try { | try {
let value = /*STOP*/"world"; | var value = /*STOP*/"world";
dart.throw(dart.str`Hello, ${value}`); | // Comment
} catch (e) { | throw "Hello, $value";
Stop #2
try { | var value = "world";
let value = "world"; | // Comment
/*STOP*/dart.throw(dart.str`Hello, ${value}`); | /*STOP*/throw "Hello, $value";
} catch (e) { | }
let st = dart.stackTrace(e); | // Comment
Stop #3
dart.throw(dart.str`Hello, ${value}`); | }
} catch (e) { | // Comment
let st = /*STOP*/dart.stackTrace(e); | catch (e, /*STOP*/st) {
{ | print(e);
core.print(e); | print(st);
[...]