Miri fails to run in presence of RUSTC environment variable

[CraftSpider]

Currently, if the RUSTC environment variable is set, miri errors out with 'failed to run rustc to learn about target-specific information'. This appears to be because, in cargo-miri, the arg 'rustc' is being checked for exactly, but with RUSTC set, it may actually be set to any binary.

miri/cargo-miri/bin.rs

Line 1112 in fa4e77c

Some("rustc") => phase_rustc(args, RustcPhase::Build),

I found this out due to the Jetbrains rust plugin failing to run miri, as it unconditionally sets the RUSTC environment variable. I'm not sure the best solution. Looking for a path ending in rustc would make an okay patch, but to truly fix the issue, there would need to be a way to distinguish any particular path from being a rustc executable vs a JSON file (for phase_runner). A possible way to do that is to just attempt to execute the provided path?

[RalfJung]

Is it even meaningful to set RUSTC when using Miri? What would you expect that to do?

[CraftSpider]

Personally I'd expect miri to work the same whether it's set or not, though the actual value probably isn't useful to miri itself. I could raise this as an issue with the jetbrains plugin, but I also feel that having RUSTC set to a valid rustc binary shouldn't lead to failures in cargo commands, even if the command doesn't actually care about the value.

If you don't agree, I'll raise the issue with them instead, and see if they can special-case cargo miri.

[RalfJung]

We could make cargo-miri remove the RUSTC env var if it is set. That should "fix" your problem, unless you expected the env var to actually do something, so I don't know if it is a reasonable approach. Maybe we should at least print a warning?

(I do not have a clear idea for the use-cases where one would even set that env var.)

[CraftSpider]

I think that solution would work fine, a warning then ignoring it. I'm not sure what else miri would actually do with the value.

Outside of miri, jetbrains apparently sets it because some users use a self-contained installation of Rust, so rustc isn't in their path.
intellij-rust/intellij-rust#5843 is the issue about that.

[RalfJung]

Something else is happening here -- Miri also runs in rustc bootstrap via x.py, and that one does set RUSTC, which works fine and which we have to keep supporting.

Could you debug a bit more what exactly is going on in your case? In particular, your explanation with that Some("rustc") match arm makes no sense to me -- we set RUSTC_WRAPPER, and that will always make cargo invoke us as $EXE rustc ..., and that is the "rustc" we are matching against.

[RalfJung]

This file "C:\\Users\\runet\\.cargo\\bin\\rustc.exe" contains outdated or invalid JSON error looks similar to #2233. Do you have any way to reproduce this that does not require IntelliJ?

[RalfJung]

Ah, I can reproduce this with RUSTC=$(which rustc) cargo +miri miri run. This is very odd:

Caused by:
  process didn't exit successfully: `/home/r/.cargo/bin/cargo-miri /home/r/.cargo/bin/rustc - --crate-name ___ --print=file-names --crate-type bin --crate-type rlib --crate-type dylib --crate-type cdylib --crate-type staticlib --crate-type proc-macro --print=sysroot --print=cfg` (exit status: 1)
  --- stderr
  fatal error: file "/home/r/.cargo/bin/rustc" contains outdated or invalid JSON; try `cargo clean`

Looks like cargo is acting really strangely when both RUSTC and RUSTC_WRAPPER are set?

[CraftSpider]

Looks like you found my reproduction case on your own, I was running RUSTC=/path/to/rustup/rustc cargo miri as my reproduction. Thanks for the quick resolution!