Add target_feature = "gc" for Wasm

[daxpedda]

This PR adds a new target feature for Wasm targets: GC.

I went ahead and made this insta-stable because 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.

Companion PR: rust-lang/reference#2114.

r? @alexcrichton

[daxpedda]

Ah, 'tis unfortunate, will have to wait until the next LLVM version.

[alexcrichton]

Looks good to me, thanks! You can update this function to skip the feature on unsupported LLVM versions. Do you have a use case in mind for the insta-stable-ness? I would expect that the GC configuration for wasm-bindgen would be out-of-band rather than via a compiler configuration (e.g. an extra flag to wasm-bindgen itself)

[daxpedda]

Do you have a use case in mind for the insta-stable-ness? I would expect that the GC configuration for wasm-bindgen would be out-of-band rather than via a compiler configuration (e.g. an extra flag to wasm-bindgen itself)

wasm-bindgen has shifted to removing extra CLI configurations in favor of automatic detection, e.g. reference types, multivalue and other proposals. So instead of a --enable-gc flag we want to detect target_feature = "gc".

In the meantime of course wasm-bindgen might just introduce a switch.

[daxpedda]

You can update this function to skip the feature on unsupported LLVM versions.

Done.

[alexcrichton]

What would you think about landing this unstable and having a follow-up PR to switch it to stable? That'd help and get this in without merge conflicts and it can be separated from the FCP required for stabilization too. I'm not actually certain myself which team would need to sign off on this, T-lang or T-compiler, in terms of stabilization

[daxpedda]

What would you think about landing this unstable and having a follow-up PR to switch it to stable? That'd help and get this in without merge conflicts and it can be separated from the FCP required for stabilization too. I'm not actually certain myself which team would need to sign off on this, T-lang or T-compiler, in terms of stabilization

Yeah, why not!

I will open a follow-up PR right away for stabilization so we can get that rolling in the meantime until LLVM 22 is released (a long way off probably).