Optimizing Clippy & linting
(a.k.a The Clippy Performance Project)
| Metadata | |
|---|---|
| Owner(s) | Alejandra González |
| Teams | clippy |
| Status | Accepted |
| Tracking issue | rust-lang/rust-project-goals#114 |
Summary
This is the formalization and documentation of the Clippy Performance Project, a project first talked about on Zulip, July 2023. As the project consists of several points and is ever-changing, this document also has a dynamic structure and the team can add points.
In short, this is an effort to optimize Clippy, and Rust's linting infrastructure with a point of view of making Clippy faster (both on CI/CD pipelines, and on devs' machines)
Motivation
Clippy can take up to 2.5 times the time that a normal cargo check takes, and it doesn't need to be! Taking so long is expensive both in development time, and in real money.
The status quo
Based on some informal feedback [polls][poll-mastodon], it's clear that Clippy is used in lots of different contexts. Both in developer's IDEs and outside them.
The usage for IDEs is not as smooth as one may desire or expect when comparing to prior art like [Prettier][prettier], [Ruff][ruff], or other tools in the Rust ecosystem rustfmt and Rust-analyzer.
The other big use-case is as a test before committing or on CI. Optimizing Clippy for performance would fold the cost of these tests.
On GitHub Actions, this excessive time can equal the cost of running cargo check on a Linux x64 32-cores machine, instead of a Linux x64 2-cores machine. A 3.3x cost increase.
The next 6 months
In order to achieve a better performance we want to:
- Keep working on, and eventually merge rust#125116
- Improve of checking on proc-macros & expansions, maybe by precomputing expanded spans or memoizing the checking functions.
- Optimize checking for MSRVs and
#[clippy::msrv]attributes. (Probably using static values, precomputing MSRV spans?) - Migrate applicable lints to use incremental compilation
Apart from these 4 clear goals, any open issue, open PR or merged PRs with the label performance-project are a great benefit.
The "shiny future" we are working towards
The possible outcome would be a system that can be run on-save without being a hassle to the developer, and that has the minimum possible overhead over cargo check (which, would also be optimized as a side of a lot of a subset of the optimizations).
A developer shouldn't have to get a high-end machine to run a compiler swiftly; and a server should not spend more valuable seconds on linting than strictly necessary.
Ownership and team asks
Owner: Alejandra Gonzalez, a.k.a. Alejandra González
| Subgoal | Owner(s) or team(s) | Notes |
|---|---|---|
| Optimization work | ||
| ↳ Implementation | Alejandra González, Alex Macleod | |
| ↳ Standard reviews |  clippy |
Frequently Asked Questions
[poll-mastodon]: https://tech.lgbt/Alejandra González/112747808297589676 [prettier]: https://github.com/prettier/prettier [ruff]: https://github.com/astral-sh/ruff