I don’t really feel like this is necessary. We can move it in tree to support the rustup component add release case without having that discussion. If moved in tree cargo-clippy would still exist out of tree (open to vendoring that too, but it’s not necessary). The current policy has clearly been “no new lints in rustc” for a while AIUI. We can discuss changing it, and perhaps even just merging clippy into rustc’s inbuilt lints directly, but that doesn’t have to block this. Again, we shouldn’t be parceling harder problems with easier ones; these are independent issues and can be solved piecemeal.
(At the same time, I do want this discussion to happen – would love to see at least some lints upstreaming to rustc, since this was originally one of the goals of clippy, before the “no new lints” policy)
Setting up that tooling sounds itself like a fair amount of work, so that makes me a bit nervous.
Doesn’t really feel that way to me – you check if the optional components have a corresponding file on the server, and if not, try previous nightlies until you’re back to the currently installed nightly. It’s work, but won’t be too complex IMO. I might be missing something of course 
I think a good strategy there is for the Clippy or rustfmt maintainers to offer to take the PR over the finish line,
FWIW this has always been part of the discussion and is IIRC agreed upon by clippy maintainers . While we would appreciate if rustc folks would help, we’d still be driving clippy breakage fixes, either after the fact in a nongated world, or by working with PR authors in a gated world.
I do think that if we are gating then we should move the clippy lint code into tree, not as a submodule. Submodules requiring coordinated updates are annoying. Clippy devs would be able to work around this, but this would be annoying for rustc folks – for efficiently working with submodules you need push access to the submodule’s repo so that you can make temporary branches, which works for a small set of devs but will be annoying for anyone who doesn’t have push and wants to make a PR that breaks clippy.
When we’re talking about the old “broken nightly” situation I think there’s a bit of a false equivalence being made here. A nightly, or cargo, being broken is a very bad thing. But a clippyless nightly is really fine – assuming that rustup protects you from updating to it (with the option to force update anyway). In case the beta is broken off a broken clippy nightly there are six weeks to fix that, so we don’t have to worry much about this affecting stable (and again, clippy maintainers will help with this). So while I am very happy that all PRs are gated on “can this produce a valid nightly” by being equivalent to a dist build, I don’t think this is necessary for things which could be optional in a dist build.
Ultimately I’m fine with gating on clippy per build – in fact, I prefer it, since it’s easier to fix things in the same PR that breaks it instead of trying to figure stuff out after it lands, especially if it removes capabilities we depended on. But I don’t think this is absolutely necessary for rustup-packaged stable clippy to work.
(My main concern with only fixating on the “gate on clippy” solution is that there may be opposition from the rustc devs, which ultimately ends up just blocking anything from happening. It’s always good to have options open.)
empirically this can take on the order of weeks to fix to finally catch up to master (after which it all restarts again).
(Clippy nightly fixes take like a day or two. Can take up to a week, in rather rare situations, which usually are involving PRs to rustc.)
