This is a reland of commit e7658520bb
Fixes in the reland + context:
Type parameters emitted in implicit type checks on covariant mixin forwarding stubs may reference type arguments in anonymous classes. We reduce this to their mixin's implementing subclass to avoid generating RTI rules for anonymous classes.
Previous implementations would 'translate' type parameters to that of their mixed in type, but that strategy fails if the implementing subtype shuffles the order of type arguments relative to its mixed in type (demonstrated in the test - though not actually relevant in the Flutter break).
Original change's description:
> [ddc] Overhauling DDC's generic class representation.
>
> Prior to this change, DDC represented generic classes as closures over type parameters (with type arguments provided at runtime), which tightly coupled generic class definitions with their types and concrete instantiation.
>
> This rewrite decouples this representation, letting us 1) bind type information late and 2) separate generic class definitions from their instantiation.
>
> Notable changes:
> - Generic classes are now declared at top level (rather than within in closures).
> - RTIs are now passed to generic class constructors at runtime (except for JS Interop classes). Only the instantiated class's RTI is required (and it's retained up the type hierarchy).
> - Type signature resolvers are now lambdas that accept a type environment RTI at runtime. While signatures are still attached early, their instances' RTIs are now needed at runtime.
> - Generic classes, constructors, and factories are now evaluated in a 'Class' type environment.
> - An `RtiTypeEnvironment` is introduced to represent lookups on an RTI type environment bound to a parameter. These are used when evaluating type signatures and at constructor/factory bodies.
> - Type recipes now emit Class type parameters with names - but continue to emit method type parameters with de Bruijn indices. This is because indices aren't stable across subtypes.
> - Certain debugger functions now require instances (e.g.,`getClassMetadata`).
> - Adds a special flag for non-external JS interop factory constructors to emit 'true' types (versus 'any').
>
> Change-Id: I7cbeaaf666dd4f9bd5e3ef22a1163a659fc0ee48
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/365863
> Reviewed-by: Srujan Gaddam <srujzs@google.com>
> Reviewed-by: Kallen Tu <kallentu@google.com>
> Reviewed-by: Nicholas Shahan <nshahan@google.com>
> Reviewed-by: Nate Biggs <natebiggs@google.com>
> Commit-Queue: Mark Zhou <markzipan@google.com>
Change-Id: I9b6f69b7150631f28442675c4230e093e3b821d9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/379511
Reviewed-by: Kallen Tu <kallentu@google.com>
Commit-Queue: Mark Zhou <markzipan@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
This reverts commit e7658520bb.
Reason for revert: Causing failures in both Dart->Flutter roller and web_dev package.
Original change's description:
> [ddc] Overhauling DDC's generic class representation.
>
> Prior to this change, DDC represented generic classes as closures over type parameters (with type arguments provided at runtime), which tightly coupled generic class definitions with their types and concrete instantiation.
>
> This rewrite decouples this representation, letting us 1) bind type information late and 2) separate generic class definitions from their instantiation.
>
> Notable changes:
> - Generic classes are now declared at top level (rather than within in closures).
> - RTIs are now passed to generic class constructors at runtime (except for JS Interop classes). Only the instantiated class's RTI is required (and it's retained up the type hierarchy).
> - Type signature resolvers are now lambdas that accept a type environment RTI at runtime. While signatures are still attached early, their instances' RTIs are now needed at runtime.
> - Generic classes, constructors, and factories are now evaluated in a 'Class' type environment.
> - An `RtiTypeEnvironment` is introduced to represent lookups on an RTI type environment bound to a parameter. These are used when evaluating type signatures and at constructor/factory bodies.
> - Type recipes now emit Class type parameters with names - but continue to emit method type parameters with de Bruijn indices. This is because indices aren't stable across subtypes.
> - Certain debugger functions now require instances (e.g.,`getClassMetadata`).
> - Adds a special flag for non-external JS interop factory constructors to emit 'true' types (versus 'any').
>
> Change-Id: I7cbeaaf666dd4f9bd5e3ef22a1163a659fc0ee48
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/365863
> Reviewed-by: Srujan Gaddam <srujzs@google.com>
> Reviewed-by: Kallen Tu <kallentu@google.com>
> Reviewed-by: Nicholas Shahan <nshahan@google.com>
> Reviewed-by: Nate Biggs <natebiggs@google.com>
> Commit-Queue: Mark Zhou <markzipan@google.com>
Change-Id: I8ea12847bb2a4d096db0799c85f3175f1c5df3be
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/379420
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
Auto-Submit: Nate Biggs <natebiggs@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
DDC hot reload requires a new module format, which is
currently represented by the intersection of the DDC
module format and canary. Some of the expression compiler
tests only test the AMD module format (all of them run both
canary and non-canary since those are two different try
bots). Add code to test the DDC module format as well.
Change-Id: Ie3ca0dd3d63985d3222ab09730a82935481076a4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/377764
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Prior to this change, DDC represented generic classes as closures over type parameters (with type arguments provided at runtime), which tightly coupled generic class definitions with their types and concrete instantiation.
This rewrite decouples this representation, letting us 1) bind type information late and 2) separate generic class definitions from their instantiation.
Notable changes:
- Generic classes are now declared at top level (rather than within in closures).
- RTIs are now passed to generic class constructors at runtime (except for JS Interop classes). Only the instantiated class's RTI is required (and it's retained up the type hierarchy).
- Type signature resolvers are now lambdas that accept a type environment RTI at runtime. While signatures are still attached early, their instances' RTIs are now needed at runtime.
- Generic classes, constructors, and factories are now evaluated in a 'Class' type environment.
- An `RtiTypeEnvironment` is introduced to represent lookups on an RTI type environment bound to a parameter. These are used when evaluating type signatures and at constructor/factory bodies.
- Type recipes now emit Class type parameters with names - but continue to emit method type parameters with de Bruijn indices. This is because indices aren't stable across subtypes.
- Certain debugger functions now require instances (e.g.,`getClassMetadata`).
- Adds a special flag for non-external JS interop factory constructors to emit 'true' types (versus 'any').
Change-Id: I7cbeaaf666dd4f9bd5e3ef22a1163a659fc0ee48
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/365863
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Kallen Tu <kallentu@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Nate Biggs <natebiggs@google.com>
Commit-Queue: Mark Zhou <markzipan@google.com>
This includes a major version change from 127 to 128.
This change reverts some of the workarounds wrt
errors now that Chrome has fixed the original issue.
Change-Id: I639ee62964bf2d70e425071a1d541171f3b4af64
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/378240
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@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>
Late local variables are lowered by the CFE into a local:
* backing store variable
* get method
* set method
* isSet local variable (optionally when the type is nullable)
This change updates the name in JavaScript used for the backing store
variable to match the name for the late variable from the original
source. It also updates the scope information passed for expression
evaluation to remove the lowered name and replace it with the original
so evaluations will work as well.
The name change avoids the hiding performed by the debugger on
recognized temporary names so it appears in the list of local variables.
b/343405209
Issue: See https://github.com/dart-lang/sdk/issues/55918
Change-Id: I6b65a62baf6f26f6e9cfee9f14667d021e16645e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/369506
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Today, support for expression evaluation in DDC uses a lot of
information. To properly support compiling expressions in arbitrary
frames, we consume source-maps, module metadata, and full kernel
components at various stages of the process. This data is already
plumbed and available for non-sdk modules in our debugging systems
(frontend-server, webdev, g3), however it is not available the Dart
SDK module itself. Because of that, the expression compiler today
rejects all expression evaluation requests when the target is a Dart
SDK library.
Until the fix the availability of this data everywhere, we believe
we can support a limited form of expression evaluation: only
evaluation of libary level expressions. Basically, expressions
where scope data is not necessary and kernel outlines are sufficient to
compile the expression.
Here we introduce logic to recognize the first offset location of a
library, which is a clear indicator that no scope data is needed and
a library level expression evaluation is being requested.
This change is an attempt to help resolve
https://github.com/flutter/devtools/issues/7766. Note: just like
changes were needed here in the worker and test-compiler files, it
is possible that some change may be necessary in dwds and other
parts of the pipeline. Additional validation will be needed after
this lands.
Change-Id: Iff081a24ecb05092407279a0a7ed3d38c13cf41d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/367981
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
* Add special handling for String concatenations so the first string
gets mapped correctly and work better in sound null safety.
* Update variable assignments to more consistently point to helpful
locations, specifically when lowered from a prefix increment like
`++x`.
* Run the sourcemap and stacktrace test suites with sound null safety.
Previously these suites were running with unsound null safety so more
operations were wrapped in function calls to check for null. Those calls
allowed for mode step or break points that hid some of the issues
addressed in this change.
Issue: https://github.com/dart-lang/sdk/issues/55692
Change-Id: Ibd887c8da64e72ab84c0698dd49b845abfaedbb8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/366025
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Only run these tests with sound null safety. Follow up changes will remove more tests configurations, and null safety mode plumbing for
the DDC infra.
Change-Id: I0b511d778e54da2a8f5140c4a00b36eefb8000ac
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/365540
Reviewed-by: Mark Zhou <markzipan@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
The first in a series of changes that deletes all DDC tests running
with unsound null safety. Follow up changes will remove more tests
configurations, and null safety mode plumbing for the DDC infra.
* Delete the unsound version of some suites.
* Renames the sound suites to be more descriptive of the code in the
test instead of the mode it is run in.
Change-Id: If2edfecc811bb78a77a1e93bd6d0b75f22c3e80c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/365520
Reviewed-by: Mark Zhou <markzipan@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
* Extends the frontend server controller to validate/reject compile errors in compiles/recompiles.
* Extends the config to permit an 'expectedError' entry.
* Adds a handful of tests to the suite (adapted from the VM's hot reload tests).
Change-Id: I47d814e375c4c72d0406ebf5bdfee3f1975c64f0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/363800
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Mark Zhou <markzipan@google.com>
VM hot reload are run via:
1) We first emit a dill for every generation ahead of time (full dill on gen 0, incremental deltas subsequently).
2) We start a VM process at generation 0.
3) The VM process runs until it hits a `hotReload` command. It then uses the VM service protocol to connect to itself and reload the next generation.
4) The VM exits when the next generation isn't found.
* Adds config files to reload tests that allow runtime filtering.
* Implements VM-side hot reloading
* Adds several VM-specific hot reload tests
Change-Id: I1c6ad5c4eed426a0189c1b4af31297c9c1dba717
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/359200
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Mark Zhou <markzipan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
In the refactor to speed up this test, we removed most retry logic
(except for the "unreliable tests" that now apply retries in a
predictable manner).
The "noisy" tests have a similar behavior but for different reasons.
These put a lot of timing presure by serving hundreds of very large
files. The default response timeout of 5s trips this sometimes.
We could try to make this more predictable by providing a larger timeout
upfront, but I believe part of the intent with these tests was also to
incorporate retries for reasons like response timeouts. So instead, I've
added a retry, which will use by default a larger timeout on the second
attempt. This will hopefully be sufficient to remove this source of
flakiness.
Change-Id: I8eb5e9dceed5e7af36f6db45147c2d961247f6e2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/360503
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
This test was flaky about 3% of the time in linux bots due to a race
condition. Details are shared in
https://github.com/dart-lang/sdk/issues/55299. TLDR, when one test case
completes and it's execution is resumed (program 1), the test driver
sets up a breakpoint for a new test case concurrently and schedules to
run main again (program 2). Depending on when the breakpoint is set, it
could be hit by either program 1 or program 2. If both programs are in
the same state when they hit the breakpoint, then it doesn't matter
which program we use to validate the test expectations (a benign race
condition). However, this is problematic when the state is different,
which can happen when test 1 and test 2 both are using the same
breakpoint in a loop. This is what happened for the `forLoopTestBP` in
this CL.
To workaround this data race between two test cases, I decided to simply
combine them into a single test case. A different alternative is to copy
the test function and use a different breakpoint, but that didn't seem
worthwhile in this case.
Change-Id: I561c2a25d33d56a8543fe061342cab9cceafd4e4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/359721
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Currently our end-2-end tests create a temporary folder and delete
it after the suite has completed. Only one folder is created for the
entire test run, so the deletion only gets scheduled when the entire
suite has completed.
On windows bots, the cleanup very often fails causing up to 40%
flakiness on some tests.
This CL keeps the cleanup logic as is, but will now deem tests as
passing even when we can't do the proper cleanup.
Change-Id: I8e2e2d39d1bbdaf48c138c0a05a9a2540345fc28
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/359760
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
* Adds tests for the memory filesystem
* Enables hot restart/reload tests
* Adds flags to the hot reload suite
* Makes path resolution logic windows-friendly
* Adds test-reporting logic for trybots to hot reload tests
Change-Id: Ic51a0b8a3c6f8b6de20b58b2ac185dacf444cf47
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/353788
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Mark Zhou <markzipan@google.com>
* Delete unused stuff
* rename 'path' to 'root'
* accept 'includeEndsWith' as a plain text string so we often can avoid
using regexp
* accept 'subRoots' to filter to directories faster and more precisly
than when using regexps in 'pattern'
* make 'list' async instead of async* (no more yield stuff which we
promptly turn into a list when actually using it)
Note that some changes in testing.json is not 100% semantic-preserving,
e.g. the "parser_all" suite previously had a pattern "/tests/.*\\.dart$"
which was probably meant to include all dart files in the "tests" folder
in the root, but in fact included all dart files in a "tests" folder
anywhere. The updated version does not.
Change-Id: Idd014274f86bf6214dee0753a7738ec80bc6a49e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/358442
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
While working on the e2e tests, I noticed this test was taking a
long time. Turns out this was because it fully exercises an http
client retry logic using exponential backoff and up to 4 retries.
To reduce the costs, I changed the test to use controlled
environment instead. This still hits the same code-paths but
provides a faster turnaround by using at most 1 retry, and issuing
retries immediately.
With these changes, the test completes in 3s (instead of 28s).
I noticed that some of the tests to check an "unreliable" server
where non-deterministic (multiple parallel requests that sometimes
fail or succeed). The changes here also make it deterministic. While
this test seems to have some flakes due to other reasons, my hope is
that these changes will reduce the chances of this test being flaky
on the bots.
Change-Id: I8eb2a00c7a489ab4e5a46e2b5cdbee40d1ffb8d5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/356623
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Ideally we would write each source next to each test to make tests more
readable, but clustering all tests to use a common test file really
helps boost the runtime of the end2end tests now that we reuse the same
page between tests that share the same code.
This CL refactos the tests to mostly use one shared test file. Doing so
speeds up tests between 2x-4x depending on the test.
Change-Id: I9afd00c6a42226899969e3f605ac18e0d2b1a906
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/356285
Reviewed-by: Mark Zhou <markzipan@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Since we changed how the test driver sets up breakpoints, we now we
have the ability to reuse a page for multiple tests.
Before, the test harness would follow this sequence:
* on each group of tests, it would call `_initSource`, which sets up
a boostraper and code to execute on the browser. This code was
reused by all tests in the group.
* on each test, it would indirectly call `_loadScript`, which
navigated to brand new page for each test. If there were multiple
tests in a group, this would load the boostraper and code once per
test.
This CL keeps the sequence of operations the same, except, that
`_loadScript` will reuse the existing page if it already loaded the
boostraper and DDC code needed by the next test.
This greatly reduces the total running time of some of the
expresison compiler shards. On my local machine one such test took
24s before both this and the parent CL, but now takes about 5s.
Change-Id: I7774df9e83142b42efc4ad523f589758a2a4660c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/356301
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Mark Zhou <markzipan@google.com>
Instead of pausing the application while loading, this
changes the bootstrap logic to not invoke main immediately.
Later the test harness uses an expression evaluation to
trigger the start of the application when it is ready for
it.
This change will enable the ability to reuse the same page
and script across multiple tests, which will save a lot of
test execution time (see related child CL).
Change-Id: Ifa1050ac777aabb3e21b69953e85c6578b3e0cc0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/356281
Reviewed-by: Mark Zhou <markzipan@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
The data shows a lot of variation by machine. The slowest test samples
bring the p90 above 4s, which explains that we often hit the limit.
I expect that we'll continue seeing flakes, but less often as a result
of this change. That said, some of the e2e test are taking close to 4
minutes, so we may need additional sharding or switch our approach if
that ocurrs more often.
Change-Id: I47c0dbce6f766edf7c2845d26f11ae7c6372a7bc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/355980
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
The hot reload runner currently only supports d8, but I plan to add support for Chrome and VM execution.
Notable changes:
* Creates `package:reload_test` with helpers for running this suite.
* Updates the module loader with D8-specific branches and hooks for hot reload/restart.
* Exposes DDC runtime variables via a `HotReloadTestRuntime` API.
* Ports constant equality hot restart tests from webdev/dwds (validated to fail if either cache-clearing mechanism fails).
* Partially rolls DDC's d8 preamble forward (towards dart2js's).
* Wraps D8's timer implementation with custom timeout logic to better match Chrome's timing semantics when executing with native JS async.
Tests for the framework and matrix updates will be added in an upcoming change.
Change-Id: I2773b29f464cfd0330e4c653c05e117ae150b4a6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/350021
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Mark Zhou <markzipan@google.com>
Multiple end-to-end tests are failing in the bots because some steps
during the test execution are timing out. We currently have a
timeout of 5 seconds for these steps, but it's unclear if the
timeout is because of conditions in the bot machines (e.g. they are
slow), one off exceptions, or something else.
To address the flakiness, I expect we will want to increase the timeout,
but before we do it may be valuable to start measuring what is the
current distribution of timing in the bots to figure out the best value
to use.
This CL adds logging for timing data for that purpose. I've added
tracking for some interesting steps in the expresson-compiler test
framework, including the top two steps that usually hit a timeout in
practice (find-script and pause-event-for-line).
Example output on my local machine:
```
init-source: 233ms (avg), 121ms (p50), 696ms (p90), 696ms (max), 7 (total)
find-script: 18ms (avg), 18ms (p50), 21ms (p90), 25ms (max), 52 (total)
load-script: 22ms (avg), 22ms (p50), 27ms (p90), 30ms (max), 52 (total)
set-breakpoint: 0ms (avg), 1ms (p50), 1ms (p90), 2ms (max), 52 (total)
pause-event-for-line: 422ms (avg), 410ms (p50), 440ms (p90), 658ms (max), 52 (total)
check-in-frame: 459ms (avg), 446ms (p50), 480ms (p90), 695ms (max), 51 (total)
```
Change-Id: I04734b9905da8e1b4c9d06451be65a2dee32ba1c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352988
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
MarkZ