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

1

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/index.crates.io-6f17d22bba15001f/dashmap-4.0.2/src/lib.rs --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/index.crates.io-6f17d22bba15001f/dashmap-4.0.2/rust-toolchain
stable-2020-06-18

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.

2

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

3

Yes, it does.

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

4

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.