Open
Description
When working on #75573, I ended up needing to modify Clippy (both a lint implementation and some UI tests). This process left a lot to be desired, and could be a significant roadblock to new contributors. I came up with some ideas for improving the process:
- Run Clippy tests on the PR builder (if we have the CI budget). My PR was initially approved, then unapproved due to a (correct) suspicion that Clippy UI tests would be broken. However, this could easily be missed on other PRs, leading to wasted merge queue time and failed rollups. By running these tests on the PR builder, we could catch Clippy changes prior to PR approval.
- Allow running Clippy tests in-tree from stage1. Currently, running
./x.py test src/tools/clippy
requires a full compiler bootstrap (e.g. building a stage2 compiler). This takes a significant amount of time, and interacts badly with incremental compilation. For contributors with lower-end machines, this may make the contribution process incredibly frustrating. Attempting to build Clippy against a stage1 compiler (which requires running./x.py test src/tools/clippy --stage 0
for some reason) works, but the tests fail with a confusing error about LLVM being missing. - Integrate Clippy UI tests with
./x.py test --bless
. Currently, blessing Clippy UI tests requires manually running scripts from insidesrc/tools/clippy
. It would be nice if./x.py test --bless
worked on all UI tests, allowing Clippy to be largely treated as 'just another directory'. - Document the interaction between
-D warnings
and Clippy lints. It seems as though denying a built-in lint with-D warnings
prevents Clippy lints from being run. Since Clippy UI tests are run with-D warnings
, adding a new builtin Rust lint can end up preventing Clippy UI tests from testing Clippy lints. Ideally, we would allow both sets of lints to run - if this is not possible, we should document the workaround (adding#![allow(problematic_rustc_lint)]
to the affected Clippy UI tests).