Fix setting of PATH for make check on windows

[Diggsey]

I have no idea how bors keeps working without this - I can only assume it's some peculiarity of how windows searches for DLLs.

Without this change, running make check on windows will not correctly set PATH to include eg. x86_64-pc-windows-gnu\stage1\bin\rustlib\x86_64-pc-windows-gnu\lib, and when it tries to run eg. stage1/test/stdtest-x86_64-pc-windows-gnu.exe, it will fail because windows can't find the DLLs on which it relies.

It seems to be just a mistake: when the equivalent was added for the branch that deals with unix-like platforms, the windows branch was left unchanged.

[rust-highfive]

r? @pcwalton

(rust_highfive has picked a reviewer for you, use r? to override)

[brson]

Let's think carefully before merging this. The configuration here is tricky and it may be intentional.

It seems possible to me that we intentionally configured the tests on windows to load the 'host' libs and not the 'target' libs. I do vaguely recall stage1 tests not working on windows for known reasons (known years ago and now forgotten).

@alexcrichton what do you think of this? cc @vadimcn

[vadimcn]

@Diggsey, any idea which dlls is it not finding? For me, make check just works.

[Diggsey]

@vadimcn When running make check it will specifically mention test-xxx.dll from x86_64-pc-windows-gnu\stage1\bin\rustlib\x86_64-pc-windows-gnu\lib. However, that's just the first one it looks for - running depends.exe on the executable shows that it has missing dependencies on most of the DLLs from that folder. (additionally, I've tested by copying just the test dll over, and it does not fix the problem).

How is the executable supposed to find the DLLs? I've checked, and nothing in the makefile rules triggered by make check attempts to modify PATH on windows, and there's no attempt to copy or build the DLLs into the same directory, or a parent directory.

The only other ways I know of how windows could find the DLLs were if PATH already included a directory containing the DLLs, or if the DLLs happened to be loaded by another process at the time (and I'm still not sure about that one, it's not clear from msdn when that applies).

[alexcrichton]

Yeah I think this was an accidental omission (unix already does this). Depending on the ordering of what make check decides to build the test-xxx.dll may not be in place in the host directory because it's only there as rustdoc links to it (which isn't required for some run-pass tests, for example).

@bors: r+ 6203d97

[bors]

⌛ Testing commit 6203d97 with merge 60fe30e...

[bors]

⛄ The build was interrupted to prioritize another pull request.

[bors]

⌛ Testing commit 6203d97 with merge 1af31d4...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-opt