toolchain '$toolchain' may not be able to run on this system UX is not working well

[Folaht]

Wanting to use musl instead of gnu, I run into this issue:

$ rustup toolchain add stable-x86_64-unknown-linux-musl
warning: toolchain 'stable-x86_64-unknown-linux-musl' 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 x86_64-unknown-linux-musl` instead?
info: syncing channel updates for 'stable-x86_64-unknown-linux-musl'

  stable-x86_64-unknown-linux-musl unchanged - (error reading rustc version)

Notes

$ rustup --version
rustup 1.23.1 (2020-12-18)
info: This is the version for the rustup toolchain manager, not the rustc compiler.
info: The currently active `rustc` version is `(error reading rustc version)`

$ rustup show
Default host: x86_64-unknown-linux-gnu
rustup home:  /home/folaht/.rustup

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

stable-x86_64-unknown-linux-gnu
stable-x86_64-unknown-linux-musl (default)

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

stable-x86_64-unknown-linux-musl (default)
(error reading rustc version)

[rbtcollins]

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.

[rbtcollins]

@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).

[Diggsey]

@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.

[rbtcollins]

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.

[Diggsey]

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).

[rbtcollins]

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.