rustc uses non-hermetic libs/paths on Windows

[carpenterjc]

The rust compiler doesn't use the path of the linker to determine where it should look for libraries/other paths.
On windows if you don't specify the environmental variables from vcvars it will use the registry to guess what version of VS you want to use.

If you have VC 17.10 and VC10.12 installed and compile rust with your C++ toolchain configured to VC17.10 the linker path passed in to the rust compiler is that from VC17.10, however rustc looks in the registry and finds 17.12 installed and provides the standard libs from 17.12 instead.

You will then notice that features which are highly coupled to the linker/lib combinations stop working, for example asan.

See:
https://docs.rs/cc/latest/src/cc/windows/find_tools.rs.html#1190-1191

The workaround is to set VSINSTALLDIR and VCINSTALLDIR in the env.

The main problem from rust/rules/linker combination is this can appear to be working correctly, but your not actually getting the compiled output you expect, and even just installing a trial patch version of the latest VS can generate different binary outputs.

[dgrunwald-qt]

In our case we have external/windows_msvc_toolchain/msvc containing what is normally found at C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.44.35207.
I'm not sure how to set VSINSTALLDIR/VCINSTALLDIR in this case; normally those variables are set to parent directories that do not exist in our directory structure.

My solution is to instead patch rules_rust to use -LIBPATH: command line arguments instead of the LIB environment variable. rustc seems to add its own linker search path at the end of the command line (or at the beginning of LIB?); and any command line -LIBPATH arguments have precedence over the LIB envvar. Thus rustc's injected search path from the registry wins over the LIB envvar. But if rules_rust switches from LIB envvar to -LIBPATH, then that will have precedence over the path injected by rustc.

But I'd like a solution that works without having to patch rules_rust.

[dgrunwald-qt]

We discussed this in #t-compiler/windows > rust LIB path and I figured out that the magic "use library search path from registry" logic in rustc is still active if you

• use --codegen=linker=external/msvc/bin/HostX64/x64/link.exe (like rules_rust is doing automatically)
• set VSINSTALLDIR and VCINSTALLDIR
  However if you additionally have a link.exe available in PATH, then suddenly rustc disables the magic!

Indeed, this is sufficient:

mkdir useless
echo dummy file >useless\link.exe
set PATH=useless;%PATH%
set VCINSTALLDIR=bogus
set LIB=external\msvc\lib\x64;...
rustc test.rs --crate-name=test --crate-type=cdylib --edition=2024 --codegen=linker=external/msvc/bin/HostX64/x64/link.exe

If VCINSTALLDIR is set (no matter to which value) and a link.exe is found in PATH (even though that link.exe is not going to be used), then rustc will disable the registry-based extra search path logic. Weird and unexpected, and probably something that should change on the rustc side.

Unfortunately I don't see any easy way of extending PATH inside bazel :(