This makes tests more reproducible, and makes it easier to copy commands between workspaces, or between a failing bot and a local workspace.
Change-Id: Ic8dd10a3540f314a406e5c5b0a23d97032e5d01d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/508364
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
The front-end, dart2js, dart2wasm, ddc and analyzer bots do not need the cross-compilation or sanitizer tools, nor the VM test binaries.
Change-Id: I2f5a1041b1b29c562bace7210830e9904a31c397
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/510040
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed in https://dart-review.googlesource.com/c/sdk/+/497583
[dartpad] Part 1: Protocol and Scaffolding
This sets up folders for `package:dartpad` and `package:dartpad_worker`,
R=athom@google.com, sigurdm@google.com
including:
* `OWNERS` files,
* Protocol definition,
* Exceptions, and,
* Virtual file system utilities.
[dartpad] Part 2: HotReloadCompiler
Adds the hot reload compiler logic to dartpad_worker.
This is models on dartdevc with `--reload-last-accepted-kernel` and
`--reload-delta-kernel` options. I don't think this does an incremental
compilation, instead it does a modular compilation. Meaning, we can have
a huge collection of precompiled DDC modules and the compiler just gets
a DDC outline/summary dill files for these modules. But on the other hand
the actual code that is compiled will be recompiled on every compile()
call.
This is very important for flutter_web.js / flutter_web.dill where the
precompiled DDC modules is around 60 MB in total. The fact that
package:flutter is precompiled into flutter_web.js is critical for
compilation performance for small dartpad-style example apps.
The downside is that unlike incremental compilation with _frontendserver_,
if the user were to install package:http and use it in the app they are
compiling then every `compile()` call will recompile `package:http`.
Where as with _frontendserver_ we'd be able to invalidate specific files,
and only those would be recompiled.
This leaves future work to either:
* (A) Add support for modular compilation to _frontendserver_, such that
we can do incremental compilation without having to first compile all
of `package:flutter`.
* (B) Refactor compilation strategy implemented here, to leverage
modular further. We could for example compile all dependencies from
`PUB_CACHE` into a `pub_cache_outline.dill` inside the dartpad worker.
Then recompilation would only touch the user-code. Granted this is
still less than ideal.
At the moment the lack of incremental compilation is not a blocker,
current dartpad doesn't have incremental compilation, but granted it also
only supported a single file. This dartpad environment will support
multiple files, but adding many files will result in poor performance
until we refactor and figure out how to do incremental compilation.
Hence, why we shouldn't block progress waiting for incremental compilation
to work.
R=nshahan@google.com
[dartpad] Part 3: Pub execution wrapper
Adds the internal wrapper for executing pub commands inside the
worker's virtual file system.
R=sigurdm@google.com
[dartpad] Part 4: Language Server wrapper
Adds the internal wrapper for spawning and communicating with the
Dart LSP inside the DartPad worker.
R=scheglov@google.com
[dartpad] Part 5: DartPad Worker
Implements the main worker entrypoint, RPC message handling. The
`bin/worker.dart` is what will be compiled to WASM and will run as a
_Web Worker_.
R=sigurdm@google.com
[dartpad] Part 6: DartPad Client library
The public-facing `dartpad` library that developers use to embed
the compilation environment in their web applications.
This finishes `package:dartpad`featuring:
* `DartPad.create()`, which creates a _Web Worker_ running the compiled
`pkg/dartpad_worker/bin/worker.dart`, and returns a `DartPad` instance
wrapping RPC calls into the _Web Worker_.
* `Sandbox.createIFrame()` which creates a _sandboxed iframe_ containing
precompiled DDC modules from the SDK assets and `sandbox.js` for
wrapping `ddc_module_loader.js` with an RPC interface. This returns a
`Sandbox` instance wrapping RPC calls into the _sandboxed iframe_,
making it easy to load modules, run library entrypoints (main()),
initiate hot-reload, or launch a flutter app.
This is an initial API design that works. There are minor inconsistencies
and improvements that we should do. But I propose that we do so in
follow-up PRs.
R=sigurdm@google.com
[dartpad] Part 7: Build Targets
Adds a `dartpad` target to the Dart SDK, which produces:
```
out/ReleaseX64/dartpad/
├── dart
│ ├── dart_sdk.js.map
│ ├── sdk.js
│ └── sdk.tar
├── ddc_module_loader.js
├── sandbox.js
├── worker.loader.js
├── worker.mjs
├── worker.support.js
├── worker.wasm
└── worker.wasm.map
```
The `dartpad/` output folder is intended to be used as `assetBaseUrl` in
client libraries provided in `package:dartpad`. And the `dartpad/dart/`
folder is intended to be used as `sdkLocation`. These files are not
intended to be distributed along side the normal Dart SDK, instead we'll
publish them on a CDN and let people use `package:dartpad` to point at
these files. If they want to self-host everything, they can copy from our
CDN or rebuild the files using a local Dart SDK checkout.
These files are also necessary for testing, to ensure that we have proper
integration tests for `pkg/dartpad_worker/`. As we will want to publish
these files on a CDN the actual compiled size in release-mode matters,
thus, we have enabled wasm optimizations steps in this mode.
R=rmacnak@google.com
[dartpad] Part 8: Tests for `package:dartpad` and `pkg/dartpad_worker/`.
We have 3 kinds of tests:
* Unit tests (vm, browser or both),
* Worker tests (vm and browser),
* Integration tests (browser-only).
As the Dart SDK test runner simply executes `*_test.dart` files with
`dart` and doesn't support compiling tests to the browser, launching and
running tests in the browser, we employ `dart test` to run tests. We do
this by having `pkg/dartpad_worker/dart_test.yaml` specify that
`dart test` should look for files names `test_*.dart`, and we then create
`pkg/dartpad_worker/test/ci_test.dart´ to be a single test that simply
runs `dart test` as a subprocess. Thus, the only test file triggered by
Dart SDK test runner is `ci_test.dart`, and if you locally run `dart test`
this will run the individual `test_*.dart` files.
While this hack to use `dart test` isn't ideal it gives everyone a decent
work flow. And saves us from having to invent complex test harness for
`pkg/dartpad_worker/`.
**Worker tests** defined in `test/dart/worker/` and `test/flutter/worker/`
are all imported into `test_dart_worker.dart` and
`test_flutter_worker.dart` to reduce test compilation time. These have a
non-trivial compilation time because the worker is running in the test
process. This allows testing on VM, which can be easier to debug.
**Integration tests** unlike _worker tests_ launch the worker compiled by
the `dartpad` build target in a _Web Worker_. This has less compilation
overhead for the individual tests, but involves more setup, and can be
a bit harder to debug.
Both worker and integration tests employ `test/asset_server/` which serves
assets built by the `dartpad` build target, and serves as a pub-server for
tests. It also serves assets built by `tool/setup_local_flutter.dart`
which creates flutter assets, though this is not intended to run as part
of CI, since we do not have a Flutter checkout available. Thus, for the
time being flutter testing is local only. Maybe, later we'll move this
script to another repository.
R=sigurdm@google.com
Cq-Include-Trybots: luci.dart.try:pkg-linux-release-try,pkg-win-release-try
Change-Id: I3a99939ec5217b9f3a855fc5b9ad9699047d02cc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/507321
Commit-Queue: Jonas Jensen <jonasfj@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
This migrates the `String` implementation from using JS interop to
explicit host imports for the standalone target.
This moves a few helper methods shared between the JS and standalone
targets to `dart:_string_helper`. This also moves the embedder regexp
implementation to `dart:_string` to be able to access internals in some
string methods (similar to how the JS implementation special-cases
`JSSyntaxRegExp`).
This removes the final real use of JS-interop in the standalone target.
So, we can:
- Remove internal JS helper libraries from the target.
- Skip JS-interop transformations in the compiler.
- Stop emitting a helper module and support script.
Because `js_interop` is imported in `dart:_wasm`, we can't remove the
library entirely. This replaces it with a stub to avoid compilation
errors, a proper removal is tracked in dartbug.com/63166.
Change-Id: Ide495c210c3a272438deebf8fe4f3f44ba314ffa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/501960
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Kevin Moore <kevmoo@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
This CL only adds the option and appropriate uses of it. Followup
CLs will use it to actually generate appropriate instructions and
metadata for collecting coverage information.
TEST=ci (just adding flag)
Cq-Include-Trybots: luci.dart.try:vm-dyn-linux-debug-x64-try,vm-aot-dyn-linux-debug-x64-try,vm-aot-dyn-linux-product-x64-try
Change-Id: I194154ef926abe7dae8bb93f397fb68029e2db3c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/501500
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Tess Strickland <sstrickl@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Add support for keeping parser diagnostic expectations in the source
snippets they describe. Expectations are written as caret markers and
diagnostic comments, and regenerated from the parser's actual
diagnostics before comparison.
This keeps parser recovery expectations close to the code under test and
removes the need to maintain offset-based `assertErrors` lists by hand.
The updater also removes existing expectation markers before writing the
canonical form, so marked snippets can be refreshed in place.
Migrate recovery parser and class parser tests to the new
`assertExpectedDiagnostics` helper, including no-error cases where an
unmarked snippet is the expected canonical form.
Update `test_runner` to exclude `/pkg/analyzer/` from searching static
error expectations.
Bug: https://github.com/dart-lang/sdk/issues/63335
Change-Id: Ic9866da8cc601c6b360552ba576e8aa1646f89a5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/501340
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
This CL adds support to the test runner for the test outcome
expectation syntax that uses `// [...]` to indicate which diagnostic
we should expect with the given tool. Currently, `...` is `analyzer`
when testing the analyzer and `cfe` when testing the common front end.
After landing this CL, it also supports `// [spec_parser]`.
This change would allow us to migrate several tests from the multi-test
format (like `code; //# 01: compile-time error`) to the new format, in
particular tests with intentional syntax errors.
Change-Id: I5dd2560a873eb7433d3e07aa8f393e83c51b28e7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/501161
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
The test_runner skips test runs on all but front-end-only configurations
in the case where the test contains expectations that there will be
a compile-time error. This CL changes the "front-end-only"
classification such that the spec parser is included.
Before this CL, this implies that a test with a syntax error and an
expectation that this syntax error will be reported is simply skipped
when using `tools/test.py -c spec_parser ...`. With this CL, the
spec parser will be executed on that test, as it should.
Change-Id: I32ed313b5da20c189ca2f9b6b9ea3bb45f5072c7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/500721
Commit-Queue: Erik Ernst <eernst@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
This replaces js-interop and `JS(...)` usages in patches for
`dart:core` in the dart2wasm standalone target with explicit host
imports.
This still uses JS strings as a string implementation, so js-interop
from `dart:core` hasn't been removed completely. Migrating strings will
require additional changes - mainly to `dart:js_interop` itself, which
we want to remove from the standalone target anyway. So, I believe it
makes sense to migrate strings last.
In most cases, these imports match the manual JavaScript we've used
before. `StringBuffer`s are an exception here, the default platform
implements them via string concatenation but some embedders might
benefit from explicit string buffers.
TEST=tests/corelib/**
Change-Id: I1ea18ac30bac24b30e528b2c28d925fda886c988
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/491480
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
dart2wasm imports strings as globals for which JavaScript engines would
provide the respective values. The standalone target needs to support
all WebAssembly runtimes, so it can't rely on this mechanism.
Instead, this imports functions to convert a WebAssembly arrays of char
codes or ASCII bytes into a string. For now, these functions have to
return JS strings since the rest of the SDK relies on that. In the
future, embedders would be able to return any string implementation as
an externref.
Because calling host functions is invalid in constant contexts, string
constants can't be regular globals. For now, this uses the default
non-eager constant implementation with one initialization function per
string constant. Eventually, we should probably initialize these
strings in a WASM start function instead.
TEST=pkg/dart2wasm/test/standalone_test.dart
Change-Id: I93b7c3846fbe99daa8ffa31e452f62672b61ce4b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/495020
Reviewed-by: Nate Biggs <natebiggs@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
Doesn't change anything in `front_end/*testcases/primary_constructors/`.
(Would have skipped any other file with `test` in its path and
an explicit language version marker, but there weren't any outside
of those `front_end` directories).
Almost no files used as test input were affected, and none testing the actual syntax changed.
The `.../nnbd/required_2.dart` test case was split into a legacy version retaining the `var`/`final` with a language marker, and a new version without the `var`/`final` cases.
The `pkg/analyzer/` tests, and any other tests that have source code
in strings, are not migrated by this CL.
Tested: No change to behavior. One test split into legacy and new.
Change-Id: I7f5aa4cc98001a9adecacd106c0b3be14f96be1c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/480542
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
This fixes two issues in the dart2wasm standalone timer implementation
and test embedder:
1. We shouldn't compare `WasmExternRef` values with `null` (use
`isNull` instead).
2. The `scheduleRepeated` implementation of the test browser embedder
tried to divide a bigint by a JS double.
These two items fix most of the timer test failures for the dart2wasm
standalone target.
Change-Id: I5403f4790b1ec10eb316c52efb3939077f5e273c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/489160
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Kevin Moore <kevmoo@google.com>
When compiled to WebAssembly, the Dart SDK needs access to external
host functions to implement regular expressions, stack traces, timers
and more. Currently, `dart2wasm` relies on `js_interop` definition to
implement these functions in JavaScript.
As discussed in https://github.com/dart-lang/sdk/issues/53884, an
alternative is to use `wasm:import` annotations to let an arbitrary
embedder that doesn't necessarily run in a JavaScript context inject
implementations for these host functions.
This would allow running `dart2wasm` apps by e.g.
- using a runtime like wasmtime and defining host functions in Rust.
- defining a wrapper module implementing required functions by
delegating to WASI definitions, and then using say `wasm-merge` to
run the app in any WASI-compatible runtime.
This prepares the `--standalone` flag on `dart2wasm` to do just that.
When enabled, the compiler uses a different SDK platform to use imports
instead of JS interop. For now, these platforms are almost identical:
I've ported the timer logic to use wasm imports as a demo, but the rest
is still based on existing patch files. We can revisit in subsequent
CLs to incrementally reduce `js_interop` dependencies before removing
that library from the `dart2wasm_standalone` target entirely.
Change-Id: I3f406afbf2dab65506094de5c3f4067f4db66f3e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/486380
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
This CL is part of an effort to bump the SDK requirement to `3.12.0-0`
for all the packages in `pkg` that are not published to `pub`, so that
we can get better testing of the "private named parameters" feature.
(Packages that *are* published to `pub` can't be safely bumped yet,
because SDK 3.12 hasn't been released, and I don't want to block those
packages' ability to publish useful updates to customers.)
This change covers the following packages, which are owned by
OWNERS_INFRA:
- pkg/smith
- pkg/status_file
- pkg/test_runner
Changes to `pubspec.yaml` files were made manually.
Changes to `.dart` files were made automatically (with some
exceptions), using `dart fix` to migrate to using private named
parameters where it is possible to do so without changing
semantics. Note that this migration is conservative; see
https://github.com/dart-lang/sdk/issues/58607 for details.
The exceptions are:
- pkg/test_runner/lib/src/compiler_configuration.dart
- pkg/test_runner/lib/src/path.dart
These files contained code that triggered the
`use_null_aware_elements` lint, so I manually fixed the instances of
the lint. (The lint didn't previously fire because the test runner
used to be on language version 3.5.0, which was before the "null aware
elements" feature existed.)
Change-Id: Ia5d99ba5fc2d5aacbec5b091348be1d26a6a6964
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/487882
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
This updates JS exception catching as discussed in #55481:
- Only catch JS exceptions when the exception type is `dynamic`,
`Object`, or an extension of `JSValue`. (nullable or not)
(Previously we also caught JS exceptions when the type is `Error`.)
- When the JS value caught in Wasm is `null` or `undefined`, box it as a
non-interop class. For compatibility with dart2js, this class is
copied from dart2js and has the same `toString` as the dart2js class.
- In other cases: box the JS values as `JSValue`. This means the value
can be passed as any of the interop types, and can be passed back to
JS without manual jsification.
Fixes#55481.
Issue: https://github.com/dart-lang/sdk/issues/55481
Change-Id: I23e73074729f740b90df2ca8b3c713fb39966556
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/479640
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
With `loadDeferredModule` there was no easy way for the embedder to batch module loads that were part of the same load ID. The loop happened within the wasm runtime and so the best the embedder could do was a `setTimeout(f, 0)` and collect the modules before making a request. This can lead to unintended delays though.
Instead we now pass the full list of modules to the embedder's registered loader along with an instantiator function so that the emebedder can start compiling concurrently before all the modules are done loading.
Added a changelog entry since this API is new but might be in use.
Change-Id: I4ae3a9fc28fc726909f63a1dd4ea1d98d5fc3fc0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/481360
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Change the `test_runner` package's use of `DiagnosticCode.name` to
`DiagnosticCode.lowerCaseName`. There is no functional change since
all diagnostic codes generated by the analyzer are already in lower
case.
This helps pave the way for eventually deprecating and removing
`DiagnosticCode.name`, which will help ensure that analyzer clients
treat diagnostic codes in a case-insensitive fashion.
Change-Id: I6a6a69644898dff67a1f53dbe8c8a8cb757d2c96
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/468121
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
This roll moves `package:record_use` to the dart-lang/native repo.
Change-Id: I31183dc8b72272d7e94ed3031ca0b8bfca583e0d
Cq-Include-Trybots: luci.dart.try:pkg-linux-debug-try,pkg-linux-release-arm64-try,pkg-linux-release-try,pkg-mac-release-arm64-try,pkg-mac-release-try,pkg-win-release-arm64-try,pkg-win-release-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/463662
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Michael Goderbauer <goderbauer@google.com>
This allows Enums created elsewhere to be used for enumOption
declarations.
Also change the analysis options for pkg/test_runner so that
exhaustive case errors are no longer ignored.
TEST=ci
Change-Id: Ib1cf1c015f4a6df9ce018117edfd9b626e91c5f6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/438725
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Tess Strickland <sstrickl@google.com>
JavaScriptCore's wasm interpreter was buggy which caused many segfaults
on our CI, which made us implement this workaround (namely to disable
the wasm interpreter)
It seems it has matured, so we can remove this workaround.
Doing so may also lead to less jsc crashes / instability on CI and will
make us use default flags (testing closer to what is used in real
Safari)
Change-Id: Id30a017dcf1b3b37e6c0c99bddfa634b96bf45ac
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/458100
Reviewed-by: Nate Biggs <natebiggs@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Load ids provide a way to reduce the overhead of deferred loading. By
default deferred loading requires mapping `loadLibrary` calls to a list
of modules. This requires including (1) library uris, (2) prefix names
and (3) module names directly in the main module. With this loading
modules is easier as the loading function gets the exact filename.
Load ids provide an alternative approach where the compiler emits a
separate file mapping a load ID to the module set required for that ID.
An app could store this mapping on the server allowing the frontend to
include only the load ID in its request and have the server figure out
which modules to send back.
Internal serving infra uses module sets like this so this change allows
easier integration into that tooling. Dart2js already supports emitting
this deferred mapping JSON and internal infra is using that today.
Other changes include:
- Run the deferred loading transformer after TFA. This will exclude unused libraries in the resulting deferred loading map. Mark deferred helpers as entry points so that they don't get tree-shaken.
- Some changes to naming conventions of JS helpers.
- Use filename as module name to simplify JS helpers
Change-Id: I5e2f5e374de77c87095d08bfff6534506cb10652
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/454240
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
To enable this for pkg/dart2bytecode/bin/dart2bytecode:
dart2bytecode --bytecode-options=script-file-contents ...
This option is disabled by default, but enabled by the bytecode kernel
service and by the test runner when running in non-product
configurations.
TEST=pkg/vm_service/test/local_variable_declaration
Cq-Include-Trybots: luci.dart.try:vm-dyn-linux-debug-x64-try,vm-aot-dyn-linux-debug-x64-try,vm-aot-dyn-linux-product-x64-try,vm-dyn-mac-debug-arm64-try
Change-Id: Ibeeb7d212f6be27002b972d67867b2581d97a0aa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/449860
Commit-Queue: Tess Strickland <sstrickl@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Alexander Markov