Wasm Linker "module mismatch for symbol" Regression in 1.91.0

[posborne]

Additional notes and repro cases: https://github.com/posborne/rustc-1.91.0-wasm-linkage-bug-repro

With the Rust 1.91.0 stable update, it appears that a regression has been introduced which causes linkage to either fail to link (with LTO disabled) or encounter runtime errors at link boundaries in instances where the following conditions are true:

• Targeting wasm (tested so far has been with wasm32-wasip1 but like impacts other wasm targets).
• The code uses a lib that has a #[link(wasm_import_module = "...")] extern with a #[link_name = "blah"]
• "blah" is provided by libc (and probably some other cases).

This case can be relatively common in the WASM world as it can be common for there to be wasm modules as part of an interface that export symbols like open, close, etc.

Reproduction Steps

See https://github.com/posborne/rustc-1.91.0-wasm-linkage-bug-repro. The standalone-repro package is probably best to use for a reproduction. The reproducing code there consists of a cdylib and an rlib where the rlib defines the following link_name matching a symbol also provided and referenced from libc (close in this case).

#![no_std]

#[link(wasm_import_module = "test")]
extern "C" {
    #[link_name = "close"]
    pub fn close(x: u32) -> u32;
}

Introduced

Doing a bisect using cargo-bisect-rustc indicates that the regression was introduced with commit 8e62bfd

Meta

With lto = false, here's the link error seen with 1.91.0 which does not occur with 1.90.0:

$ rustc --version
rustc 1.91.0 (f8297e351 2025-10-28)

$ cargo build --release --target wasm32-wasip1 -p standalone-repro
   Compiling standalone-repro v0.1.0 (/home/paul.osborne/Projects/OpenSource/rustc-bug-wasm-mangling-minrepro/standalone-r
epro)
error: linking with `rust-lld` failed: exit status: 1
  |
  = note:  "rust-lld" "-flavor" "wasm" "--export" "_start" "--export" "use_custom_close" "--export" "use_stdlib_close" "-z
" "stack-size=1048576" "--stack-first" "--allow-undefined" "--no-demangle" "<5 object files omitted>" "<sysroot>/lib/rustl
ib/wasm32-wasip1/lib/libpanic_abort-*.rlib" "/home/paul.osborne/Projects/OpenSource/rustc-bug-wasm-mangling-minrepro/targe
t/wasm32-wasip1/release/deps/libmock_wasm_imports-087a5ee1a42d8ae5.rlib" "<sysroot>/lib/rustlib/wasm32-wasip1/lib/{libstd-
*,libwasi-*,libcfg_if-*,librustc_demangle-*,libstd_detect-*,libhashbrown-*,librustc_std_workspace_alloc-*,libminiz_oxide-*
,libadler2-*,libunwind-*,liblibc-*}.rlib" "-l" "c" "<sysroot>/lib/rustlib/wasm32-wasip1/lib/{librustc_std_workspace_core-*
,liballoc-*,libcore-*,libcompiler_builtins-*}.rlib" "-L" "<sysroot>/lib/rustlib/wasm32-wasip1/lib/self-contained" "-o" "/h
ome/paul.osborne/Projects/OpenSource/rustc-bug-wasm-mangling-minrepro/target/wasm32-wasip1/release/deps/standalone_repro.w
asm" "--gc-sections" "--no-entry" "-O0" "--strip-debug"
  = note: some arguments are omitted. use `--verbose` to show all linker arguments
  = note: rust-lld: error: import module mismatch for symbol: close
          >>> defined as env in /home/paul.osborne/Projects/OpenSource/rustc-bug-wasm-mangling-minrepro/target/wasm32-wasi
p1/release/deps/standalone_repro.standalone_repro.10d18315a1d024f1-cgu.1.rcgu.o
          >>> defined as test in /home/paul.osborne/Projects/OpenSource/rustc-bug-wasm-mangling-minrepro/target/wasm32-was
ip1/release/deps/standalone_repro.standalone_repro.10d18315a1d024f1-cgu.3.rcgu.o


error: could not compile `standalone-repro` (lib) due to 1 previous error

Compilation and linking completes with LTO enabled but emits a wasm module that results in runtime aborts in the guest.

Root Cause

The issue appears to be related to changes around wasm_import_module_exception_force_mangling and possible ordering changes in 8e62bfd. The issue does not if two rust libs export the same link_name; it appears to be unique to a mix of non-mangled (libc) and mangled names.

CC @jdonszelmann @bjorn3 @sunfishcode @alexcrichton

[bjorn3]

Looks like tcx.wasm_import_module_map() now gets LOCAL_CRATE rather than def_id.krate as argument, which would cause the LLVM function declaration to not get mangled if the extern function is called from another crate.

[alexcrichton]

Thanks @bjorn3! I tested that in #148363 and looks like that is indeed both the cause and fix.