Update is happening even if user has a tool and that tool is missing

[nrc]

This should require --force.

cc rust-lang/rls#641

[kennytm]

We need to block nightly on RLS etc. again if rustup cannot prevent uninstall of manually added components.

(cc @rust-lang-nursery/infra) (P.S. we need to sync the team members between the two orgs...)

[pietroalbini]

The generated manifests when rls is missing are wrong.

The rustup behavior was changed in #1419 to handle removed components (when the docs for some tier 2 platforms were removed and users weren't able to update), but the old behavior is still present when the component is marked as available = false in the manifest.

Currently there is no mention of rls in the nightly manifest at all. The easiest way to fix is to keep rls in the manifest but mark it as unavailable, and this doesn't require any rustup update.

[nrc]

This should be fixed with @pietroalbini's PR

[sfackler]

When will that fix propagate out? The 2018-08-29 nightly still upgraded and warned about missing rls-preview and clippy-preview components.

[nrc]

It should have worked today :-(

[nrc]

In today's manifest, rls and Clippy have available = false as expected, so I guess there must be a problem with Rustup

[pietroalbini]

Nope, experimented with this for a bit locally, and it's still a manifest problem. While the components themselves are available = false, they're still missing from the rust package. If we add to the manifest this snippet (for example) rustup behaves correctly for clippy on linux and prevents the download:

[[pkg.rust.target.x86_64-unknown-linux-gnu.components]]
pkg = "clippy-preview"
target = "x86_64-unknown-linux-gnu"

The error messages are still really bad, but at least we don't upgrade people with components installed. I'll look into sending a PR to rustc soon to tweak manifest generation again.

[pietroalbini]

Ok, this should be fixed now.