Allow easy switching on Windows toolchains with rust-toolchain.toml

[RivenSkaye]

Problem you are trying to solve

I'm currently facing a problem where I need to be able to switch between MSVC and GNU toolchains on a Windows host. rust-toolchain.toml (which mostly just pins the channel and components) causes rustup to default to whatever the global default was before pinning a channel (and release) on the first command invocation that makes it select a matching target. Afterwards, it's impossible to switch unless using a higher priority override type, which causes redownloading and reinstalling on every change.

I don't know if linux-gnu and linux-musl and similar multi-toolchain targets suffer the same problem, if so I'll gladly widen the scope to include those as well.

Solution you'd like

An added table entry for [toolchain] to select allowed compiler toolchains would be a working fix. It'd allow existing setups to keep working without any changes (if unspecified, keep current behavior) while also allowing for the toolchain file to actually manage toolchains instead of just channels and targets. Possible name for this new entry could be backends with the value being an array whose values may be any of (arch-)?OS-backend.

Concrete example would be matching ((x86_64-|i686-)pc-)?windows-(gnu|msvc)|((x86_64-|i686-)unknown-)?linux-(gnu|musl)
This would would match any of

• x86_64-pc-windows-gnu
• x86_64-pc-windows-msvc
• x86_64-unknown-linux-gnu
• x86_64-unknown-linux-musl
• i686-pc-windows-gnu
• i686-pc-windows-msvc
• i686-unknown-linux-gnu
• i686-unknown-linux-musl

Naturally this would need to be expanded to either a static list of allowed entries, or to include other known and supported combinations.

As for using it, rustup will resolve e.g. +nightly-msvc to either a currently installed nightly-<...>-msvc or the latest available nightly-<host-triplet>-msvc toolchains (in that order). Even with a toolchain file, it will currently not resolve +msvc. This could be changed to checking if a toolchain file is present and using the specified channel there to resolve it through +<channel>-msvc following the existing logical path. If no toolchain file is present, it'd be free to error in the same way it does currently (error: toolchain 'msvc' is not installed).

Notes

For now I can make do with rustup override set <toolchain> and commandline overrides to force both, but this solution isn't portable as rustup override is directory-specific and can't be checked into a VCS unlike the toolchain files.

[djc]

This sounds like a situation that's analogous to #3546 (see recent comments)?

[RivenSkaye]

I did find that issue, but it seems to mostly be about using specific tooling from other channels - the example there being rustfmt - rather than allowing to switch between toolchains for actual building and debugging. I'll gladly present this as a use case for that issue and merge them if that's preferred though

[djc]

Yes -- I think the broad case is similar enough from the rustup perspective in that you'd like to have a set of toolchains with well-defined names that you'd like to use for different things in the same repo.

[rami3l]

@RivenSkaye @djc IIRC at least with Linux the recommended way is to use the gnu toolchain with an additional musl target. I believe the same is true for Windows and thus I don't see why multiple toolchains with different host triples are needed in this case. Maybe I'm missing something?

[RivenSkaye]

@rami3l the problem there lies in either statically linking a lot of MinGW stuff for it to work on Windows, resulting in much bigger binaries, or having to make sure MSVC can find and process MinGW headers for GNU builds. The latter wouldn't be much of an issue, if a rust-toolchain.toml file would cause it to always default to MSVC. But considering my system is set to default to GNU, I get the bloaty result.

Closing as duplicate and adding this use case to 3546