Fix wasm_import_module attribute cross-crate

This commit fixes an accidental regression from 144678 where wasm
targets would now accidentally use the wrong import module map for a
symbol causing a symbol to skip mangling. This can result in compilation
failures when symbols are used in cross-crate situations.

Closes 148347

Author: alexcrichton

compiler/rustc_symbol_mangling/src/lib.rs

@@ -228,7 +228,7 @@ fn compute_symbol_name<'tcx>(
         // However, we don't have the wasm import module map there yet.
         tcx.is_foreign_item(def_id)
             && tcx.sess.target.is_like_wasm
-            && tcx.wasm_import_module_map(LOCAL_CRATE).contains_key(&def_id.into())
+            && tcx.wasm_import_module_map(def_id.krate).contains_key(&def_id.into())
     };
 
     if !wasm_import_module_exception_force_mangling {

tests/ui/wasm/auxiliary/link-name-in-foreign-crate.rs

@@ -0,0 +1,7 @@
+#![no_std]
+
+#[link(wasm_import_module = "test")]
+unsafe extern "C" {
+    #[link_name = "close"]
+    pub fn close(x: u32) -> u32;
+}

tests/ui/wasm/wasm-link-name-in-foreign-crate-respected.rs

@@ -0,0 +1,22 @@
+//@ only-wasm32
+//@ aux-build:link-name-in-foreign-crate.rs
+//@ compile-flags: --crate-type cdylib
+//@ build-pass
+//@ no-prefer-dynamic
+
+extern crate link_name_in_foreign_crate;
+
+// This test that the definition of a function named `close`, which collides
+// with the `close` function in libc in theory, is handled correctly in
+// cross-crate situations. The `link_name_in_foreign_crate` dependency declares
+// `close` from a non-`env` wasm import module and then this crate attempts to
+// use the symbol. This should properly ensure that the wasm module name is
+// tagged as `test` and the `close` symbol, to LLD, is mangled, to avoid
+// colliding with the `close` symbol in libc itself.
+
+#[unsafe(no_mangle)]
+pub extern "C" fn foo() {
+    unsafe {
+        link_name_in_foreign_crate::close(1);
+    }
+}