Rustup: Ignore a nightly update if it breaks existing installed tools.

[alatiera]

Every now and then there's a nightly which breaks tools like rustfmt and clippy, which is to be expected.
But that kinda sucks if you want to update nightly regular.

What if there were 2 distribution channels for nightly.

One bleeding edge like now, and another where rustup would understand if the new build of nightly would brake existing tools, and would not distribute that update unless you explicitly request it.

That way you could run rustup update everyday without fearing of your stuff breaking.

[alatiera]

This could also be useful for CI builds where a built would fail cause it couldn't compile clippy/rustfmt that day.

[gnzlbg]

IMO it would simply be better if the last step of rust-nightly builds would be to build clippy, rls, and rustfmt-nightly, and ship those along with rustup (e.g. rustup install rustfmt-nightly). If either clippy or rustfmt-nightly fail to build, then the whole nightly build should just fail.

CI-wise when bors first runs the tests on a PR it should, as a last step, try to build rustfmt-nightly and clippy, to let people know in advance that a rust change will break any of these tools. Maybe they can submit a PR to rustfmt/clippy/rls that fixes the breakage, and tell bors about it, so that when borg merges a rust-lang PR it also merges the fix in the corresponding tool.

[jkeiser]

I agree regarding rustup, but ... it still feels weird ergonomically for an rustup update to give me a less capable toolchain. Seems like this should be done as well. Not all components we install will be part of the toolchain at all times.

[jkeiser]

(rls is another component that has trouble.)

[Diggsey]

This should be fixed now.