web: Fix MVP wasm build by explicitly disabling post-MVP features

[SuchAFuriousDeath]

Description

Fixes #23751

-C target-cpu=mvp alone no longer keeps the produced wasm strictly
MVP. Two separate paths leak post-MVP target features back in:

1. Rust 1.82+ enables reference-types and multivalue by default
   for wasm32-unknown-unknown; target-cpu=mvp does not unset them.
2. C dependencies compiled by cc-rs/clang (e.g. jpegxr's jxrlib)
   produce object files whose target_features section carries
   +reference-types/+multivalue regardless of the Rust flags.

Either path leaves +reference-types in the final module's
target_features. wasm-bindgen 0.2.94+ then auto-enables externref
transforms and fails with failed to find the __wbindgen_externref_table_dealloc function, because the
build-std'd MVP code lacks the runtime helper.

Explicitly pass -C target-feature=-reference-types,-multivalue
to rustc and -mno-reference-types -mno-multivalue to clang via
CFLAGS_wasm32_unknown_unknown for the MVP profile only.

Testing

Prereqs:

• Rust 1.82+
• rustup component add rust-src (for -Z build-std)
• wasm-bindgen-cli 0.2.120 matching lockfile (cargo install wasm-bindgen-cli --version 0.2.120)
• Node + clang/LLVM for jpegxr's bindgen

Reproduce the bug on master:
cd web
npm ci
CARGO_FEATURES=jpegxr BUILD_WASM_MVP=true npm run build

expect: error: failed to find the __wbindgen_externref_table_dealloc function

Checklist

• I, a human, have self-reviewed this PR and fully understand the changes within.
• I have made or updated tests where possible.
• All of my commits are properly scoped, compile successfully, and pass all tests.
• This PR does not make sense to split up into smaller PRs.
• An LLM was involved in the authoring of this code.

[danielhjacobs]

Didn't we deal with the Rust 1.82+ issue in #18528 by building std, which we do "stably" by setting RUSTC_BOOTSTRAP to 1 to use Nightly features with stable Rust when building the vanilla module. Any CI scripts that use either of those commands (Nightly release, Dockerfile, dockerfile test) also need to install the rust-src component.

[danielhjacobs]

Here the mvp “cpu” is a placeholder in LLVM for disabling all supported features by default. Cargo’s -Zbuild-std feature, a Nightly Rust feature, is then used to recompile the standard library in addition to your own code. This will produce a binary that uses only the original WebAssembly features by default and no proposals since its inception.

https://doc.rust-lang.org/beta/rustc/platform-support/wasm32-unknown-unknown.html#enabled-webassembly-features

[danielhjacobs]

Mainly I would have expected https://ruffle.rs/demo/ to have stopped working on Pale Moon if this were really an issue, as https://repo.palemoon.org/MoonchildProductions/UXP/issues/2647 is still an issue

[torokati44]

My guess is that the problem comes mainly from newer clang enabling those extensions, so the CFLAGS part of the fix might suffice.

[SuchAFuriousDeath]

I got tangled up in this a little bit, the PR is adjusted. Here is where we stand:

The existing -Ctarget-cpu=mvp + -Zbuild-std + RUSTC_BOOTSTRAP=1 setup from #18528 does produce a strictly-MVP Rust side on current rustc (1.95 here). I confirmed that by ablation: the Rust-side fix I'd originally pushed turned out to be redundant. I've simplified the PR — it's now a one-knob change: set CFLAGS_wasm32_unknown_unknown=-mno-reference-types -mno-multivalue for the MVP build path. No rustflags change.

So the rustc-docs quote you linked is literally correct, and the existing system works for everything compiled by rustc. The breakage is purely a cc-rs/clang leak that the existing system does not (and cannot) control:

1. jpegxr pulls in Microsoft's jxrlib (C) via cc-rs.
2. cc-rs invokes clang for wasm32-unknown-unknown with clang's defaults, which since LLVM 16-ish include +reference-types and +multivalue. Those land in the C object files' target_features custom sections.
3. wasm-ld merges target_features into the final module. I dumped the failing wasm from master: it has +reference-types and +multivalue even with -Ctarget-cpu=mvp + -Zbuild-std — entirely contributed by the C objects.
4. wasm-bindgen 0.2.94+ auto-enables externref transforms when it sees +reference-types in target_features. The Rust-side code was built without externref support, so __wbindgen_externref_table_dealloc isn't present → failed to find the __wbindgen_externref_table_dealloc function.

Tracked upstream as wasm-bindgen/wasm-bindgen#4654 (still open). Setting CFLAGS_wasm32_unknown_unknown=-mno-reference-types -mno-multivalue is the exact workaround recommended in that issue's discussion — it makes cc-rs/clang produce strict MVP objects, so the linked module's target_features stays clean.

Re: ruffle.rs/demo on Pale Moon — that demo's default web build does not enable jpegxr (or any feature that pulls in C deps via cc-rs). No C objects means no clang leak, so the strict-MVP guarantee from rustc holds end-to-end and Pale Moon is happy. The breakage only surfaces with CARGO_FEATURES=jpegxr (the env in the original bug report). Repro:

cd web && CARGO_FEATURES=jpegxr BUILD_WASM_MVP=true npm run build

Master fails with the externref error. Drop jpegxr and master passes. This PR makes both pass.

[torokati44]

+1 reason to sometime rewrite the jpegxr loader to Rust. And get rid of the intermediate TIFF format with it. And the disgusting fakelibc too.
(I heard AI can now port an entire server-side JS runtime from Zig to Rust in a week with no regressions! 👀😏 And we even have c2rust to boot!)

[torokati44]

The comment is a bit verbose - but if anyone, I don't mind that one bit! :P
JS nitpicks notwithstanding, I agree that this is a good fix for the cause of the linked issue, and I also don't know a better way to pass the flag in, but in an envvar. Any potentially preset value there is nicely appended to as well. Thanks for figuring this out!