Make the wasm_c_abi future compat warning a hard error

[bjorn3]

This is the next step in getting rid of the broken C abi for wasm32-unknown-unknown.

The lint was made deny-by-default in #129534 3 months ago. This still keeps the -Zwasm-c-abi flag set to legacy by default. It will be flipped in a future PR.

cc #122532

[lcnr]

given #129534

r? @workingjubilee @alexcrichton

does this need a compiler FCP?

[daxpedda]

I should note that the changes in #129534 did not actually start showing an error to users, it was still a warning by default.
See #129534 (comment)

[workingjubilee]

Technically we are breaking like ~85 versions of a foundation ecosystem crate, so yeah, an FCP might be warranted, but also technically we're just fixing a bug.

If we do this, we should make sure we only do one FCP between this and #133952 though since they're the same decision: "We're killing this dead, yeah?"

[workingjubilee]

Nominating for T-compiler:

We already accepted the MCP to phase out this behavior, but this is the "hard break" edge. If an FCP is desired before proceeding, now is the time to decide. We are technically breaking a crate on future versions of Rust. However it is the crate and target's maintainer wish that we do so, and this is the solution to a 4 year old issue:

• WebAssembly ABI mismatch between clang and rust #71871

We have heard no strong objection and this has been discussed for 4 years at this point, so any box-ticking formality is exactly that: a formality.

@rustbot label: +I-compiler-nominated

Also cc @daxpedda

[apiraino]

Discussed in T-compiler triage on Zulip.

Even if it's just a sign-off, we want to loop in T-lang, seems the usual procedure for them is to FCP such changes.

@rustbot label -I-compiler-nominated +I-lang-easy-decision

[workingjubilee]

To summarize even more summarily for T-lang:

extern "C" fn on wasm32 targets has used a creative ABI that emerged because Rust and C toolchain development were more historically contemporary to each other, as opposed to the usual "first C, then 10~40 years later, Rust". Unfortunately, wasm-bindgen needed something for a stable-ish wasm ABI to talk to JavaScript. A flawed lowering was written. It was not immediately fixed because fixing it would break wasm-bindgen. For a while the wasm32-unknown-emscripten target was an acceptable workaround, and in a nascent ecosystem which might have further growing pains, the next move was not obvious.

Things have settled and it has become clear that Rust should align the ABI of extern "C" fn with that used by C toolchains for other wasm32 targets.

Thanks to @alexcrichton and @daxpedda we have implemented a relatively-smooth migration path for wasm-bindgen. There should be no meaningful concerns going forward, and this will make code that wasn't compatible with C code be compatible again, according to the conventional understanding of extern "C" fn.