Files
Jonathan Brouwer bbe1afafb4 Rollup merge of #149868 - alexcrichton:wasm-no-allow-undefined, r=Mark-Simulacrum
rustc: Stop passing `--allow-undefined` on wasm targets

This commit updates how the linker is invoked on WebAssembly targets (all of them) to avoid passing the `--allow-undefined` flag to the linker. Historically, if I remember this correctly, when `wasm-ld` was first integrated this was practically required because at the time it was otherwise impossible to import a function from the host into a wasm binary. Or, at least, I'm pretty sure that was why this was added.

At the time, as the documentation around this option indicates, it was known that this was going to be a hazard. This doesn't match behavior on native, for example, and can easily paper over what should be a linker error with some sort of other obscure runtime error. An example is that this program currently compiles and links, it just prints null:

    unsafe extern "C" {
        static nonexistent: u8;
    }

    fn main() {
        println!("{:?}", &raw const nonexistent);
    }

This can easily lead to mistakes like rust-lang/libc#4880 and defer what should be a compile-time link error to weird or unusual behavior at link time. Additionally, in the intervening time since `wasm-ld` was first introduced here, lots has changed and notably this program works as expected:

    #[link(wasm_import_module = "host")]
    unsafe extern "C" {
        fn foo();
    }

    fn main() {
        unsafe {
            foo();
        }
    }

This continues to compile without error and the final wasm binary indeed has an imported function from the host. This program:

    unsafe extern "C" {
        fn foo();
    }

    fn main() {
        unsafe {
            foo();
        }
    }

this currently compiles successfully and emits an import from the `env` module. After this change, however, this will fail to compile with a link error stating that the `foo` symbol is not defined.
2026-04-04 17:19:09 +02:00
..
2026-03-04 13:38:52 +01:00