rustc: Add a new wasm ABI

[alexcrichton]

This commit implements the idea of a new ABI for the WebAssembly target,
one called "wasm". This ABI is entirely of my own invention
and has no current precedent, but I think that the addition of this ABI
might help solve a number of issues with the WebAssembly targets.

When wasm32-unknown-unknown was first added to Rust I naively
"implemented an abi" for the target. I then went to write wasm-bindgen
which accidentally relied on details of this ABI. Turns out the ABI
definition didn't match C, which is causing issues for C/Rust interop.
Currently the compiler has a "wasm32 bindgen compat" ABI which is the
original implementation I added, and it's purely there for, well,
wasm-bindgen.

Another issue with the WebAssembly target is that it's not clear to me
when and if the default C ABI will change to account for WebAssembly's
multi-value feature (a feature that allows functions to return multiple
values). Even if this does happen, though, it seems like the C ABI will
be guided based on the performance of WebAssembly code and will likely
not match even what the current wasm-bindgen-compat ABI is today. This
leaves a hole in Rust's expressivity in binding WebAssembly where given
a particular import type, Rust may not be able to import that signature
with an updated C ABI for multi-value.

To fix these issues I had the idea of a new ABI for WebAssembly, one
called wasm. The definition of this ABI is "what you write
maps straight to wasm". The goal here is that whatever you write down in
the parameter list or in the return values goes straight into the
function's signature in the WebAssembly file. This special ABI is for
intentionally matching the ABI of an imported function from the
environment or exporting a function with the right signature.

With the addition of a new ABI, this enables rustc to:

• Eventually remove the "wasm-bindgen compat hack". Once this multivalue
  ABI is stable wasm-bindgen can switch to using it everywhere.
  Afterwards the wasm32-unknown-unknown target can have its default ABI
  updated to match C.

• Expose the ability to precisely match an ABI signature for a
  WebAssembly function, regardless of what the C ABI that clang chooses
  turns out to be.

• Continue to evolve the definition of the default C ABI to match what
  clang does on all targets, since the purpose of that ABI will be
  explicitly matching C rather than generating particular function
  imports/exports.

Naturally this is implemented as an unstable feature initially, but it
would be nice for this to get stabilized (if it works) in the near-ish
future to remove the wasm32-unknown-unknown incompatibility with the C
ABI. Doing this, however, requires the feature to be on stable because
wasm-bindgen works with stable Rust.

[rust-highfive]

r? @matthewjasper

(rust-highfive has picked a reviewer for you, use r? to override)

[nagisa]

Are there any alternatives to adding a temporarily useful (AFAICT? Or is the plan that bindgen continues to use this ABI for a long time to come?) ABI string for effectively forever?

The goal here is that whatever you write down in
the parameter list or in the return values goes straight into the
function's signature in the WebAssembly file.

This sounds a lot like the existing "unadjusted" ABI, though as far as I can tell for wasm specifically it sets the +multivalue feature as well. Is there any reason multivalue shouldn't be a part of the target_feature system instead?

[alexcrichton]

Sorry if this wasn't clear from the description, but my intention is that this is eventually a long-lasting and stable ABI. If your desire is to match C you'd use extern "C", but if your desire is to match or conform to a WebAssembly specification you'd use this new ABI.

After I posted this I realized that the name "wasm-multivalue" is probably too wordy and too temporary for this concept, and I might actually propose "wasm" instead. The multivalue part is here because LLVM hasn't enabled multivalue by default, but AFAIK almost all other runtimes have implemented it. Eventually wasm targets need to move towards using multivalue returns and I figured that this is a good place to start doing that. The "wasm" abi (if we change the name) would be defined in terms of the online specification, which has support for multiple returns.

Note that multivalue is part of the target_feature system already. I figured that if a new ABI is being added it would be good to unconditionally use it, so I went ahead and automatically enabled it for this new ABI.

[nagisa]

I see. extern "wasm" makes much more sense to me then, yes.

There's a conflicting interaction between extern "wasm" unconditionally enabling multivalue and user explicitly requesting #[target_feature(disable="multivalue")]. Should error in that case or something.

Otherwise no other concerns from me and I'm happy to approve landing this.

[alexcrichton]

Ok sounds good! I've renamed the ABI to "wasm", added tests, updated existing tests, and filed a tracking issue.

AFAIK target_feature(disable) isn't possible today, and I don't think there's too many users of -multivalue (since that's already the effective default in LLVM), so I'm not sure if it's worth adding more checking for -Ctarget-feature=-multivalue

[nagisa]

r=me

[alexcrichton]

@bors: r=nagisa

[bors]

📌 Commit 0665766 has been approved by nagisa

[bors]

☔ The latest upstream changes (presumably #81866) made this pull request unmergeable. Please resolve the merge conflicts.

[Dylan-DPC-zz]

failed in rollup

@bors r-

[bors]

☔ The latest upstream changes (presumably #83981) made this pull request unmergeable. Please resolve the merge conflicts.

[alexcrichton]

Ah yes I forgot that node needed an update to support multivalue returns by default!

[alexcrichton]

@bors: r=nagisa

[bors]

📌 Commit 482a3d0 has been approved by nagisa

[bors]

⌛ Testing commit 482a3d0 with merge 1255053...

[bors]

☀️ Test successful - checks-actions
Approved by: nagisa
Pushing 1255053 to master...

[theduke]

@alexcrichton this is not directly related, but I'm not quite sure where else to ask.

Does or will this new ABI support anyref ?

As I understand it there currently is no mechanism that allows rustc to directly produce a signature with externrefs.
(I think wasm-bindgen manually patches the wasm when externrefs are enabled?)

[alexcrichton]

No this doesn't help along the externref story for Rust at all, currently that's basically entirely unsupported. I'm not sure myself how externref could be added natively, if ever, to Rust.