We're looking for help with testing a fix with how rustup behaves on Windows. If you are on Windows, you can help by setting the environment variable
0. There are a variety of ways to set an environment variable in Windows, but the easiest is probably to just search for "environment variable" in the start menu, Settings, or the Control Panel, and then click "Environment Variables..." and add it as a user variable. You will then need to restart your terminal, editor, or IDE to pick up the change.
If you experience any problems that seem to be introduced by this (such as cargo commands not behaving with toolchains correctly), please file an issue.
Historically, rustup has modified the
PATH environment variable on Windows when it runs
cargo or other tools so that the toolchain's "sysroot" bin directory is added to the PATH (for example,
C:\Users\eric\.rustup\toolchains\stable-x86_64-pc-windows-msvc\bin). This means that when a command like
cargo needed to execute
rustc, or recursively execute
cargo like in a third-party subcommand, it would come directly from the toolchain's
bin directory instead of using the rustup proxy (which is located in your cargo home, such as
RUSTUP_WINDOWS_PATH_ADD_BIN=0 will change rustup to avoid changing the PATH variable so that cargo subcommands will execute the rustup proxies instead of directly from the toolchain directory.
PATH was originally done for various reasons that are complicated and not really relevant anymore. However, out of an abundance of caution, we are asking people to test the change before we enable it by default for everyone just in case there are any issues that we have not foreseen. For example, there might be some subtle issues with loading the rustc or std DLLs.
This change was also delayed because previously it would cause cargo to run
rustc through the rustup wrapper, which would have incurred a significant overhead. That has been resolved as of Rust 1.71 (via cargo#11917) which changed cargo to avoid the wrapper automatically.
This change does not affect any other platforms because they already do not modify PATH. Setting
RUSTUP_WINDOWS_PATH_ADD_BIN will have no effect on non-Windows platforms.
Because rustup is placing the toolchain bin directory in PATH, that was preventing recursive calls to commands like
cargo from to specifying or changing the current rustup toolchain. For example, if the subsequent commands do something like running
cargo +nightly metadata, it would get an error like
no such command: +nightly because it was trying to execute
cargo directly instead of via the rustup proxy. Similarly setting the
RUSTUP_TOOLCHAIN environment variable would also not work.
The following are examples that would fail if they try to run
rustc with a different toolchain (like with the
+ shorthand or with the
RUSTUP_TOOLCHAIN environment variable):
cargo runwhere your executable in turn wants to run
- A custom Cargo subcommand
- A Cargo build script
We appreciate your help, as we hope to switch the default in an upcoming release of rustup.