Files
sdk/pkg
Ömer Sinan Ağacan affc3392a0 [dart2wasm] Implement Wasm FfiNative support
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>
2022-09-23 09:41:22 +00:00
..
2022-09-23 05:37:39 +00:00
2022-09-23 05:37:39 +00:00
2022-09-16 19:35:00 +00:00
2022-09-23 05:37:39 +00:00
2022-09-23 05:37:39 +00:00
2022-09-16 19:35:00 +00:00
2022-07-25 12:21:59 +00:00
2022-07-29 18:11:01 +00:00

Package validation

The packages in pkg/ are automatically validated on the LUCI CI bots. The validation is largely done by the tools/package_deps package; it can be tested locally via:

dart tools/package_deps/bin/package_deps.dart

Packages which are published

There are several packages developed in pkg/ which are published to pub. Validation of these packages is particularly important because the pub tools are not used for these packages during development; we get our dependency versions from the DEPS file. Its very easy for the dependencies specified in a package's pubspec file to get out of date wrt the packages and versions actually used.

In order to better ensure we're publishing correct packages, we validate some properties of the pubspec files on our CI system. These validations include:

  • that the dependencies listed in the pubspec are used in the package
  • that all the packages used by the source are listed in the pubspec
  • that we don't use relative path deps to pkg/ or third_party/ packages

Packages which are not published

For packages in pkg/ which we do not intend to be published, we put the following comment in the pubspec.yaml file:

# This package is not intended for consumption on pub.dev. DO NOT publish.
publish_to: none

These pubspecs are still validated by the package validation tool. The contents are more informational as the pubspecs for these packages are not consumed by the pub tool or ecosystem.

We validate:

  • that the dependencies listed in the pubspec are used in the package
  • that all the packages used by the source are listed in the pubspec
  • that a reference to a pkg/ package is done via a relative path dependency