OS discrepancy in how `RUSTUP_TOOLCHAIN` is set

[smoelius]

Problem

There seems to be a discrepancy in how RUSTUP_TOOLCHAIN is set on Windows versus Mac and Linux.

Steps

1. Create a Cargo project in a directory called env. Give it the following main.rs:

   fn main() {
       println!("{}", env!("RUSTUP_TOOLCHAIN"));
   }

   And the following rust-toolchain:

   [toolchain]
   channel = "nightly-2022-06-30"

2. In a sibling directory, create another Cargo project with the following main.rs:

   fn main() {
       std::process::Command::new("cargo")
           .env_remove("RUSTUP_TOOLCHAIN")
           .current_dir("../env")
           .arg("run")
           .status()
           .unwrap();
   }

3. cargo run the latter. On Linux and Mac, the toolchain is printed as one might expect. But on Windows, one gets:

   error: environment variable `RUSTUP_TOOLCHAIN` not defined
    --> src\main.rs:2:20
     |
   2 |     println!("{}", env!("RUSTUP_TOOLCHAIN"));
     |                    ^^^^^^^^^^^^^^^^^^^^^^^^
     |
     = note: this error originates in the macro `env` (in Nightly builds, run with -Z macro-backtrace for more info)
   
   error: could not compile `env` due to previous error

Possible Solution(s)

Sorry, I don't have any.

Notes

I'm not sure if this is related to #3036.

Rustup version

rustup 1.25.1 (bb60b1e89 2022-07-12)

Installed toolchains

Default host: x86_64-pc-windows-msvc
rustup home:  C:\Users\User\.rustup

installed toolchains
--------------------

stable-x86_64-pc-windows-msvc (default)
nightly-2022-06-30-x86_64-pc-windows-msvc
nightly-x86_64-pc-windows-msvc

active toolchain
----------------

stable-x86_64-pc-windows-msvc (default)
rustc 1.62.1 (e092d0b6b 2022-07-16)

[rbtcollins]

It's possible a bug that it's showing set for any os. That variable is under user control.

[ehuss]

This is unrelated to RUSTUP_TOOLCHAIN. If you run rustc -Vv instead of cargo, you can see that the rust-toolchain file is being ignored.

The cause of this is that on Windows rustup puts the toolchain bin directory in PATH in order for rustc to find the necessary .dll files located in the bin directory. A consequence of this is that any subsequent rustup-proxy commands that you run will run directly out of that toolchain directory instead of using the proxy.

Other platforms aren't affected because the use other env vars to find shared libraries (like LD_LIBRARY_PATH).

This used to work, as rustup would keep ~/.cargo/bin in front of the path, but something changed in 1.25. I strongly suspect #2978 changed the behavior.

[ChrisDenton]

This used to work, as rustup would keep ~/.cargo/bin in front of the path, but something changed in 1.25. I strongly suspect #2978 changed the behavior.

That is also the conclusion I reached in #3036.

[smoelius]

Thank you for the detailed explanations, @ehuss, @ChrisDenton.

Closing as evidence suggests this is a duplicate of #3036.