Adds a new `@Array.variable()` to specify that the last element of
structs is a variable length inline array.
This CL does not add any checks for passing structs with variable
length inline arrays by value or directly calling them with
`AllocatorAlloc.call`. Instead, the implementation defaults to what
C does, allocate as if there are 0 elements in the variable length
inline array.
TEST=tests/ffi/*
CoreLibraryReviewExempt: VM only
Closes: https://github.com/dart-lang/sdk/issues/55964
Change-Id: I524d8a1d710b1a744b392e05fa884908c3ff1f12
Cq-Include-Trybots: dart/try:vm-aot-android-release-arm64c-try,vm-aot-android-release-arm_x64-try,vm-aot-asan-linux-release-x64-try,vm-aot-linux-debug-x64-try,vm-aot-linux-debug-x64c-try,vm-aot-mac-release-arm64-try,vm-aot-mac-release-x64-try,vm-aot-msan-linux-release-x64-try,vm-aot-obfuscate-linux-release-x64-try,vm-aot-optimization-level-linux-release-x64-try,vm-aot-tsan-linux-release-x64-try,vm-aot-ubsan-linux-release-x64-try,vm-aot-win-debug-arm64-try,vm-aot-win-debug-x64-try,vm-aot-win-debug-x64c-try,vm-appjit-linux-debug-x64-try,vm-asan-linux-release-arm64-try,vm-asan-linux-release-x64-try,vm-checked-mac-release-arm64-try,vm-eager-optimization-linux-release-ia32-try,vm-eager-optimization-linux-release-x64-try,vm-ffi-android-debug-arm-try,vm-ffi-android-debug-arm64c-try,vm-ffi-qemu-linux-release-arm-try,vm-ffi-qemu-linux-release-riscv64-try,vm-fuchsia-release-arm64-try,vm-fuchsia-release-x64-try,vm-linux-debug-ia32-try,vm-linux-debug-x64-try,vm-linux-debug-x64c-try,vm-mac-debug-arm64-try,vm-mac-debug-x64-try,vm-msan-linux-release-arm64-try,vm-msan-linux-release-x64-try,vm-reload-linux-debug-x64-try,vm-reload-rollback-linux-debug-x64-try,vm-tsan-linux-release-arm64-try,vm-tsan-linux-release-x64-try,vm-ubsan-linux-release-arm64-try,vm-ubsan-linux-release-x64-try,vm-win-debug-arm64-try,vm-win-debug-x64-try,vm-win-debug-x64c-try,vm-win-release-ia32-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/371960
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
When iterating on core library changes or changes in the AOT compiler
many seconds are wasted waiting on gen_kernel/compile_platform to
parse Dart code. This happens because we are running these tools
from sources on prebuilt Dart SDK.
This CL allows SDK developer to opt-in into AOT compiling these
tools by adding `precompile_tools=true` to their DART_GN_ARGS.
AOT compilation is performed using prebuilt SDK - so these
executables do not need to be recompiled if core libraries or
VM changes reducing iteration cycles.
pkg/vm/tool/precompiler2 is tweaked to detect when DART_GN_ARGS
contains `precompile_tools=true` and use precompiled
gen_kernel.exe instead of running it from source.
Using precompiled compile_platform takes vm_platform_strong.dill
build from 20 seconds to 3 seconds.
Using precompiled gen_kernel takes small benchmark build from
~10 seconds to 2 seconds.
This relands 5cda2a871c with fixes
for Flutter build.
TEST=manually tested
Change-Id: I552861c80c152890655e41baaf6ea3fb3b03a57e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/367961
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
This reverts commit 5cda2a871c.
Reason for revert: broke Flutter build.
Original change's description:
> [tools] Allow precompiling gen_kernel and compile_platform
>
> When iterating on core library changes or changes in the AOT compiler
> many seconds are wasted waiting on gen_kernel/compile_platform to
> parse Dart code. This happens because we are running these tools
> from sources on prebuilt Dart SDK.
>
> This CL allows SDK developer to opt-in into AOT compiling these
> tools by adding `precompile_tools=true` to their DART_GN_ARGS.
>
> AOT compilation is performed using prebuilt SDK - so these
> executables do not need to be recompiled if core libraries or
> VM changes reducing iteration cycles.
>
> pkg/vm/tool/precompiler2 is tweaked to detect when DART_GN_ARGS
> contains `precompile_tools=true` and use precompiled
> gen_kernel.exe instead of running it from source.
>
> Using precompiled compile_platform takes vm_platform_strong.dill
> build from 20 seconds to 3 seconds.
>
> Using precompiled gen_kernel takes small benchmark build from
> ~10 seconds to 2 seconds.
>
> TEST=manually tested
>
> Change-Id: Ieec6ad4e1081023d140eb744f0a3cd0c754414ca
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/367940
> Commit-Queue: Slava Egorov <vegorov@google.com>
> Reviewed-by: Martin Kustermann <kustermann@google.com>
Change-Id: Id3e4eb44d33516f31c165d9a1e55911e8d356e7f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/367960
Commit-Queue: Slava Egorov <vegorov@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
When iterating on core library changes or changes in the AOT compiler
many seconds are wasted waiting on gen_kernel/compile_platform to
parse Dart code. This happens because we are running these tools
from sources on prebuilt Dart SDK.
This CL allows SDK developer to opt-in into AOT compiling these
tools by adding `precompile_tools=true` to their DART_GN_ARGS.
AOT compilation is performed using prebuilt SDK - so these
executables do not need to be recompiled if core libraries or
VM changes reducing iteration cycles.
pkg/vm/tool/precompiler2 is tweaked to detect when DART_GN_ARGS
contains `precompile_tools=true` and use precompiled
gen_kernel.exe instead of running it from source.
Using precompiled compile_platform takes vm_platform_strong.dill
build from 20 seconds to 3 seconds.
Using precompiled gen_kernel takes small benchmark build from
~10 seconds to 2 seconds.
TEST=manually tested
Change-Id: Ieec6ad4e1081023d140eb744f0a3cd0c754414ca
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/367940
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Include gen_snapshot and platform dill targets to runtime_precompiled to ensure this target can be used separately without runtime target when working on AOT tests.
Avoiding runtime target saves time building unneccessary snapshots.
Change-Id: Ib6583772f47af1eecaf9a9849b3966461982502f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/365870
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
Users of our standalone embedders we distribute in the Dart SDK should
be using `dart_api_dl.h` (and initialize it from
the `dart:ffi`s `NativeApi.initializeApiDLData`)
If there's any API functions missing, we can add them.
Though we should not Dart C API symbols that are only relevant for
embedders. It requires a custom embedder implementation (which is
outside the scope of what we distribute in Dart SDK)
Issue https://github.com/dart-lang/sdk/issues/40579
TEST=ci
Change-Id: I6f3842668c59a5dd6fefc6857581995501b9b0e0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352820
Reviewed-by: Slava Egorov <vegorov@google.com>
This is a reland of commit 0a393f1b69
The problem was that the checks for whether or not dartaotruntime
existed were always returning false on Windows because the ".exe" suffix
wasn't being taken into account. Patchset 2 addresses this.
Original change's description:
> [ DDS ] Fix DDS AOT snapshot build rules
>
> dds_aot.dart.snapshot was not being generated for runtime build targets,
> and dds.dart.snapshot was being built regardless of whether or not we
> were building for an IA32 target.
>
> This change also adds a check for IA32 in 'dart run' so the "Could not
> find dds_aot.dart.snapshot. Have you built the full Dart SDK?" message
> isn't printed when we fall back to using dds.dart.snapshot.
>
> This change also reverts 2cc08595a6, which
> failed to fix the issue it was attempting to fix.
>
> TEST=pkg/vm_service tests
>
> Change-Id: Ic990082c25b0d022093ad66600332dfb2878709f
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/341760
> Reviewed-by: Siva Annamalai <asiva@google.com>
> Commit-Queue: Ben Konyi <bkonyi@google.com>
TEST=pkg-win-release-try, pkg-win-release-arm64-try, and pkg/vm_service
tests
Change-Id: Ieab41edcb6bffca3be6bf628e357871f28949323
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/342640
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Derek Xu <derekx@google.com>
This reverts commit 0a393f1b69.
Reason for revert: breaks dartdev on Windows
Original change's description:
> [ DDS ] Fix DDS AOT snapshot build rules
>
> dds_aot.dart.snapshot was not being generated for runtime build targets,
> and dds.dart.snapshot was being built regardless of whether or not we
> were building for an IA32 target.
>
> This change also adds a check for IA32 in 'dart run' so the "Could not
> find dds_aot.dart.snapshot. Have you built the full Dart SDK?" message
> isn't printed when we fall back to using dds.dart.snapshot.
>
> This change also reverts 2cc08595a6, which
> failed to fix the issue it was attempting to fix.
>
> TEST=pkg/vm_service tests
>
> Change-Id: Ic990082c25b0d022093ad66600332dfb2878709f
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/341760
> Reviewed-by: Siva Annamalai <asiva@google.com>
> Commit-Queue: Ben Konyi <bkonyi@google.com>
Change-Id: I479a026184fc1fe27926d1ab0d7d3221dec3130e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/342440
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Derek Xu <derekx@google.com>
dds_aot.dart.snapshot was not being generated for runtime build targets,
and dds.dart.snapshot was being built regardless of whether or not we
were building for an IA32 target.
This change also adds a check for IA32 in 'dart run' so the "Could not
find dds_aot.dart.snapshot. Have you built the full Dart SDK?" message
isn't printed when we fall back to using dds.dart.snapshot.
This change also reverts 2cc08595a6, which
failed to fix the issue it was attempting to fix.
TEST=pkg/vm_service tests
Change-Id: Ic990082c25b0d022093ad66600332dfb2878709f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/341760
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Ben Konyi <bkonyi@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>
Build one package with three elf_test_runner components: one for each of the binaries that the test harness invokes on the target. (Though currently only tests that use "dart" are setup.)
Create includable CML shards for the capabilites required by the AOT and JIT VMs.
Fold test_runner's fuchsia_cfv2.dart back into fuchsia.dart.
TEST=ci
Bug: https://github.com/dart-lang/sdk/issues/38752
Change-Id: I7bd8d43d184cbcb11903c7aed77ce31fb30cb894
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332451
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Zijie He <zijiehe@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
This change created a CFv2 build target and provided two
implementations of the FuchsiaEmulator, so that I can continually work
on both CFv2 build and test script integration independently.
The v2 target can be built with
```
tools/build.py --os fuchsia --mode release fuchsia_ffi_test_package_cfv2
```
And v2 FuchsiaEmulator implementation can be triggered with
FUCHSIA_CFV2 environment variable.
Bug: #38752
Change-Id: I31936a2ca967fbfeb2bc5628e2f005aef6762687
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/322583
Reviewed-by: Alexander Thomas <athom@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Zijie He <zijiehe@google.com>
The `sdk:copy_full_sdk_snapshots` target is dependent on
`utils/dartdev:dartdev` and `utils/dds:dds`, so these targets have been
getting built anyways when building the SDK.
TEST=Confirmed that
`./tools/build.py -mdebug -aarm_x64 --os=android create_sdk` does not
crash.
Fixes: https://github.com/dart-lang/sdk/issues/41776
Change-Id: I356218e542313f393ff2ea812d761ab8868955d8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/322520
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Derek Xu <derekx@google.com>
- Introduces a new output subdirectory `gen/utils/ddc` where the
new build targets output files. This is intended to make the
migration to the new assets easier since landing this change
shouldn't immediately break any dependencies.
- Enables building the canary and stable assets at the same time.
- Changes more names in our workflow from "dartdevc" to "ddc".
- Updates the ddc-canary-linux-chrome and
ddc-canary-linux-chrome-unsound configurations to use the
new assets.
The new outputs appear in directories that are more consistently
named, (no more sound vs kernel confusion). They are named in
preparation for the eventual deletion of the unsound targets
without any lingering cruft to be cleaned up in the sound
directories.
The new structure is:
```
gen/utils/ddc/
|- canary
| |- pkg
| |- sdk
|- canary_unsound
| |- pkg
| |- sdk
|- stable
| |- pkg
| |- sdk
|- stable-unsound
|- pkg
|- sdk
```
The 'pkg' and 'sdk' directories all contain outputs with the same
files names, each compiled in the respective build modes
(sound/unsound and stable/canary).
Change-Id: I66822ebf03bba487b6d359a8e0aa818b9e7b6bef
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/313081
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nicholas Shahan <nshahan@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>
This should make vm/dart_2/analyze_snapshot_binary_test pass on
dartkp-linux-release-arm64 & dartk-linux-release-arm64
by ensuring arm64 `gen_snapshot` & `analyze_snapshot` binaries
are available on the device when running tests on arm64 HW.
Change-Id: Icd814ff6df22a33b651733e4c3dc99873cf56a58
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/279970
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Updated strictness on build configuration for analyze_snapshot
Will run only under Linux/Android 64 bit arm, arm64c, simarm64,
simarm64c and x64 architectures.
analyze_snapshot just has a single target that links into product precompiled programatically
Testing suite updated to comply with null-safety requirements and
fix for simulated platform failing to use gen_snapshot with assembly.
TEST=ci
Change-Id: I3d58400db2e26a441a40fe7197b22510a52732b6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/279391
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Chris Evans <cmevans@google.com>
We use binaryen from googlesource mirror with commits that have already
been rolled into g3.
Since binaryen doesn't come with GN files (it uses cmake), we add
our own in third_party/binaryen/BUILD.gn.
TEST=ci
Change-Id: Iee5c37c9d391ee41dc57250d7a33177cbe9ed2aa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/270640
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Aske Simon Christensen <askesc@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>
This is a reland of 19e5749308
TEST=runtime/tests/vm/dart/analyze_snapshot_binary_test.dart
Original change's description:
> [vm] Add analyze_snapshot tool for AOT snapshot inspection
>
> Current skeleton to allow for instrumentation snapshots that can be
> built alongside Dart compilation artifacts and easily referenced for
> specific versions between Snapshot hash <-> DartSDK <-> Flutter Engine
>
> TEST=runtime/tests/vm/dart/analyze_snapshot_binary_test.dart
>
> Change-Id: Ie3757a265bbf457506c72fb62a625fea7bedcb68
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/221087
> Reviewed-by: Slava Egorov <vegorov@google.com>
> Commit-Queue: Slava Egorov <vegorov@google.com>
Change-Id: Ia1ea0071d30818440ae48484ff6c406236af5a4e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/224526
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
Current skeleton to allow for instrumentation snapshots that can be
built alongside Dart compilation artifacts and easily referenced for
specific versions between Snapshot hash <-> DartSDK <-> Flutter Engine
TEST=runtime/tests/vm/dart/analyze_snapshot_binary_test.dart
Change-Id: Ie3757a265bbf457506c72fb62a625fea7bedcb68
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/221087
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
Alexander Markov