Question about export naming convention in core module

[tanishiking]

Hi, I am working on adding support for standalone Wasm in Scala.js using WASIp2, and am planning to use wasm-tools to transform a core module into a component.

For reference, I’ve been playing around with the WAT representations of component binaries in Rust and moonbit.
And it turned out, it seems that to implement and export the run function for wasi:cli/[email protected] for example, the core Wasm binary must use an export name in the form of <interface>#<function name>. For example:

(export "wasi:cli/[email protected]#run" (func 41))

If the function is exported under any other name, the wasm-tools component new command fails with an error:

error: failed to encode a component from module

Caused by:
    0: failed to decode world from module
    1: module was not valid
    2: failed to find export of interface `wasi:cli/[email protected]` function `run`

Based on this, I assume that when implementing a core Wasm module for such interfaces, wasm-tools expects functions to be exported with the <interface>#<function name> naming convention.

• Is this assumption about naming convention correct?
• If so, is this naming convention (or specification?) documented anywhere?
  • Is it specific to wasm-tools?

Sorry if this issue should go to wasm-tools rather than here.

[alexcrichton]

The name here is specific to wasm-tools and if you can avoid it I might recommend doing so as it's a "temporary standard" that should one day go away. Instead the naming defined in #378 should work, so for this it would be cm32p2|_ex_wasi:cli/[email protected]|main for an export name. The current wasm-tools should support this as well, it's just that other languages aren't using it yet as they're waiting for the wasm-tools change to propagate.

[tanishiking]

That's great to hear that there will be a standard specification for what the core module should look like in a componentized context.
Indeed, the wasm-tools repository has comments pointing to #378 here and there, and it already has an implementation for #378. 👀

Thank you for letting me know :) closing