* 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>
All uses either already pass a non-nullable String or assert that
the returned value is non-nullable which would be equivalent to
asserting that the value passed is not null.
Change-Id: I6308a8b39bc5ee08db6741145ed7b8a983c33118
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/365662
Reviewed-by: Mark Zhou <markzipan@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>
With the new type system type arguments appearing in extends are
no longer represented by a class definition and do not need to
trigger any lazy logic.
Change-Id: I3f80f9f972bec69c678909c12d25a604a8fe2c59
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/353205
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Mark Zhou <markzipan@google.com>
If DDC is invoked with an relative output path during the Dart SDK build
itself rather than an absolute path, then the build will fail with an
error message that it can't calculate the relative path between the
output file and the source map. The problem is that p.url.relative
cannot be used with real relative filesystem paths as the current
directory is assumed to be the string '.' rather than the actual
directory and the algorithm cannot perform the resolution.
This change blocks the RBE dart action offloading in a follow up change,
which changes the Dart SDK build to only use relative paths when
building on RBE, which otherwise fails in the above manner.
Fixes: b/333765428
Change-Id: I5f3d984337cdd006feeb6b721f21fa17ed0d23f5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/362189
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Auto-Submit: Jonas Termansen <sortie@google.com>
Commit-Queue: Jonas Termansen <sortie@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>
When running in d8 the runtime flags need to be set by loading an
SDK with the same name passed for the application that gets used
when the application is started. If not the module system will
create an additional instance of the SDK module. This meant the
runtime flags were being set in one instance while the application
read them from another.
The same issue was present in the ddb script and this change fixes
it there as well.
Add the `--interop-null-assertions` option to the ddb script that uses
the runtime flag to enable null checks on non-static JavaScript
interop APIs.
Issue: https://github.com/dart-lang/sdk/issues/55378
Change-Id: Id8c31383fa601f5953e2cc41021746aa918186b7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/361133
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
- Add a runtime flag to enable checks on non-nullable APIs that
return values from non-static JavaScript interop.
- Call a new helper method at the call site when these APIs are
detected to perform the null check.
- Add test file for the cases we can detect and enforce.
NOTE: This does not make non-static JavaScript interop sound.
This only adds more checks to enforce soundness with respect
to nullability in some cases. There are still holes that will
never be closed due to the permissive nature of this form of
JavaScript interop.
Change-Id: I2f88d1543a683fdc84d764e2b0eaafeb0ca73107
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/358581
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Srujan Gaddam <srujzs@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>
The flag allows for overriding the default (amd) with the ddc module
format when using `--runtime=chrome`.
This is intended to make it easier to test and debug changes to
the ddc module system.
Change-Id: I34767e2e80e9c80af5870bb7f51bf9ebaf438336
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/355507
Reviewed-by: Mark Zhou <markzipan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: 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>
Johnni Winther