interop & wasm: reconcile import and export mechanisms

[sigmundch]

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 #55715).

Some questions:

• Do we want to generalize any of these mechanisms. For example, should wasm:export become a more general purpose export mechanism that we also support for JS programs?
• Do want want to provide better guidelines and documentation for when to use which?
• Do we want to add static checks to restrict the use. For example, should wasm:import only be used for the internal wasm runtime? Or maybe for dart:ffi support?

cc @srujzs @mkustermann @osa1

[srujzs]

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.

[mkustermann]

Yes, I think for now this should be internal.

From a conceptual view, there should be two/three different mechanisms

• Interop with JS code: The import/export mechanism should be provided by the new JS interop
  => The types involved should probably be restricted to JS interop types.
• Interop with Wasm/WasmGC code: The import/export mechanism may be provided by e.g. 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.
• Interop with C code: The import/export mechanism may be provided by something similar to 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)

[osa1]

I agree, Wasm interop pragmas should be internal.

[mkustermann]

@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)

[osa1]

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.