`link.exe` path issue in Windows with rust 1.65+

[ebraraktas]

First of all, I am not sure if this is the correct repository to open this issue, it may be related to cargo or rustup.

Code

This repository shows how to reproduce the issue. For demo, there is a simple github action which modifies the PATH and tries to build proc-macro2.

I expected to see this happen: With rust 1.64 and older, I can build that crate successfully, as one can see from the logs of this run.

Instead, this happened: With rust 1.65+, rust fails to find correct link.exe after the PATH modification, as one can see from the logs of this run. I expect it to find the correct link.exe, as described in this comment.

Version it worked on

It most recently worked on: 1.64

Version with regression

1.65

[ChrisDenton]

I'd guess that this is likely caused the "cc" crate (which rustc uses). In the case where vcvarsall is used, cc will not try to override it and instead respect its settings. This can be a problem if the environment is further modified afterward in a breaking way.

A workaround might be to switch these two lines:

call "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" amd64
set "PATH=C:\msys64\usr\bin;%PATH%"

So instead it's:

set "PATH=C:\msys64\usr\bin;%PATH%"
call "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" amd64

Or just not use vcvarsall in this case.

[ebraraktas]

@ChrisDenton thanks for quick reply. The workaround you suggested helped my issue with rust 1.65. I am not familiar with Windows at all, and your explanation makes sense.

Can I assume that this behavior is not a regression, and previous versions were not supposed to work with PATH modification? If that is the case, this issue can be closed.

[ChrisDenton]

Indeed, after tracking this down further it looks like there was a bug fix that corrected some broken logic. So it is now working as it was intended to.