Decide how the `--force-non-host` flag should evolve

[rami3l]

I actually don't think this is a good way forward, since host_arch.can_run() relies on hardcoding and is fragile. The warnings below seem sufficient.

Originally posted by @rami3l in #3980 (comment)

[rami3l]

I personally think this should be a natural closing step to #3635. Once implicit installations are removed, there should be fewer places that require --force-non-host. Also, given the fragility of host_arch.can_run(), the deprecation notice should be removed.

We should not remove the flag completely though:

it looks like we already have some users who rely on this flag: https://github.com/search?q=%22--force-non-host%22&type=code

#3980 (comment)

... so I recommend changing the flag to only suppress the warnings, and these warnings can of course be inaccurate, as suggested by their current wording.

[djc]

Makes sense.

[rami3l]

So the point of this was to support cross-rs properly (they need non-host toolchains), while stopping people that are just following their nose from getting stuck and confused. E.g. installing an arm64 toolchain on an amd64 machine and wondering why that breaks.

cross-rs should be updated by now I believe, so the appropriate action is to remove the warning and reject non-host toolchains unless the flag is provided.

Originally posted by @rbtcollins in #3980 (comment)

[rami3l]

So the point of this was to support cross-rs properly (they need non-host toolchains), while stopping people that are just following their nose from getting stuck and confused. E.g. installing an arm64 toolchain on an amd64 machine and wondering why that breaks.
cross-rs should be updated by now I believe, so the appropriate action is to remove the warning and reject non-host toolchains unless the flag is provided.

Originally posted by @rbtcollins in #3980 (comment)

After https://discord.com/channels/442252698964721669/463480252723888159/1284703690204385290 and other similar issues showing a common confusion between rustup target and rustup toolchain, I've changed my mind.

Now I'm more convinced that we should go with the original plan with --force-non-host, that is denying all toolchain installations built for a different host target unless this flag is present, or the host target is among a known list of exceptions. We should be able to afford extending this list of exceptions manually from time to time, given that it's not changed very often...

[djc]

Now I'm more convinced that we should go with the original plan with --force-non-host, that is denying all toolchain installations built for a different host target unless this flag is present, or the host target is among a known list of exceptions. We should be able to afford extending this list of exceptions manually from time to time, given that it's not changed very often...

Sounds sensible to me...