Installing locally built miri toolchain breaks rustup miri?

[cbiffle]

I'm quite confused here, so it's possible that this is not a Miri bug, but:

I built Miri locally to work on features a couple weeks back, and now cargo +nightly-whatever miri doesn't appear to work anymore. Because I needed the cargo wrapper (miri test doesn't behave exactly the same way), I did ./miri install.

Now when I try cargo +nightly miri test or equivalent, I get:

thread 'main' panicked at 'failed to determine underlying rustc version of Miri: CommandError { stdout: "", stderr: "fatal error: This Miri got built with local toolchain `miri`, but now is being run under a different toolchain. \nMake sure to run Miri in the toolchain it got built with, e.g. via `cargo +miri miri`.\n" }', src/phases.rs:91:10
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I've tried ./miri uninstall, which doesn't seem to exist. I've tried removing the files that I assume are responsible in ~/.cargo/bin and re-running rustup component add miri, but curiously the files are not recreated and cargo miri remains an unrecognized subcommand.

Halp?

[saethlin]

Yup. The process is not generally reversible.

rm the miri and cargo-miri executables from .cargo/bin. Then I'm told some people get back into a working state just by removing and re-adding the Miri component. But I've had to remove the whole nightly toolchain.

It would be cool to do the install in a more... Isolated fashion.

[cbiffle]

If this is a known thing that causes hard-to-reverse changes to other installed toolchains, that should really be in CONTRIBUTING.md as a large warning. I was trying to use Miri for other things on this machine and this has stopped me in my tracks.

[cbiffle]

rm ~/.cargo/bin/miri 
rm ~/.cargo/bin/cargo-miri
rustup toolchain uninstall nightly-2022-07-27
rustup toolchain install nightly-2022-07-27
rustup component add miri
cargo miri

...is still an unrecognized subcommand for Cargo. Perhaps I should remove my system's entire rustup installation and start from scratch? (Edit: I should clarify, the last two commands are run in a directory with a rust-toolchain.toml that pins that toolchain version.)

[cbiffle]

If anyone else is running into this, here is a thing that seems obvious but won't fix it.

$ cargo install cargo-miri
$ cargo miri test
This is a dummy package to make sure nobody malicious registers the cargo-miri crate. This crate was mentioned in a talk but not registered. If you think you deserve to be the owner of this package, please contact Bram Geron.

🙄

[bjorn3]

Try rustup self update. That should re-install all rustup shims if you removed the miri and cargo-miri executables installed by ./miri.

[cbiffle]

Thanks, I've already blown away Rustup and Cargo and am in the process of reinstalling all the toolchains and cargo-install'd binaries I need to do my work. Hopefully your suggestion will help the next person.

[saethlin]

For whatever it's worth, "reinstall rustup" was my experience as well the first two times I dealt with this and I simply neglected to open an issue. So thank you for raising this.

Maybe we should ask the rustup person/people for advice on doing something better here.

[RalfJung]

If this is a known thing that causes hard-to-reverse changes to other installed toolchains, that should really be in CONTRIBUTING.md as a large warning.

Yes you are right. Sorry for that. :(

[RalfJung]

Try rustup self update. That should re-install all rustup shims if you removed the miri and cargo-miri executables installed by ./miri.

Sadly this does nothing when rustup is already up-to-date.

[RalfJung]

Ah, rustup update does it.

[saethlin]

@cbiffle This situation should be properly resolved now, by #2806