Find and correct all places recommending `rustup install` and `rustup uninstall`

[kinnison]

We want to deprecate rustup install and rustup uninstall in 1.21.0 -- as such as indicated in #2096 (comment) we need to find and correct anywhere major which recommends the use of these deprecated interfaces.

NOTE Our ideal outcome is that the rustup install and rustup uninstall CLI API remains available into the future as a pure alias to rustup toolchain XXX which currently due to limitations in clap it is not.

ALSO NOTE We want the "correct" CLI API documented, so this work remains wanted.

FINALLY With #2149 we intend to not emit a warning but rather only verbose indicators that the current rustup install and rustup uninstall may not behave exactly as the rustup toolchain XXX interface and that will change when the alias work is done.

This issue is meant to track that documentation fixup work:

• The Book, for example here
• The edition guide, for example here
• Miri's README, for example here

Until all those (and any further high profile instances) are resolved, we should not release 1.21.0

If you find new instances of rustup install and rustup uninstall in high profile documentation, please comment below so we can track it. Ditto if you file a PR to get that fixed to use rustup toolchain install etc, then please comment so that we can track the PR.

[trolleyman]

Please don't do this -- this makes rustup less easy to use! Just check the comments of https://www.reddit.com/r/rust/comments/e7rer9/we_need_your_help_before_rustup_1210_can_be/

Can someone explain what the main reason is for this change?

[AxelMontini]

IMO it doesn't make any sense.

• rustup override overrides the default toolchain.
• rustup check checks for toolchain updates.
• and so on

Either:

1. We group every toolchain-related command under rustup toolchain
2. We remove rustup toolchain and keep everything as a rustup command.

I find that separating toolchain-related commands (some under rustup toolchain, others not) just makes the tool less intuitive to use.
I prefer the current situation (or the second option I listed) over this.

[brson]

I would encourage careful deliberation about actually removing these commands. Maybe it is best to actively discourage their use, in the hopes of removing them someday, though I am not sure. I am doubtful about removing them completely in the near term.

These commands are commonly used, are possibly more intuitive than the alternative, and have effectively no maintenance burden. Since rustup is used by nearly the entire rust community, any disruption it causes will have a negative effect on goodwill.

Some tools need to "just work", and sometimes have to carry backwards-compatibility baggage to do so.

[pantsman0]

A tool should never never take away a feature that isn't a significant bug.

It is very simple. If you teach users that your tool breaks when you update, they will not update.

[kennytm]

Rather than implementing rustup install and rustup uninstall as hard-coded commands like #2096, perhaps rustup could adapt cargo's "[alias]" system and handle install/uninstall as a part of this.