Symbol names may not correctly account for optimization level differences between crates

[alexcrichton]

On investigating rust-lang/wg-cargo-std-aware#32 I've managed to reduce this down to:

$ cat foo.rs
pub fn foo() {
    bar::<usize>();
}

pub fn bar<T>() {
    baz();
}

fn baz() {}
$ cat bar.rs
extern crate foo;

pub fn bar() {
    foo::foo();
}
$ rustc --crate-type rlib foo.rs
$ rustc --crate-type dylib bar.rs -L .
$ rustc --crate-type dylib bar.rs -L .  -C opt-level=2
error: linking with `link.exe` failed: exit code: 1120
  |
  = note: "C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Community\\VC\\Tools\\MSVC\\14.22.27905\\bin\\HostX64\\x64\\link.exe" "/NOLOGO" "/NXCOMPAT" "/LIBPATH:C:\\Users\\alex\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib" "bar.bar.3a1fbbbh-cgu.0.rcgu.o" "/OUT:bar.dll" "/DEF:C:\\Users\\alex\\AppData\\Local\\Temp\\rustcAYUABK\\lib.def" "bar.13x131manznmlae2.rcgu.o" "bar.4hnz5vh12lvh2qha.rcgu.o" "/OPT:REF,ICF" "/DEBUG" "/NATVIS:C:\\Users\\alex\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\etc\\intrinsic.natvis" "/NATVIS:C:\\Users\\alex\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\etc\\liballoc.natvis" "/NATVIS:C:\\Users\\alex\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\etc\\libcore.natvis" "/LIBPATH:." "/LIBPATH:C:\\Users\\alex\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib" "C:\\Users\\alex\\AppData\\Local\\Temp\\rustcAYUABK\\libfoo.rlib" "C:\\Users\\alex\\AppData\\Local\\Temp\\rustcAYUABK\\libstd-b2f27b8d08c4688f.rlib" "C:\\Users\\alex\\AppData\\Local\\Temp\\rustcAYUABK\\libpanic_unwind-9c73c9c2e052b2f1.rlib" "C:\\Users\\alex\\AppData\\Local\\Temp\\rustcAYUABK\\libbacktrace-7a588e8fa018f6bc.rlib" "C:\\Users\\alex\\AppData\\Local\\Temp\\rustcAYUABK\\librustc_demangle-74b71f441b8acffe.rlib" "C:\\Users\\alex\\AppData\\Local\\Temp\\rustcAYUABK\\libhashbrown-42efce06651eab9c.rlib" "C:\\Users\\alex\\AppData\\Local\\Temp\\rustcAYUABK\\librustc_std_workspace_alloc-7518db6030684168.rlib" "C:\\Users\\alex\\AppData\\Local\\Temp\\rustcAYUABK\\libunwind-f7edde5930d50b47.rlib" "C:\\Users\\alex\\AppData\\Local\\Temp\\rustcAYUABK\\libcfg_if-30189c8e78e151e8.rlib" "C:\\Users\\alex\\AppData\\Local\\Temp\\rustcAYUABK\\liblibc-5f5719f1cab83a12.rlib" "C:\\Users\\alex\\AppData\\Local\\Temp\\rustcAYUABK\\liballoc-f297c401e81b90c6.rlib" "C:\\Users\\alex\\AppData\\Local\\Temp\\rustcAYUABK\\librustc_std_workspace_core-f8c80c1aefab6a32.rlib" "C:\\Users\\alex\\AppData\\Local\\Temp\\rustcAYUABK\\libcore-6d66b6e58725d3ed.rlib" "C:\\Users\\alex\\AppData\\Local\\Temp\\rustcAYUABK\\libcompiler_builtins-1f6a73e107798f53.rlib" "advapi32.lib" "ws2_32.lib" "userenv.lib" "msvcrt.lib" "/DLL" "/IMPLIB:bar.dll.lib"
  = note: lib.def : error LNK2001: unresolved external symbol _ZN3foo3bar17h95b7da637b923d2cE
          bar.dll.lib : fatal error LNK1120: 1 unresolved externals


error: aborting due to previous error

The platform used here to reproduce the error is x86_64-pc-windows-msvc, but it looks like macOS also generates the same error. The error doesn't appear to manifest on Linux, presumably because the linker options just ignore non-defined symbols.

Here you can see that when both crates are compiled with the same optimization level the link succeeds, but with different optimization levels the wrong symbol name is generated, so the wrong symbol is asked to be exported which causes an error.

[alexcrichton]

cc @michaelwoerister and @eddyb, y'all may know where to start looking for this?

[alexcrichton]

I did a bit of instrumentation in the compiler, and it looks like this line is changing depending on which crate is compiling. When compiling the foo crate the value being hashed there is "foo". When compiling bar, however, if you turn off optimizations it's also hashing "foo" (and instantiating_crate is crate15). If you turn on optimizations in the bar crate, however, then it hashes "bar" because instantiating_crate is crate0. That to me implies some funkiness around here where instantiating_crate is calculated.

Sure enough it looks like tcx.sess.opts.share_generics() is changing between compilations which causes issues. I'll look into fixing this locally.

[alexcrichton]

Ok, posted #64324!

[alexcrichton]

Reopening due to #66018

[jdm]

Is this now fixed by #68277?

[michaelwoerister]

Yes, that should be the case. A regression test for this issue was added in 0a9bcb0.