Wasm: stabilize target_feature = "gc"

[daxpedda]

Follow-up to #150111, stabilizing the new target features.

[..] it has already passed phase 5 in addition to being implemented and stabilized by all major JS engines.

This doesn't enable the target feature by default!

For context: while this proposal adds a lot of new features to Wasm, they are not accessible through Rust apart from unstable inline ASM. This is largely useful to signal tools to make use of the feature, e.g. wasm-bindgen, where this can be used to make some pretty optimizations.

While merging this has to wait until LLVM 22 releases, which is a long way off, I thought it might still be sensible to get FCP approval now. But let me know if this would be considered too premature.

Addresses #150260.
Companion PR: rust-lang/reference#2114.

r? @alexcrichton

[alexcrichton]

To confirm about wasm-bindgen's use case, the intention here is that users will specify -Ctarget-feature=+gc during compilation, that'll make its way to the target-features custom section in the wasm module (emitted by LLD), and then wasm-bindgen will pick that up and act on it?

[daxpedda]

Yes!

As I mentioned, this isn't a dealbreaker because we can just add a global flag.
However, this isn't the case for the next version of wasm-bindgen, where we don't do any post-processing.
We would require enabling LLVMs gc support to feed GC instructions to the linker.

[alexcrichton]

Ok going off the prior stabilization from #131080 that also used T-compiler as the team. I would agree it's reasonable to kick off an FCP here before LLVM 22 is released, so let's see what happens if...

@rfcbot fcp merge

[daxpedda]

I wanted to bump this again because there was some issue with the Rustbot, but I held off because I realized if we stabilize this and LLVM can't actually parse the GC instructions, we are stuck in a bad situation.

Even though inline assembly is not stable yet in Wasm, it is still possible to embed GC instructions via object files. If LLVM doesn't actually understand those, libraries doing this now can't actually rely on target_feature = "gc". Now they would have to figure out the Rust version as well (or possibly the LLVM version!).

So while this is not an issue for wasm-bindgen, which deals with this stuff in post-processing, it might be an issue for other libraries or toolchains. In the meantime I've confirmed that LLD indeed fails on most GC instructions and types.

In conclusion: we should not stabilize this until LLVM can truly parse all GC instructions.