Stabilize WebAssembly multivalue, reference-types, and tail-call target features

[alexcrichton]

For the multivalue and reference-types features this commit is
similar to #117457 in that it's stabilizing target features specific to
WebAssembly targets. The previous PR left out these two features because
they weren't expected to change much about compiled code so it was
unclear what the rationale was. It has since been discovered
that reference-types can be useful as it changes the binary format of
the call_indirect instruction. Additionally on Zulip there's
a use case of detecting these features at compile time and generating a
compile error to better warn users about features not supported on
engines.

This PR then additionally adds the tail-call feature which corresponds
to the tail-call proposal to WebAssembly. This feature advanced to
"phase 4" in the WebAssembly CG awhile back and has been supported in
LLVM for quite some time now. Engines are finishing up implementations
or have already shipped implementations, so while this is a bit of a
late addition to Rust itself it reflects the current status of
WebAssembly's state of the feature.

A test has been added here not only for these features but other
WebAssembly features as well to showcase that they're usable without
feature gates in stable Rust.

[rustbot]

r? @petrochenkov

rustbot has assigned @petrochenkov.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[jieyouxu]

The changes LGTM. As far as I understand it, this stabilizes multivalue and reference-types target features (aka wasm proposals) which are already enabled-by-default through the llvm 19 update.

But let's also have someone on T-compiler double-check.

EDIT: this definitely needs relnotes

[alexcrichton]

In case anyone's curious, this is a longer description of what stabilization of these features mean and for multivalue and reference-types there's some more info in this post but the general tl;dr; is that multivalue and reference-types don't affect generated code too too much except for reference-types currently changing the encoding of indirect call instructions. The main motivation for this is to enable users to test for this in Wasm code and emit early-errors if the engine the code is intended to run in doesn't support either proposal.

[ehuss]

Whenever you get a chance, can you also post a PR to update the docs at https://github.com/rust-lang/reference/blob/9c21beeaa59566d87191392548c421cc7baa941a/src/attributes/codegen.md?plain=1#L276-L284?

[alexcrichton]

certainly!

[CryZe]

Would it make sense to add Tail Call as well? I recently added wasm-bindgen support, it's in phase 5 and V8, Spidermonkey and wasmtime ship it by default now, with Safari following very soon.

[alexcrichton]

Excellent point! I've added that in as well now. I've additionally expanded the commit message, PR description, and PR title to include tail-call as well.

I also realize though that this would be an insta-stable addition. If folks are uncertain about that I'm also happy to mark the feature as unstable for awhile. I'm relatively sure that the LLVM implementation is pretty mature though and @CryZe is right in that most engines are shipping this now, so the only part that might change is the feature name really and tail-call matches both the proposal itself and LLVM. In that sense most of the work for shipping this feature wasn't on Rust's part, all Rust needs to do is name it, so that's the part to insta-stabilize here.

[rustbot]

Some changes occurred in tests/ui/check-cfg

cc @Urgau

[petrochenkov]

@rfcbot fcp merge

[rfcbot]

Team member @petrochenkov has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Aaron1011
• @cjgillot
• @compiler-errors
• @davidtwco
• @eddyb
• @estebank
• @jackh726
• @lcnr
• @matthewjasper
• @nagisa
• @oli-obk
• @petrochenkov
• @pnkfelix
• @wesleywiser

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[bors]

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

[alexcrichton]

Wanted to bump this again in case it fell out of folks' inboxes

[bors]

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

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[bors]

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