Replace Windows custom toolchain hack

[ghost]

When using a custom toolchain on Windows, Rustup ensures that the
fallback Cargo calls the correct rustc executable by hardlinking cargo
into an empty directory and executing it there. The problem with this
method is that if cargo is invoked twice at the same time, the second
invocation fails because it can't replace the hardlink which it is in use
by the first. This occurs when an integration test itself invokes cargo.

This commit replaces the hack by specifying the correct version of rustc
by setting the RUSTC environment variable when cargo is invoked. This is
set to the absolute path of rustc in the correct toolchain rather than
the rustup wrapper. This is consistent with the way rustc is invoked on
a normal toolchain on Windows.

[petrochenkov]

Does this fix #1197?
(The last time I tried, "fallback Cargo" didn't work on Windows at all, as described in that issue.)

[ghost]

Fallback Cargo is working for me on Windows both with and without this change.

[flip1995]

We need this over at https://github.com/rust-lang-nursery/rust-clippy to get Appveyor green again. It would be great if someone could review this!

r? @Diggsey

[kinnison]

Hi @mikerite

Are you interested in persuing this PR? If so, it needs rebasing as the codebase has been run through rustfmt since you created the change.

Thanks,

D.

[bors]

☔ The latest upstream changes (presumably #1576) made this pull request unmergeable. Please resolve the merge conflicts.

[ghost]

@kinnison, I would still like this to be merged. I've rebased the changes.

[kinnison]

This looks sane to me, though I'm unsure about the exact semantics of dealing with this under Windows. Is there anyone with Windows experience able to 👍 this?

[alexcrichton]

I wonder if it would be possible to address the possible race here that's happening instead of setting RUSTC? I'd be a little worried that more tools other than Cargo expect rustc to "be the right rustc", whether or not RUSTC is set. To get the most scripts and such it seems like it'd be great to get rustc working when executed through PATH.

I'll admit though that I don't know a ton about the underlying issue here, so it may not have an easy solution or one at all!

[ghost]

This is only an issue for tools containing a rustc.exe file in the directory where they located. Arguably, if people are using this set up on Windows, they want that bundled executable invoked when they call "rustc.exe" so I don't think a general fix is possible.

For the tools managed by rustup, a possible fix might be to store rustc.exe and those tools in separate directories but that seems like a much bigger and more risky change.

Existing fallback code only targets Cargo right now.

https://github.com/rust-lang/rustup.rs/blob/61f57bb7b29512d4864abd059837cd6d526d5033/src/rustup/toolchain.rs#L366-L367

[alexcrichton]

I may be misunderstanding the issue, but isn't the point here that you're using a custom toolchain which only has rustc.exe, but you're using cargo.exe from an otherwise already-downloaded toolchain? In that case the "official" cargo.exe has rustc.exe right next to it

[ghost]

That's right.

[alexcrichton]

I don't think I understand then what you mean by "tools containing a rustc.exe file". By "tools" do you mean "toolchains"? Because all toolchains have rustc.exe AFAIK.

Also when you say "tools managed by rustup" I'm not sure I know what you mean. This I thought was a PR about cargo.exe and custom toolchains, where cargo.exe is guaranteed to have rustc.exe next to it.

[ghost]

By "tools containing rustc.exe" I meant tools written by other people that for some for reason bundle rustc.exe. I don't actually know of any tools like this. I though this is what you meant when you said the "the most scripts and such".

By "tools managed by rustup" I meant cargo, rustfmt and all the other tools that can be included as components of a toolchain. I'm not 100% sure of the terminology.

This PR only about cargo.exe and custom toolchains. Yes, cargo.exe is will always have rustc.exe next to it for a non-custom toolchain.

[alexcrichton]

Ok, well going back to my original point I don't think this is the right solution because rustc as an executable is expected to work not only with Cargo but also other tools.

I was trying to make sense of your response, but I think my original thoughts still stand.

[ghost]

OK, let's close this. Thanks for taking the time to review.