I'm sorry that this has affected you. As the warning message says, that toolchain could not run on your system.

We try to do a difficult thing, permitting the maximum permissible underlying capabilities of the system, while still being easy to use. In this area we fall short.

Remove that new toolchain, and then instead use the target add option to add a new target to your existing toolchain.

@kinnison and I have discussed this and we have consensus: the only use case for this UX being the way it is is is folk doing unusual personalities with e.g. qemu binary emulation on their machines etc. We think making the ability to install toolchains that aren't the host toolchain require a --force-non-host-toolchain (or some other name) option would perhaps avoid folk making this mistake: users with deliberate complicated setups that can run these toolchains can still do so by providing the option. Others should be diverted to the relevant target instead.

UX wise we can probably benefit by some actual testing, but my intuition is that we need to make this discoverable. I suggest something like the following:

• trying what the OP did should get an error that states the following things:
  • the requested toolchain won't work on their machine
  • if they have some sort of host emulator they can install the toolchain by using --option name
  • if they want to compile for the host triple they provided, they should use 'rustup toolchain target add' instead.
• The most visually clear part of the error should be clear instructions that can just be copy-pasted to perform the target add that is almost certainly what the user wanted.
• The --force etc path should not be trivially copy-pasteable (e.g. it shouldn't be a complete command line).

@rbtcollins There are some combinations that work fine without any kind of emulator, at least on windows. eg:

• 32-bit toolchains on 64-bit hosts
• GNU vs MSVC toolchain

It looks like the logic for this warning doesn't currently consider these possibilities. If this is to become a hard error it should be smarter about this.

I think thats a good discussion to have, but its not obvious to me that we should actually be more complicated in the code here.

Running a 32 bit toolchain on a 64-bit host will save some memory, but it requires 32-bit libc etc, and 32-bit system headers for Windows - so 'some sort of host emulator' is needed, even if that is just multiarch. multiarch isn't default-on on systems, and we haven't got a reliable way to detect it at the moment. We could perhaps download the toolchain and run it to verify, and then uninstall it - but given that 99% of the time this still won't be what folk want, I don't think that this makes sense.

GNU vs MSVC toolchain for Windows - we switched the default to the MSVC toolchain because it was substantially faster. Making folk have to explicitly work to opt into a slower configuration makes sense to me: if a user wants to do so, they can use the proposed --force-... option to get it, but hopefully they will take time to read the docs and realise that all they need is the GNU target.

The evidence we have is that the complexity here - offering the same arch triples to describe 'compiler you can run on this machine' and 'machine you can run a compiled binary on' confuses folk until they have climbed the learning curve. We can either not offer the ability to install different arch compilers, which would make certain testing use cases much harder, or we can provide some mechanism to help folk step up the learning curve. So far we've tried doing nothing - and got these queries in the bug tracker, discord etc; then we tried a warning, which may have reduced it somewhat, but its not clear that it has, and certainly this bug shows that folk still end up in the situation where they have installed the toolchain that cannot run : the warning is too late.

Running a 32 bit toolchain on a 64-bit host will save some memory, but it requires 32-bit libc etc, and 32-bit system headers for Windows - so 'some sort of host emulator' is needed, even if that is just multiarch. multiarch isn't default-on on systems, and we haven't got a reliable way to detect it at the moment.

AFAIK, this distinction doesn't exist on windows. When you install the VC build tools you get both 32-bit and 64-bit support, and they both use the same headers. I don't even know of a way to get just 64-bit support, but maybe there is an option somewhere.

There are also several advantages to using a 32-bit toolchain to compile 32-bit code (or a gnu toolchain when targeting gnu), due to the fact that you are not cross-compiling. In particular, crates with build scripts may not support cross-compiling.

we tried a warning, which may have reduced it somewhat, but its not clear that it has, and certainly this bug shows that folk still end up in the situation where they have installed the toolchain that cannot run : the warning is too late.

I'm sympathetic to that, but if people are ignoring the warning, why would they not ignore the error too? If you can make it work with --force then the only affect it will have is that people will retry with --force and then hit the same thing. Meanwhile, you will have broken CI workflows for anyone who uses this feature.

Furthermore, the warning currently compares against the automatically detected host triple rather the "default host" triple, so anyone using the "default host" feature will hit this error even with commands like rustup install stable.

At the very least, this error should occur only when you first try to change the "default host", not every time you do something with rustup (having previously changed the default host).

The point about the default host is worth taking into account for the implementation for sure : thats just about a possible bug we should avoid.

But the point about --force is much weaker: the hypothesis is that people are not even reading the message, let alone taking in the documentation around it. We know, from having to explain this repeatedly, that the conceptual separation between 'toolchain' and 'target' is not intrinsically understood by people that want rust installed on their system; some of whom are developers of rust programs, and some of whom are consumers of rust programs who are just trying to build a thing someone else has written.

It is true that adding --force will break CI systems and tools like cross that depend on the current feature as-is. It is also true that it will force people that try to add a toolchain that won't run locally to pause and possibly re-evaluate what they are trying.

1. Some may not follow the breadcrumbs that we provide at that point: they may not see them (e.g. hidden by other output); or they may not look for them.
   1.1. Some of these will not find --force and will decide rustup is broken (and may ask for help)
   1.2. Some of them will find it and use it hoping it fixes things without understanding (and may subsequently ask for help)
2. Some will follow the breadcrumbs but not understand the documentation that the breadcrumbs lead to
   1.1. Some will then try --force (and may then ask for help)
   1.2. Some will ask for help
3. Some will follow the breadcrumbs and understand and switch to rustup target add and we'll have a happy user who we never hear from

The question really is how many will be in 3 vs 1 or 2, and what can we do to maximise the size of bucket 3. Rustc itself has been super successful at this strategy of helpful, meaningful error messages, so I think we have significant prior art around the idea of taking this approach.

The question really is how many will be in 3 vs 1 or 2, and what can we do to maximise the size of bucket 3. Rustc itself has been super successful at this strategy of helpful, meaningful error messages, so I think we have significant prior art around the idea of taking this approach.

Observationally, given the problem is not reading the messaging, and a large number of people do express confusion about rustc's messaging even when it is solved by reading the error message, we should definitely appreciate those details and not expect this to be completely solved, either way.

Just an FYI but I've been running into this quite a bit lately on Windows. E.g.:

> rustup update nightly-msvc
error: DEPRECATED: future versions of rustup will require --force-non-host to install a non-host toolchain as the default.
warning: toolchain 'nightly-msvc' may not be able to run on this system.
warning: If you meant to build software to target that platform, perhaps try `rustup target add msvc` instead?
info: syncing channel updates for 'nightly-x86_64-pc-windows-msvc'
...

I do tend to move around between nightly and stable as well as msvc and gnu. It's not the biggest deal in the world but having a big scary red error every time is slightly annoying.

@ChrisDenton 1.24.3 included #2782 which should have fixed that circumstance. Are you running 1.24.3 and if so could you please tell me the exact variant of rustup you are running, along with what your default host is etc.

@kinnison I'm on 1.24.3. Default host is x86_64-pc-windows-msvc.

> 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.54.0 (a178d0322 2021-07-26)`
> rustup update stable-msvc
error: DEPRECATED: future versions of rustup will require --force-non-host to install a non-host toolchain as the default.
warning: toolchain 'stable-msvc' may not be able to run on this system.
warning: If you meant to build software to target that platform, perhaps try `rustup target add msvc` instead?
info: syncing channel updates for 'stable-x86_64-pc-windows-msvc'

  stable-x86_64-pc-windows-msvc unchanged - rustc 1.54.0 (a178d0322 2021-07-26)

info: checking for self-updates

On I've just had an interesting thought - I wonder if this is a question of partial vs. full target specifications... Could you try the following: rustup update stable-x86_4-pc-windows-msvc If that runs without the deprecation error then I think I have an idea of what needs doing.

That worked!

> rustup update stable-x86_64-pc-windows-msvc
info: syncing channel updates for 'stable-x86_64-pc-windows-msvc'

  stable-x86_64-pc-windows-msvc unchanged - rustc 1.54.0 (a178d0322 2021-07-26)

info: checking for self-updates

I've been seeing this warning as well on the CI for winapi. I'm pretty sure the downside of getting this warning in situations where the toolchain should clearly work outweighs the benefit of stopping users from installing a toolchain which will not work anyway.

@retep998 Yes, we're trying to resolve the issue, we're aware of what it ought to be and we can fix it fairly easily. A fix is being worked on here - #2854

In #2854 the fix is in for partial toolchain names, and has a test, so the next release of rustup should fix the major pain of Windows at least. If anyone affected here is comfortable building a local rustup and trying it then that'd be useful, but I think it should be good. however it doesn't prevent the toolchain warning message when installing the musl toolchain on gnu linux for example, that remains something that in theory could yet be a problem for users so is worthy of the warning for now.

The thing is the suggested option --force-non-host doesn't actually work right now. It's bad UI to suggest an option that doesn't even exist ;)

I'm on an M1 Mac trying to install some old stable releases (which only have x86-64 versions). I do get it warning, but the error message is a little annoying 😉