Tracking issue for the unstable "wasm" ABI

[alexcrichton]

This issue is intended to track the stabilization of the "wasm" ABI added in #83763. This new ABI is notably different from the "C" ABI where the "C" ABI's purpose is to match whatever the C ABI for the platform is (in this case whatever clang does). The "wasm" ABI, however, is intended to match the WebAssembly specification and should be used for functions that need to be exported/imported from a wasm module to precisely match a desired WebAssembly signature.

One of the main features of the "wasm" ABI is that it automatically enables the multi-value feature in LLVM which means that functions can return more than one value. Additionally parameters are never passed indirectly and are always passed by-value when possible to ensure that what was written is what shows up in the ABI on the other end.

It's expected that one day the "C" ABI will be updated within clang to use multi-value, but even if that happens the ABI is likely to optimize for the performance of C itself rather than for binding the WebAssembly platform. The presence of a "wasm" ABI in Rust guarantees that there will always be an ABI to match the exact WebAssembly signature desired.

Another nice effect of stabilizing this ABI is that the wasm32-unknown-unknown target's default C ABI can be switched back to matching clang. This longstanding mismatch is due to my own personal mistake with the original definition and the reliance on the mistake in wasm-bindgen. Once the "wasm" ABI is stable, however, I can switch wasm-bindgen to using the "wasm" ABI everywhere and then the compiler can switch the default ABI of the wasm32-unknown-unknown target to match the C ABI of clang.

[wleslie]

For folks wanting to give this a try, is there an experimental branch of wasm-bindgen that uses this "wasm" ABI?

[alexcrichton]

There is not a branch at this time, no.

[joshtriplett]

What is the current state of this? Is there wasm-bindgen support or tooling support for this? Is anything using this?

cc @alexcrichton

[memoryruins]

@joshtriplett

Is anything using this?

Searching sourcegraph and github, I've so far only found one project previously using it then switched to "C" ABI due to a couple of issues oasisprotocol/oasis-sdk#561

• problems with u128 Broken WASM codegen with u128 and wasm_abi #88207
• problems with compiling multivalue functions https://github.com/ptrus/wasm-bug (todo: should probably open an upstream issue for this)

[alexcrichton]

The wasm-bindgen crate hasn't updated to using this since it requires nightly Rust and it otherwise wants to compile on stable. I'm otherwise unaware of any other tooling using this myself.

[joshtriplett]

@alexcrichton Is there a chicken and egg problem there? I think we were waiting to consider stabilization until it was clear this was being used. :)

[alexcrichton]

Personally I think this is more of a "what is C going to do" problem for stabilization. I don't think Rust is in the position to blaze a trail here when C/C++ otherwise can't access it. One of the main purposes of this ABI is to give access to the ability to define a multi-return function in WebAssembly, but C/C++ have no corresponding mechanism to do that. Until C/C++ figure out how they're going to return multiple values then multi-return is unlikely to be used in the wasm ecosystem so stabilizing this wouldn't provide much benefit. Additionally if this were stabilized and then C/C++ picked a different way to use multi-return then that would be yet-another ABI that Rust would have to implement.