Align with the "C" ABI

[daxpedda]

Motivation

We are currently using a non-standard ABI (there isn't really a standardized one) for Wasm exports, which currently Rust is mimicking: rust-lang/rust#71871.

This has the big disadvantage of making the wasm32-unknown-unknown backend ABI incompatible with wasm32-wasi and wasm32-unknown-emscripten. Which in turn makes wasm-bindgen not compatible with any C/C++ dependency: #2317.

Plan

1. Make wasm-bindgen follow the C ABI outlined here: https://github.com/WebAssembly/tool-conventions/blob/main/BasicCABI.md. Which mainly involves removing splatting.
2. Let users try it out with a compiler flag in Rust. (Introduce perma-unstable wasm-c-abi flag rust-lang/rust#117919: -Zwasm-c-abi)
3. Figure out a migration path for users. (Add wasm_c_abi future-incompat lint rust-lang/rust#117918)
4. Move the wasm32-unknown-unknown target to the C ABI.
5. (optional) Introduce a flag to wasm-bindgen that uses the unstable "wasm" ABI: Tracking issue for the unstable "wasm" ABI rust-lang/rust#83788.

Result

It should be possible to compile Rust with wasm32-unknown-unknown while consuming Emscripten and WASI dependencies correctly, which would also partially address #3421. I know nothing about Emscripten, but WASI would require some additional hook ups to support it's API, which we should probably (help) support as well.

Downsides

There is a reason why the ABI differs, splatting is a performance improvement and the C ABI has no support for multi-value. Hopefully this can be addressed in the future and a better ABI can be agreed on. In the meantime users can use the "wasm" ABI on nightly to opt into splatting without us having to break C compatibility for everybody else.

[alexcrichton]

One possible solution I've thought may work in the past is that there could be something like:

pub trait IntoWasmAbi: WasmDescribe {
    type Abi1: WasmAbi;
    type Abi2: WasmAbi;

    fn into_abi(self) -> (Self::Abi1, Self::Abi2);
}

where most impls have type Abi2 = (); and extern "C" fn foo(_: ()) ends up not having any arguments in wasm (e.g. the () argument is elided). That would require a lot of plumbing in the macro, however, but should probably get the splat behavior desired here (I think, at least for strings, I'm not sure for optional things)

[temeddix]

Is this fixed with #3595? Or are there additional steps needed?

[daxpedda]

See OP.
I believe the next step to take is migrating rustc to the new ABI.

[ranile]

@Liamolucko did #3595 check off the first part of the plan mentioned in this issue? If so, can you check it off in the issue as well

[Liamolucko]

@Liamolucko did #3595 check off the first part of the plan mentioned in this issue? If so, can you check it off in the issue as well

Yes.

[temeddix]

I'm not an expert here, please excuse me for basic questions.

The next step is written as "Move the wasm32-unknown-unknown target to the C ABI.". Does this mean that new C ABIs produced by wasm-bindgen when running cargo build are going to change? Would this be a small work or a major rewrite?