Decouple nightly RLS from Clippy

[Xanewok]

Context

As you must've noticed the RLS and Clippy are not shipped with nightly builds for quite a few releases now. This happens when a change lands to the Rust compiler and a tool cannot be built or its test fail when using the currently built compiler. Currently, the RLS explicitly depends (in Cargo sense) on Clippy, which means that whenever Clippy cannot build, the RLS also fails the build and is thus not included in the nightlies.

In practice, there's a lot more breakage involved for the Clippy since it uses rustc internals quite heavily (e.g. directly inspects AST/HIR structures), while the problem is sidestepped by the RLS by relying on the internal Rust librustc_save_analysis library doing all the heavy lifting and outputting relevant information to JSON.

While specifically the current breakage requires more work/coordination (caused by moving libtest out of tree, please help with #59440 if you know how!) and has caused more fallout than typical breakages, and regardless of the fact that we don't guarantee component availability for the nightly channel, I'd like us to try our best and ship RLS if possible, even without Clippy support.

Implementation

Implementation-wise I believe this can be done by running Clippy tool test first and if it's detected as failed by rustbuild, then it will try to build RLS in the --no-default-features mode (Clippy support is gated by the only default clippy feature). When RLS is built without Clippy support, we can warn the user on start up that that version has no Clippy support enabled because it's not available in that build.

Alternatives

Create a separate rustup-complete channel that's only released with all the tools

While this may be a somewhat viable or desired idea:

• IIRC the current breakage lasts for 1-2 weeks now which is the 1/3 of a version release cycle (...which makes it more of a fortnightly release)
• requires more infrastructure/implementation effort in the rustup/rustbuild
• doesn't solve the case for the regular nightly release, which is often the case for people actively working on the compiler or related tooling (hurts contributability)

Do nothing

We just 🤷‍♂️ and tell people to move off nightly or pin to a specific nightly release.

That's not great because there's still a fair chunk of the ecosystem that's bound to nightly features. If we make them pin to a specific release, then there's UX/discoverability issue.

Right now, when the user either tries to update the preexisting toolchain or install a fresh one with RLS, they fail with an uninformative "rls component is unavailable" message. Then, they need to either learn about or navigate to https://rust-lang.github.io/rustup-components-history/ to learn which was the most recent toolchain with RLS shipped (even then, right now it's impossible since the history shows "missing" for the last 8 ones) or find and use a script that parses the recent nightly build manifests and finds the most recent one. And that's for every tool breakage, which can happen quite often.

Thoughts?

cc @nrc @oli-obk @rust-lang/infra @rust-lang/dev-tools

[Manishearth]

FWIW the current breakage is very much not the norm, it's due to some complex things with the libtest stuff and a lack of time from the people who understand rust's build system. It took this long because we kept waiting on others, otherwise clippy breakages get fixed in one or two days.

We're reverting the libtest stuff so that clippy can work again.

Create a separate rustup-complete channel that's only released with all the tools

This is being worked on too.

[Manishearth]

Overall the UX experience of nightly users who want to use tooling is actively being worked on by @kinnison , the rough plan right now is to have rust publish a "last known good" nightly version for a subset of tools, and teach rustup about it.

Overall we seem to be shifting towards shipping RLS and clippy together, always (instead of people using tools individually leading to more permutations), so the fix proposed here won't really help much once we get there.

[Xanewok]

FWIW the current breakage is very much not the norm

I tried to emphasize that in the OP as well, hope that's visible there

I'm also aware of the work done in the Rustup area (which is great!), however I believe there's a lot of merit of doing the best-effort thing here and keeping the RLS separate from Clippy on the build level.

I know there was an idea/conversation/RFC (by @nrc I believe) to introduce rustup "profiles", which is a set of components included in the profile (e.g. tools would include rls, clippy, rust-src, rust-lldb, ...).
This would wholly solve the another toolnightly channel and would also allow to streamline the tooling development, as you're saying is the shift now.

Now that I think about it, it seems weird for the rls component to duplicate clippy and rustfmt components internally. Right now, RLS also supports externally invoked Rustfmt - I wonder if we should try to do the same for Clippy and measure the overhead?

[Manishearth]

Now that I think about it, it seems weird for the rls component to duplicate clippy and rustfmt components internally. Right now, RLS also supports externally invoked Rustfmt - I wonder if we should try to do the same for Clippy and measure the overhead?

This sounds like a good step forward.

Yeah, I'm all for separating things out, I just want to caution against doing it as a reaction to what is mostly a one-time thing.

[matthiaskrgr]

Right now, when the user either tries to update the preexisting toolchain or install a fresh one with RLS, they fail with an uninformative "rls component is unavailable" message. Then, they need to either learn about or navigate to https://rust-lang.github.io/rustup-components-history/ to learn which was the most recent toolchain with RLS shipped (even then, right now it's impossible since the history shows "missing" for the last 8 ones) or find and use a script that parses the recent nightly build manifests and finds the most recent one.

Shameless plug: rust-lang/rustup#1501 would probably help here.

[kinnison]

Overall the UX experience of nightly users who want to use tooling is actively being worked on by @kinnison , the rough plan right now is to have rust publish a "last known good" nightly version for a subset of tools, and teach rustup about it.

We're still thinking about this within wg-rustup. @nrc has some reservations with the early plans, but we're proceeding, slowly, toward something we think is plausible given the reduced bandwidth in wg-rustup.

[aidanhs]

We discussed this in the infra meeting last week - long story short, we'd prefer not to paper over the cracks with a quickfix (rustup-complete) at this point in time as it doesn't feel very high priority and it sounds like wg-rustup may be making (slow) progress on it.