Also fix --check-clean. `ninja target -t commands` reports the commands for the default target, fix to use `ninja -t commands target` instead.
Change-Id: Ice179290e75b083a96abadb7540ca960eafcc982
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/510440
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
- Break false dependency of non-VM platforms on VM platform
- Break false dependency of bootstrap gen_kernel on VM platform
- Extend precompile_tools to gen_kernel steps
- Rename intermediate kernel files so JIT versus AOT is visible in ninjatracing
TEST=ci
Change-Id: I07011abe8303597af61d2b8c73e788b661482cc0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/510060
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Extend --check-clean (enabled on bots) to verify build commands don't include absolute paths.
The non-RBE GCC and MSVC builds still have absolute paths. GCC doesn't have -ffile-compilation-dir so it uses -fdebug-prefix-map, which is not fixable. The MSVC build has absolute path in the toolchain wrappers, which might be fixable.
TEST=ci
Change-Id: I3b984aaab7aefa7ff527f0a039ca42281224a09d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/506505
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Ryan Macnak <rmacnak@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>
- Document which target needs to be built for the test
`web/wasm/ffi/ffi_native`.
- Add tests that passes and expects `double` and `float`s.
(The `sqrt` native function was previous unused)
- Define inputs in `wasm_module` gn template so that the
`ffi_native_test_wasm_module` target will rebuild the Wasm file when
`tests/web/wasm/ffi/ffi_native_test_module.c` changes.
Change-Id: Iff642ff2cdee48a617e8f2cf4cca4053122a7e05
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/384263
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
The type category table is a O(number-of-classes) sized byte array that
maps from class-id to either a type category (function, record, ...) or
a masqueraded class-id.
* for flute this table takes up around 1 KB.
* this prevents from making concrete class-ids come before all abstract
class ids
After recent changes the core RTT implementation no longer involves
masqueraded types (i.e. `<obj> is/as <type>` and `<type> <: <type>`
queries don't trigger masquerading functionality)
This CL removes the type category table, the special casing in the
class-id assignment and the compiler support for building the table.
Instead we move the logic to pure dart code, which can use normal `is`
checks to perform its function.
We add one optimization: The compiler will provide the class-id from
which one only non-masqueraded classes come. This makes the masquerading
function have a fast path.
* We use `Wasm{TypedData,String}Base` marker interfaces i
`dart:_internal` to check for wasm-backed implementations
* We use `-Ddart.wasm.js_compatibility` to provide JSCM mode
We add a test that actually exercises the 2 modes.
Change-Id: I051c35b17878950402a1336df871a686b649f732
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/349641
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
stringref target won't be used any time soon (probably ever). To help
with build times and avoid keeping it updated remove it for now.
Change-Id: I0df33b7ab2e19bae5090e8ea32ea6a3dc3751652
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/334881
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
The purpose of the wasm_js_compatibility target is to facilitate experiments with a JS compatibility mode for Dart2Wasm. Initially, we're just going to focus on typed data, but this will give us a place to experiment with moving List and String to JS as well.
In addition, someday down the road we hope to experiment with two additional compatibility changes:
1) Exclusively using double for all Dart numbers
2) Allowing undefined to flow as null.
The two major benefits of this approach are:
1) Much faster JS interop
2) To make it easier to bring up Dart2JS applications on Dart2Wasm
The only downside will be access overhead on the Wasm side, but the JS builtins proposal could potentially bring us close to parity with Wasm builtins someday.
Tested: Wasm specific trivial refactor.
Change-Id: I2c09426b6999507c1de6e584e9bc7072a088bda9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/313240
Commit-Queue: Joshua Litt <joshualitt@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
Reviewed-by: William Hesse <whesse@google.com>
This adds basic infrastructure for a stringref implementation in
dart2wasm:
- A `--[no-]stringref` option to the compiler
- An option in the `WasmTarget`, controlling the name of the target
- Separate sets of patch files for the two targets
- Separate platform dill files for the two targets
For now, the patch file contents are the same, and the compiler flag
is not used by the backend (only by the `dart2wasm` script to select
the appropriate platform dill file). Both of these will change as the
implementation progresses.
Tested: ci + manual check that the option selects the correct dill
Change-Id: I2c9bb95ba06fd3de3f7007703ef545e3f0c728ba
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/310621
Commit-Queue: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
The `dartaotruntime` is built in `product` mode even when we do a release build. This CL wires up a product flag so we always build the Dart2Wasm product snapshot when creating the SDK.
Change-Id: Ic8c6a6da180a47a19ba818d7c449f712c9e60123
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/264887
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Joshua Litt <joshualitt@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
This CL introduces a new kernel-to-kernel pass in Wasm backend to
compile `FfiNative`-annotated external functions to external functions
with `wasm:import` pragmas.
The new pass `WasmFfiNativeTransformer` extends `FfiNativeTransformer`.
Some `FfiNativeTransformer` methods made public to allow reuse in the
pass.
The conversion works like this: when we see a member like:
@FfiNative<Int8 Function(Int8, Int8)>("ffi.addInt8")
external int addInt8(int a, int b);
We generate a Wasm import using Wasm ABI types according to emscripten
calling conventions:
@pragma('wasm:import', 'ffi.addInt8')
external static WasmI32 addInt8_$import(WasmI32 a, WasmI32 b);
and convert the original member (`addInt8()`) to a wrapper function that
calls the Wasm import, converting the arguments and return values to
Dart types:
static int addInt8(int a, int b) {
return WasmI32.toIntSigned(
addInt8_$import(
WasmI32::int8FromInt(a),
WasmI32::int8FromInt(b),
));
}
Build, test, and CI changes:
- Test runner now uses `// SharedObjects=...` lines in dart2wasm tests
to pass extra Wasm modules to d8 command used to run the tests.
Support for `// SharedObjects=...` lines were already used in
native/AOT FFI tests, not added in this CL. We just start to use those
lines in dart2wasm tests.
- dart2wasm gn file updated with a target "test_wasm_modules" that
builds FFI test Wasm modules to Wasm using emcc (emscripten C
compiler).
- CI dart2wasm_hostasserts configuration updated to copy the Wasm files
generated by the "test_wasm_modules" target to the shards.
TEST=tests/web/wasm/ffi_native_test
Change-Id: I6527fe4e2ca2b582e16d84fee244e9cbe6dee307
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/252822
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
This adds a --platform= option to dart2wasm to read the SDK libraries
from that dill file instead of compiling them from source every time.
If the option is not given, the SDK libraries are compiled, like before.
Also adds a "dart2wasm" build target, which will build the dart2wasm
platform dill and compile dart2wasm to two AOT snapshots (with and
without asserts). The dart2wasm scripts in sdk/bin are updated to run
via these snapshots and use this platform dill.
This speeds up test runs for the dart2wasm-hostasserts-linux-x64-d8
configuration by approximately 45x.
Change-Id: If2c7750a6eb39725310745f887792784d0dfc583
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/243624
Commit-Queue: Aske Simon Christensen <askesc@google.com>
Reviewed-by: William Hesse <whesse@google.com>
Reviewed-by: Joshua Litt <joshualitt@google.com>
Ryan Macnak