This code should be using a `LiteralNull` from the JS AST but was
accidentally using the `NullLiteral` from the Kernel AST.
Add a test to trigger this code path in the expression compiler
because there must not be a source location for the code being
compiled.
Add a retry duration for getting a chrome tab in the test suite.
This fixes a failure I was seeing when I run the test locally.
Change-Id: I6900ace6280f1105c77ccafce4f47d0fc5771d6b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/252540
Reviewed-by: Anna Gringauze <annagrin@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
`VariableDeclaration.name` could be null when the variable
was synthetically introduced by the compiler. In this case the
expression compiler can ignore the variable because it's value
doesn't reflect the value of a variable in the original dart
source code.
Add a regression test for the expression compiler that
ensures code that introduces a synthetic variable will not
cause a crash when you stop at a breakpoint.
Fixes: https://github.com/dart-lang/sdk/issues/49373
Change-Id: Ifc5f72ab4e5733ead17a20889c222bcc46921f6b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/250343
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Anna Gringauze <annagrin@google.com>
Use `hasScheme` in place of comparing against the empty string, and
`isScheme` to compare against all other schemes.
TEST=No behavior changes.
Change-Id: Ifc9fd13c6cf37933ebd4a754c4b500dedbcb291b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/231185
Reviewed-by: Kevin Moore <kevmoo@google.com>
Commit-Queue: Nate Bosch <nbosch@google.com>
In the test suite, the options passed to the two phases of the
compile drifted apart. Some were false when compiling the module
but true when printing that module as Javascript. This surfaced
when some unused portions were migrated to null safety.
Change-Id: I2d5c648bc53e5c9fe3f014446393d0f893bd5382
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/218181
Reviewed-by: Anna Gringauze <annagrin@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
* Tests constructor tear off values and calling torn off constructors.
* Covers default, named, redirecting, and factory constructors at break
point locations in a method, global function, and inside the default
constructor.
* Create new test suites for legacy code (Dart language version 2.11)
in amd and ddc module systems.
* Sound and Unsound suites now run code without a Dart language comment.
Change-Id: I9cf16c258ce6ece7c436f9deb044ed821f980d1b
Fixes: https://github.com/dart-lang/sdk/issues/47214
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/214866
Reviewed-by: Anna Gringauze <annagrin@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
We use `package:shelf/shelf_io.dart` to serve the requests,
which in turn uses `package:shelf_proxy/shelf_proxy.dart` as
an inner request handler.
On exception (such as seen in the webdev CI failures) the shelf_io
returns 500 response, which is currently is not causing a retry in
RetryTimeoutClient.
This change adds retries on 500.
Add tests with server returning InternalServerError.
Closes: https://github.com/dart-lang/webdev/issues/1345
Change-Id: I73470d73fb5651edee4bf2033ae514930bfe28c2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/206581
Commit-Queue: Anna Gringauze <annagrin@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Kevin Moore <kevmoo@google.com>
Recent flakes in webdev CI show failures to load dill files
due to broken sockets (most likely caused by connection timeouts).
This change adds retries and timeouts to the asset server file
system to make it tolerant to breaking connections.
- Add RetryTimeoutClient wrapper for HttpClient that performs
retries with delays and connection/response timeouts, based
on the idea in
https://github.com/dart-lang/http/blob/master/lib/retry.dart
- Make AssetFileSystem use the RetryTimeoutClient.
- Add tests for reading multiple files concurrently.
- Add tests for ExpressionCompilerWorker reading assets using
standard, multiroot, and asset file systems.
- Simplify uri that AssetFileSystem uses to query the asset
server, since we no longer need to load package uris.
This will eliminate a step in uri translation in dwds.
- Validated that changes do not break google3 manually.
Change-Id: I2ff163b8d99cd0b7551f3f33a71e6b306540e3c9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/204880
Commit-Queue: Anna Gringauze <annagrin@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
We are seeing CI flakes in webdev when using expression_compiler_worker
in tests involving expression evaluation, for example, see linux tests
for dwds in the following PR:
https://github.com/dart-lang/webdev/pull/1343
The logs show that HttpFileSystemEntity.exists fails due to a broken
pipe, which we suspect is due to http client closed too early.
This change is an attempt to fix the problem by
- logging exceptions thrown in expression compiler worker
- awaiting for the request to be read before closing http client in
HttpFileSystemEntity.
TEST=pkg/dev_compiler/test/expression_compiler/asset_file_system_test.dart
See investigation of the CI issue in:
https://github.com/dart-lang/webdev/issues/1345
Closes: https://github.com/dart-lang/sdk/issues/46388
Change-Id: Iaf98f08e8ebb618bf8365bd497f01ae685f0d3f2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/203841
Commit-Queue: Anna Gringauze <annagrin@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
* Now tests both DDC + AMD module systems
* Porting more tests + purging them from the regular test
* Fixing a bug related to string-typed JS scope objects
Change-Id: I703d3760971ef8c14ef4157a71b364d8d3c22aaf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/194080
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Mark Zhou <markzipan@google.com>
Adding the dartdevc_test target to the pkg-linux-debug bot config since some of its tests require that the sound SDK be built. Also failing more gracefully if the expected dill is not found.
Change-Id: I5d2004a3a13d9f73dcb51afb3c68c0b7c18e614e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/194108
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Mark Zhou <markzipan@google.com>
Adding 'dartdevc_test' target to pkg-X builders.
Splits eval tests into sound and unsound suites.
Adding more robust event polling (instead of just waiting 500 ms).
Turns on sound mode for the ported tests.
Also ports a couple more tests.
Change-Id: Ia8e9095e1e3330ea1732a4fa4f14425777de5127
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/193446
Reviewed-by: Anna Gringauze <annagrin@google.com>
Commit-Queue: Mark Zhou <markzipan@google.com>
In some cases, such as file system exceptions, ExpressionCompilerWorker
fails to start but does not close its receiver port, which causes the
consumer to wait indefinitely for responses.
Make ExpressionCompilerWorker communicate the failure to the consumer,
close the receiver port, and exit.
Added tests to verify graceful exit.
Issue that uncovered the bug: https://b.corp.google.com/issues/183218372
Change-Id: I54a9c3620cfc5f77c101b26b4e98b6eeb03ad7e1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/192260
Commit-Queue: Anna Gringauze <annagrin@google.com>
Reviewed-by: Gary Roumanis <grouma@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
The full workflow for an end-to-end test:
1) Perform test/compiler options pre-initialization.
2) Start an instance of Chrome (with 1 tab) and save a persisted debug connection for use in all tests.
3) For each separate Dart program to be tested:
1) Create inside a temp directory the HTML bootstrapper, DDC-compiled JS sources, and auxiliary JS files (dart_library.js or require.js).
2) Initialize a DDC ProgramCompiler/IncrementalCompiler and perform a full compile of the program, saving the compiler's state for subsequent incremental compiles.
3) Enable the debugger and set a URL breakpoint at the program's main JS entrypoint.
4) For each test for this Dart program:
1) Navigate to the HTML bootstrapper, pausing when the target module is loaded (at the breakpoint set above).
2) Set a breakpoint at a JS location translated from a Dart breakpoint ID via source maps.
3) Resume the debugger, pausing at that breakpoint. Remove the breakpoint.
4) Reconstruct the local JS scope, then evaluate the Dart expression.
5) Evaluate the JS expression inline, then compare results with expectations.
5) Disable the debugger to clear its state.
4) Shut down Chrome and clean up any temporary directories.
Other notes:
* Supports bootstrapping/compilation on AMD and DDC module systems only (though expression eval is only supported on AMD)
* Requires that Dart breakpoint IDs be set declaratively (no support for columns)
The test structure/flow is subject to change. While I port existing tests, Dart programs will consist of inline source file strings with simple breakpoints. In the future, we want to allow more complicated Dart programs to be specified (like in the modular test framework) and more complicated expression evaluation test patterns (rather than allowing only a single evaluation per test).
Change-Id: I5de7cfa66991fd14b24fa16edd1615f55c041ae3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/190962
Commit-Queue: Mark Zhou <markzipan@google.com>
Reviewed-by: Anna Gringauze <annagrin@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Nicholas Shahan