Weird rustup-toolchain interaction if you replace cargo, but not rustc binary

I've noticed a very weird thing. If I use a cargo executable that I built myself (just cargo build --release in a checkout of cargo repo), cargo builds start respecting rustup-toolchain files of crates-io dependencies! The version of Rust can change multiple times during a single build.

   Compiling dashmap v4.0.2
     Running `rustc --crate-name dashmap --edition=2018 /usr/local/cargo/registry/src/ --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --diagnostic-width=272 --crate-type lib --emit=dep-info,metadata,link -C opt-level=2 -C embed-bitcode=no -C debuginfo=1 --cfg 'feature="default"' --cfg 'feature="serde"' -C metadata=c613ba2e98dcaa71 -C extra-filename=-c613ba2e98dcaa71 --out-dir /build/crates/target/aarch64-unknown-linux-gnu/release/deps --target aarch64-unknown-linux-gnu -L dependency=/build/crates/target/aarch64-unknown-linux-gnu/release/deps -L dependency=/build/crates/target/release/deps --extern cfg_if=/build/crates/target/aarch64-unknown-linux-gnu/release/deps/libcfg_if-4492e92fe04d99db.rmeta --extern num_cpus=/build/crates/target/aarch64-unknown-linux-gnu/release/deps/libnum_cpus-5e9c16c68f96ec2e.rmeta --extern serde=/build/crates/target/aarch64-unknown-linux-gnu/release/deps/libserde-9dce91f67c7c5352.rmeta --cap-lints allow --cfg tokio_unstable`
info: syncing channel updates for 'stable-2020-06-18-aarch64-unknown-linux-gnu'
info: latest update on 2020-06-18, rust version 1.44.1 (c7087fe00 2020-06-17)
info: downloading component 'cargo'
info: downloading component 'rust-std'
info: downloading component 'rustc'
info: installing component 'cargo'
info: installing component 'rust-std'
cat /usr/local/cargo/registry/src/

Fortunately, this does not happen with the official cargo from rustup. I guess the weird interaction here is that my cargo binary is not the magic replacement from rustup, but it invokes rustc which is a magic replacement from rustup (i.e. in normal situation all binaries are just hardlinks of rustup), so now every rustc invocation seems like a new run of rustup that can pick a new toolchain.

Does it work correctly if you do rustup run stable /path/to/my/cargo?

Yes, it does.

Another option I've used was to set an explicit toolchain override to override the overrides RUSTUP_TOOLCHAIN=stable.

You can run custom toolchains through rustup as well. There's specific support for using cargo from a different toolchain when a custom toolchain doesn't contain Cargo, and I don't know for sure that it'll function with just cargo, but that should work in theory.

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.