Rust 1.96 Ships May 28: Fix Your WebAssembly Builds Now

Rust 1.96 ships on May 28 — five days from now. One change in this release will silently break WebAssembly builds that have been working fine for years. The culprit is --allow-undefined, a linker flag that Rust has been passing to wasm-ld since WebAssembly support was first introduced. It’s going away. If you’re targeting WASM with raw extern "C" blocks for host function imports, your build fails on upgrade day. The fix is a single attribute — but you need to know if you’re affected.

What Is Actually Changing

Since Rust first shipped WebAssembly targets, the compiler has automatically passed --allow-undefined to the wasm-ld linker. This flag converts undefined extern symbols into WebAssembly imports instead of treating them as errors — a behavior that diverges from every other platform Rust supports. On native targets, an undefined symbol is a linker error. On WASM, it was silently imported from the host. That divergence ends with 1.96.

The change landed in nightly last month and goes stable on May 28 (PR #149868). Per the official Rust team announcement, the flag was “effectively required in the very early days” of wasm-ld integration but was always known to be a hazard. The ecosystem has long outgrown it.

Are You Affected?

Most Rust-WASM developers are not affected. If you’re using #[wasm_bindgen] for JavaScript interop, you’re safe — the macro already handles symbol declaration correctly. Same for projects with fully resolved static dependencies. Where things break is raw extern "C" blocks used for JS host function imports without a #[link] attribute:

// This worked before Rust 1.96. It won't after.
unsafe extern "C" {
    fn js_log(n: u32);
}

Without the #[link(wasm_import_module = "...")] annotation, wasm-ld no longer knows where to import this symbol from. Before 1.96, it shrugged and created an import. After 1.96, it’s a linker error.

There’s a second category worth noting: code with typo’d extern function names or unlinked dependencies that currently compiles to a silently broken WASM module. Those projects will now get compile-time errors instead. That is the correct outcome.

Three Ways to Fix It

Fix 1 (Recommended): Add the #[link] Attribute

Add #[link(wasm_import_module = "env")] to each extern block. The module name must match the object key you use in your JavaScript WebAssembly.instantiate call:

#[link(wasm_import_module = "env")]
unsafe extern "C" {
    fn js_log(n: u32);
}

// JS side — unchanged
let instance = await WebAssembly.instantiate(module, {
    env: {
        js_log: n => console.log(n),
    }
});

This is explicit, correct, and forward-compatible. It works on the current stable toolchain today, so you can make this change before May 28 without waiting.

Fix 2 (Quick Escape): Restore the Flag via .cargo/config.toml

If you have a large codebase and need time to audit, restore the old behavior per-target in your Cargo config:

[target.wasm32-unknown-unknown]
rustflags = ["-C", "link-arg=--allow-undefined"]

No code changes required. This buys you time. Treat it as a stopgap, not a long-term solution — the flag may be fully removed in a future Rust release.

Fix 3 (Best Long-Term): Migrate to #[wasm_bindgen]

If you’re still writing raw extern "C" blocks for JavaScript interop in 2026, this is the moment to stop. wasm-bindgen (currently at v0.2.118) handles all of this automatically, gives you type-safe JS bindings, and integrates cleanly with wasm-pack. The Rust 1.96 change is the push you needed.

Test on Nightly Before May 28

You have five days. Use them:

rustup update nightly
cargo +nightly build --target wasm32-unknown-unknown

Linker errors will surface immediately. Search your WASM-targeted crates for extern "C" blocks without #[link(wasm_import_module = "...")] annotations. That’s your fix list.

Why Rust Made the Right Call

A compiler that silently papers over missing symbols is not doing you a favor — it’s deferring runtime failures and producing WASM modules that depend on host imports nobody declared intentionally. The crater impact analysis found approximately 4,983 regressions across 757,000 crates tested, but most were noise from CI environments missing wasi-sdk. The real blast radius is smaller, and the Rust team reviewed carefully before committing to stable.

WebAssembly adoption grew 217% year-over-year in 2025. The ecosystem is mature enough to enforce correctness. Treating WASM as a special platform that needs linker workarounds is the wrong model going forward — and the Rust team is right to end it.

For more on the current state of Rust and WebAssembly performance, see our Rust WASM benchmark deep-dive. If you have WASM builds in your pipeline, run them on nightly today. Five days is short.