Open sigmundch opened 4 months ago
I think wasm:import
and wasm:export
should both be locked down to the SDK via a check. IIRC, the former is to call out to JS functions defined in the instance from Wasm and the latter is to call dart2wasm functions from JS. Both mechanisms rely on unique names so having users be able to use this will likely lead to collisions somewhere. It's also a bit wonky for users to even be able to expose the JS function properly in the case of wasm:import
and the Wasm function in the case of wasm:export
. JS interop does what users need here anyways.
It looks like skwasm uses these mechanisms already, so we can allowlist that code. Should we lock down any of the other wasm:
pragmas?
I'm also not sure what the plan is for dart:ffi
for Wasm to Wasm interop and if this is something that's needed for that.
Yes, I think for now this should be internal.
From a conceptual view, there should be two/three different mechanisms
dart:wasm
=> The types involved should probably be restricted to Wasm/WasmGC types
=> Apps running (in the future) in a pure wasm runtime (without JS) could use this.dart:ffi
=> The types involved should probably be restricted to be C types
=> Possibly an extension of C types (the VM has e.g. Handle
, we may need something similar for opaque wasm functions/objects)
=> This is a higher abstraction layer: When emscripten compiles C code to linear-memory wasm it encodes C types in a certain way to a wasm abi, our dart:ffi
-like abstraction will then know how a dart C api can be lowered to the same emscription wasm abi (both for calling convention, struct layout, etc)I agree, Wasm interop pragmas should be internal.
@osa1 Could you change dart2wasm to only recognize @pragma('wasm:import')
& @pragma('wasm:export')
for dart:*
libraries? (I would assume any usage in flutter engine will be inside dart:*
libraries as well)
We discussed this a bit today, we also want to limit @Native
usage to Flutter engine and SDK, as it was never intended as a general way to interact with any Wasm module. We will have a different mechanism for that.
With this we can also reopen #37355 until we have this new mechanism to interact with other Wasm modules.
In wasm you can use JS-interop or
wasm:*
pragmas to import and export symbols. This can be a source of inconsistencies and confusion (e.g. see https://github.com/dart-lang/sdk/issues/55715).Some questions:
cc @srujzs @mkustermann @osa1