Now that clippy should no longer break since it receives rustc-fixes automatically, do we still need to use the rustc master toolchain?
I wonder if we could use a rust-toolchain file to pin clippy to a certain nightly version inside this repo.
This could make sure that clippy always compiles for people adding new lints and we might no longer require the rustc master toolchain to build it, the correct nightly would be installed automatically.
If someone merges changes done in the rustc repo down to this clippy repo and resolves the merge conflicts, the nightly version would be bumped to that nightly.
However I am not sure how a rustc-toolchain file will behave if it is found inside a subdir of the rustc repo...
Also this might introduce a 24 hour delay if we need to wait for a new nightly to be released in some cases (might happen around releases? I don't know). :/
+1 for pinning a nightly
I wonder if we could use a rust-toolchain file to pin clippy to a certain nightly version inside this repo.
However I am not sure how a rustc-toolchain file will behave if it is found inside a subdir of the rustc repo...
I hope a rust-toolchain file doesn't break in the rust repo, since we currently have one in the Clippy repo. I always wondered why.
If someone merges changes done in the rustc repo down to this clippy repo and resolves the merge conflicts, the nightly version would be bumped to that nightly.
We should put a policy in place, that every sync should bump the pinned nightly version to the latest nightly. This policy should be enforced by a GHA somehow (Maybe with a check in clippy_dev). We should then add a cargo dev update_nightly command that updates the nightly version, wherever necessary.
Also this might introduce a 24 hour delay if we need to wait for a new nightly to be released in some cases
Once we pinned a nightly, we won't be forced to update the nightly version. A policy of no changes in the rust-lang/rust clippy subtree in the no-toolstate-breakage week may be good. But this has to be accepted by the infra team and is not our decision. We should definitely always get a sync in the no-toolstate-breakage week in the rust repo, if this should be problematic, we can ask for that policy to be implemented. As long as we still use rustc master that won't be a problem.
For every step here, I would suggest that we do a few syncs to get familiar with the new workflow and then move on with automation/pinning nightlies/...
However I am not sure how a rustc-toolchain file will behave if it is found inside a subdir of the rustc repo...
I think as long as all commands are executed from the rustc repo root, everything will be fine. The toolchain file is only active for the directory it is in and its subdirectories. (https://github.com/rust-lang/rustup#override-precedence)
I tried to get this to work but hit a wall because clippy requires the rustc-dev component which is not downloaded by default and there is no way to tell rustup to install it via the rust-toolchain file :(
clippy requires the rustc-dev component which is not downloaded by default and there is no way to tell rustup to install it via the rust-toolchain file
A somehow dirty hack is to call rustup from the build.rs file to install the component
Good news, https://github.com/rust-lang/rustup/issues/2350 has been closed so this will become unblocked after the next rustup release! 馃帀
Most helpful comment
Good news, https://github.com/rust-lang/rustup/issues/2350 has been closed so this will become unblocked after the next rustup release! 馃帀