Running multiple cargos simultaneously with linked toolchain under windows

[Hecatron]

Hi,
I've recently been developing an embedded project under windows for the ESP32
As part of this I need to use a custom toolchain and link it in
https://github.com/esp-rs/rust

This all seems to work fine but some tools try to run cargo multiple times at the same time
and under windows if this happens and the toolchain is linked it seems to result in

error: unable to unlink old fallback exe: Access is denied. (os error 5)

This might be related / the same thing I'm not sure
#1137

rust-analyser

In the case of rust-analyser I believe it runs "cargo check" and "cargo metadata"
at the same time while it's scanning the source
rust-lang/rust-analyzer#10674

cargo make

With cargo make if I set RUSTUP_TOOLCHAIN="esp" as part of the cargo make script it works fine
If i try and use a rust-toolchain.toml file it seems to fail

[toolchain]
channel = "esp"

The same for directory overrides

• https://rust-lang.github.io/rustup/overrides.html

rustup details

rustup --version

rustup 1.24.3 (ce5817a94 2021-05-31)
info: This is the version for the rustup toolchain manager, not the rustc compiler.
info: The currently active `rustc` version is `rustc 1.56.0 (09c42c458 2021-10-18)`

rustup show

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

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

stable-x86_64-pc-windows-msvc (default)
nightly-x86_64-pc-windows-msvc
esp

installed targets for active toolchain
--------------------------------------

thumbv7em-none-eabihf
x86_64-pc-windows-msvc

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

stable-x86_64-pc-windows-msvc (default)
rustc 1.56.0 (09c42c458 2021-10-18)

[Hecatron]

So I found a workaround to this for custom toolchains

We can't use rustup component since this is a custom toolchain, but we can use x.py
so lets build some tools inside the custom toolchain folder

# Add rustfmt for reformatting code
x.py build --stage 2 rustfmt
# Fixes VSCode Issues with rust-analyser
x.py build --stage 2 cargo

Typically the toolchain ends up in build\x86_64-pc-windows-msvc\stage2
The tools / components end up in build\x86_64-pc-windows-msvc\stage2-tools\x86_64-pc-windows-msvc\release
So lets copy the built tools across

xcopy /e /h /c /i build\x86_64-pc-windows-msvc\stage2-tools\x86_64-pc-windows-msvc\release\*.exe build\x86_64-pc-windows-msvc\stage2\bin

(Note x.py install doesn't work too well under windows so it's easier just to do it this way)

At this point when linking to the toolchain via rustup it should find the pre-built cargo instead of using the fallback one so avoids problems with rust-analyser under VSCode, also it allows for rustfmt to be used as well

[N3xed]

One workaround I've found is to copy cargo.exe from the nightly toolchain (~/.rustup/toolchains/nightly-<platform>/bin/cargo.exe) into the custom toolchain.

This is pretty much the same as @grbd, but avoids having to compile rust yourself.

[kinnison]

Realistically this stems from https://github.com/rust-lang/rustup/blob/master/src/toolchain.rs#L620-L633 which currently only supports a single fallback path for cargo. If, instead, we created a unique fallback path for this toolchain, and then cleaned up when the proxy exited, we'd stand a better chance of things.

To do this, we'd need to:

1. Create a uniquely named fallback path for this run
2. Register that into the toolchain object (the primary not the fallback)
3. Clean up any registered fallback during Drop of the toolchain

In order that the fallback is not cleaned up too early, the toolchain would have to be returned from https://github.com/rust-lang/rustup/blob/master/src/config.rs#L922 and then only dropped after the command has run.

This ought to be fairly straightforward (though not trivial) to implement and test.

[damccull]

Is there a workaround for this I'm not understanding until it gets fixed?

[kinnison]

Unfortunately I don't have a good suggestion. Perhaps someone else who does a lot of work with linked toolchains on Windows might be able to suggest something.

[rbtcollins]

Copy cargo into the tool chain as mentioned above.

[steventrouble]

To elaborate, you can find the directory it's searching for the cargo tool using rustup which cargo.

If it says "not a file", then you can copy cargo into that directory from nightly.