# Help test Windows behavior between rustup and cargo **URL:** \ **Category:** cargo\ **Created:** [January 31, 2024, 2:38pm UTC](https://internals.rust-lang.org/t/help-test-windows-behavior-between-rustup-and-cargo/20237 "2024-01-31T14:38:59Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![ehuss](https://avatars.discourse-cdn.com/v4/letter/e/9de0a6/32.png) [@ehuss](https://internals.rust-lang.org/u/ehuss)\ **Post date:** [January 31, 2024, 2:38pm UTC](https://internals.rust-lang.org/t/help-test-windows-behavior-between-rustup-and-cargo/20237/1 "2024-01-31T14:38:59Z")
We're looking for help with testing a fix with how rustup behaves on Windows ( **especially if you do development of miri, clippy, or use rustc as a library** ). If you are on Windows, you can help by setting the environment variable `RUSTUP_WINDOWS_PATH_ADD_BIN` to `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](https://github.com/rust-lang/rustup/issues/new/choose). ## What does this change do? 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](https://rust-lang.github.io/rustup/concepts/proxies.html) (which is located in your cargo home, such as `C:\Users\eric\.cargo\bin`). Setting `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. Modifying `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](https://github.com/rust-lang/cargo/pull/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. ## What does this fix? 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 `cargo` or `rustc` with a different toolchain (like with the `+` shorthand or with the `RUSTUP_TOOLCHAIN` environment variable): - Running `cargo run` where your executable in turn wants to run `cargo` or `rustc` - A [custom Cargo subcommand](https://doc.rust-lang.org/cargo/reference/external-tools.html#custom-subcommands) - A Cargo [build script](https://doc.rust-lang.org/cargo/reference/build-scripts.html) We appreciate your help, as we hope to switch the default in an upcoming release of rustup. ---
**Author:** ![kpreid](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/kpreid/32/8484_2.png) [@kpreid](https://internals.rust-lang.org/u/kpreid)\ **Post date:** [January 31, 2024, 3:44pm UTC](https://internals.rust-lang.org/t/help-test-windows-behavior-between-rustup-and-cargo/20237/2 "2024-01-31T15:44:13Z")
> [@ehuss](#): > > 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. I ran into this just a few days ago, causing code in my `xtask` that worked locally to fail on Windows CI. I appreciate hearing that this platform-specific behavior is being removed. ---
**Author:** ![CAD97](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/cad97/32/3460_2.png) [@CAD97](https://internals.rust-lang.org/u/CAD97)\ **Post date:** [January 31, 2024, 6:48pm UTC](https://internals.rust-lang.org/t/help-test-windows-behavior-between-rustup-and-cargo/20237/3 "2024-01-31T18:48:46Z")
I've turned this on locally and haven't seen any issues yet (smoke tested most the tools/scripts I use semiregularly). I also utilize _all_ the path remapping environment variables\[1\], so I'm no stranger to hastily written scripts breaking\[2\]. Aside: I've generally recommended scripts/tools potentially running under rustup/cargo to use `${CARGO:-cargo}` for "current toolchain" cargo and `rustup run toolchain cargo` for specific toolchain, and to avoid using the `+toolchain` shorthand. (Infact I recall asking cargo to add diagnostics for receiving a `+toolchain` argument specifically due to hitting this.) Once this change lands by default, is there any reason to not just always use `cargo`? * * * 1. `$CARGO_HOME=D:\.rust\cargo`, `$RUSTUP_HOME=D:\.rust\rustup`, `$CARGO_TARGET_DIR=D:\.rust\target`; utilizing a [dev drive](https://learn.microsoft.com/en-us/windows/dev-drive/) for `D:\` makes a felt improvement for anything that touches a large number of small files, e.g. updating the rust-docs and rust-src rustup components. 2. I've only very rarely had troubles with `$CARGO_HOME`, but forgetting to check `$CARGO_TARGET_DIR` and just using `$CARGO_WORKSPACE_DIR/target` isn't that uncommon. ---
**Author:** ![ehuss](https://avatars.discourse-cdn.com/v4/letter/e/9de0a6/32.png) [@ehuss](https://internals.rust-lang.org/u/ehuss)\ **Post date:** [January 31, 2024, 9:33pm UTC](https://internals.rust-lang.org/t/help-test-windows-behavior-between-rustup-and-cargo/20237/4 "2024-01-31T21:33:45Z")
> [@CAD97](#): > > Once this change lands by default, is there any reason to not just always use `cargo`? I think just `cargo` for the "current" or `cargo +toolchain` for an override should be fine after this change. (Though it might take a while for this change to land.) Build scripts probably should still use `$CARGO`. ---
**Author:** ![bjorn3](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/bjorn3/32/2736_2.png) [@bjorn3](https://internals.rust-lang.org/u/bjorn3)\ **Post date:** [February 2, 2024, 11:58am UTC](https://internals.rust-lang.org/t/help-test-windows-behavior-between-rustup-and-cargo/20237/5 "2024-02-02T11:58:25Z")
The current behavior causes [`cargo clif build` does not work on Windows · Issue #1447 · rust-lang/rustc\_codegen\_cranelift · GitHub](https://github.com/rust-lang/rustc_codegen_cranelift/issues/1447) Setting the mentioned env var fixes it. ---
**Author:** ![link2xt](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/link2xt/32/12157_2.png) [@link2xt](https://internals.rust-lang.org/u/link2xt)\ **Post date:** [May 13, 2024, 1:51pm UTC](https://internals.rust-lang.org/t/help-test-windows-behavior-between-rustup-and-cargo/20237/6 "2024-05-13T13:51:09Z")
This change caused an issue with nextest: > > > \`\`\` > PS C:\\src\\rust-test\> cargo nextest run --workspace > warning: virtual worksp…ace defaulting to \`resolver = "1"\` despite one or more workspace members being on edition 2021 which implies \`resolver = "2"\` > note: to keep the current resolver, specify \`workspace.resolver = "1"\` in the workspace root's manifest > note: to use the edition 2021 resolver, specify \`workspace.resolver = "2"\` in the workspace root's manifest > note: for more details see https://doc.rust-lang.org/cargo/reference/resolver.html#resolver-versions > warning: virtual workspace defaulting to \`resolver = "1"\` despite one or more workspace members being on edition 2021 which implies \`resolver = "2"\` > note: to keep the current resolver, specify \`workspace.resolver = "1"\` in the workspace root's manifest > note: to use the edition 2021 resolver, specify \`workspace.resolver = "2"\` in the workspace root's manifest > note: for more details see https://doc.rust-lang.org/cargo/reference/resolver.html#resolver-versions > Compiling proc-macro2 v1.0.82 > Compiling unicode-ident v1.0.12 > Compiling rust-test v0.1.0 (C:\\src\\rust-test\\hello\_world) > Compiling quote v1.0.36 > Compiling syn v2.0.61 > Compiling hello\_macro v0.1.0 (C:\\src\\rust-test\\hello\_macro) > Finished \`test\` profile \[unoptimized + debuginfo\] target(s) in 2.82s > error: creating test list failed > > Caused by: > for \`hello\_macro\`, command \`'C:\\src\\rust-test\\target\\debug\\deps\\hello\_macro-621f285b4f25d626.exe' --list --format terse\` exited with code 0xc0000135: The specified module could not be found. (os error 126) > \--- stdout: > > \--- stderr: > > \--- > \`\`\` > > I am using the pre-built cargo-next \`0.9.70\` from https://get.nexte.st/latest/windows. I am using the latest \`cargo\` \`1.78.0\`. > \`\`\` > PS C:\\src\\rust-test\> cargo nextest --version > cargo-nextest-nextest 0.9.70 > PS C:\\src\\rust-test\> cargo --version > cargo 1.78.0 (54d8815d0 2024-03-26) > \`\`\` > > Note that this issue doesn't exist on cargo 1.70.0 with the same \`cargo-nextest\` binary. > > This can be reproduced by the following file structure: > > \`\`\` > PS C:\\src\\rust-test\> tree /f > Folder PATH listing for volume ??? > Volume serial number is EC09-0909 > C:. > │ .gitignore > │ Cargo.lock > │ Cargo.toml > │ > ├───hello\_macro > │ │ Cargo.toml > │ │ > │ └───src > │ lib.rs > │ > └───hello\_world > │ Cargo.toml > │ > └───src > main.rs > \`\`\` > > \`Cargo.toml\` > \`\`\` > PS C:\\src\\rust-test\> cat Cargo.toml > \[workspace\] > > members = \[ > "hello\_world", > "hello\_macro", > \] > \`\`\` > > \`hello\_macro/Cargo.toml\` > \`\`\` > PS C:\\src\\rust-test\> cat .\\hello\_macro\\Cargo.toml > \[package\] > name = "hello\_macro" > version = "0.1.0" > edition = "2021" > > \[lib\] > proc-macro = true > > \[dependencies\] > syn = { version = "2", features = \["extra-traits"\] } > quote = "1.0" > proc-macro2 = "1.0" > \`\`\` > > \`hello\_macro/src/lib.rs\` is an empty file. > > \`hello\_world/Cargo.toml\` > \`\`\` > PS C:\\src\\rust-test\> cat .\\hello\_world\\Cargo.toml > \[package\] > name = "rust-test" > version = "0.1.0" > edition = "2021" > > \[dependencies\] > \`\`\` > > \`hello\_world/src/main.rs\` > \`\`\` > PS C:\\src\\rust-test\> cat .\\hello\_world\\src\\main.rs > fn main() { > println!("Hello, world!"); > } > \`\`\` This is going to be fixed on the nextest side it seems, so no action needed, just adding it here for reference. ---
**Author:** ![steffahn](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/steffahn/32/13288_2.png) [@steffahn](https://internals.rust-lang.org/u/steffahn)\ **Post date:** [November 4, 2025, 1:51pm UTC](https://internals.rust-lang.org/t/help-test-windows-behavior-between-rustup-and-cargo/20237/7 "2025-11-04T13:51:25Z")
This topic was automatically closed 540 days after the last reply. New replies are no longer allowed.