Posts tagged "clippy" | Rust Blog

Together for a healthier Clippy

2026-07-06T00:00:00+00:00

Together for a healthier Clippy

Clippy is a very loved piece of software, with the fortune of having many contributors willing to do high-quality pull requests with very needed features and bug-fixes. We are extremely thankful for every single contributor who not only took the time to learn about Clippy’s internals, but also felt comfortable enough to show their work and maintained communication in order to ship it.

That’s why we’re addressing them with this health report of Clippy as an open source project.

The truth is that Clippy has a reviewing capacity problem, and we’ve been having it for the last few months. Unlike some other Rust teams, no one from the Clippy team is currently funded to work on Clippy, not even on a part-time basis. The burden of maintenance thus falls squarely into the maintainer’s free time, eventually leading to burnout.

We hope that the newly established Rust Foundation Maintainers Fund will be able to help secure some funding for Clippy maintainers. If you'd like to help, consider donating to the fund.

That’s why we are launching an initiative in which contributors help themselves get their pull request reviewed and merged faster.

What does this mean

Once a contributor opens a pull request, we propose they review another contributor’s pull request. That way each contributor reviews at least one pull request and nobody’s contributions get stale.

The underlying mechanism looks like this: Once a contributor opens a pull request, our dear bot @rustbot will prompt them to look at other pull requests (preferably ones without any other reviews). After they’ve reviewed a pull request, the contributor gets on a special secret list of cool ones, and priority on their pull request from the team's reviewers.

We want to thank the Bevy project and their "Open Code Review" system as an inspiration for this new initiative.

We've done this in the past

Clippy is no stranger to health updates of this kind, last year we had the Feature Freeze, which was an absolute success. In that process, we gained knowledge, trust, and the certainty that the Rust community cared about Clippy, and Clippy doing things right.

Once again, the team wants to thank and congratulate every single person, contributor or not, that cares about Clippy. Striving for excellence is what makes this linter (and language) so loved, and with the help of the community (of YOU), we can help Clippy become stronger and healthier.

What we learned with Clippy's feature freeze

2025-10-22T00:00:00+00:00

The feature freeze affecting Clippy has reached its end date. This means that the Clippy project has been accepting pull requests that add new features (and new lints) for a while.

The Clippy team has reviewed the results, and we can say that it's been a success 🎉. It has been so great that we managed to create an all-time peak in the number of pull requests opened in a week.

In this plot we can observe that peak (the red lines mark the start and end of the feature freeze)

After some data crunching of those pull requests opened after June 26th, we had 18 pull requests open in that period that added lints. With 326 pull requests open by both new and old contributors, we want to highlight all the new people that started contributing to Clippy, 47 new contributors who opened a total of 195 pull requests.

On a team meeting, we concluded that the results of the feature freeze were positive enough to warrant a future one. The cadence and duration of these is still being decided.

58% of all pull requests by new contributors (114 out of the total 195) were opened by the same person. We held a meeting with her (ada4a on Github) to iron out some of the details of the codebase and our procedures for new contributors. We are currently analyzing that meeting in order to improve the experience for future and current contributors.

We also asked some questions to Ada (ada4a) to include as a mini Q&A, here are some of the answers.

Ada's Q&A

Why do you like contributing to Clippy? What's so fun about it?

I came to enjoy improving the suggestions that Clippy makes: they are fascinating in how they point out the exact part of code that is problematic, and show the (sometimes pretty complex) manipulations required to fix it. Also, It has been empowering to learn the machinery behind the compiler, and use that knowledge to refine these diagnostics even further.

Would you recommend contributing to Clippy? Why or why not?

Yes, for multiple reasons:

Rust is (in)famously hard to learn, and to me, Clippy is one of the parts of the toolchain most helpful for beginners, as it teaches idiomatic style and helps discover helpful functions from std -- thus, contributing to it helps reduce the entry barrier of the language.
If you, like me, wanted to learn the inner workings of the compiler and contribute to it some day, but were intimidated by the development setup required for that, Clippy could be a nice stepping stone, as hacking on it doesn't require compiling rustc, but it interacts with a lot of compiler's data structures and APIs.

Announcing the Clippy feature freeze

2025-06-21T00:00:00+00:00

The Clippy project will be on feature-freeze for 12 weeks, starting from Rust 1.89.0 beta (June 26th 2025) to September 18th 2025 (Rust 1.89.0 stable release). During this time no new features will be accepted, only bug fixes.

This feature freeze comes from a lack of the necessary capacity needed to maintain all the current lints (over 750 of them 😱) and still add new ones. We need to care for the Clippy project the same way that Clippy cares about our code, and note that every single one of them needs maintaining and accounting for current and future changes in the compiler as a whole.

As a team we’ll focus on making contributing the best it can be, and mark the issues that could be great as a starting point to get familiar with the project.

What can I expect as a user?

As a user you can expect to have more accurate lints, with less false positives and more edge cases covered. A bump into Clippy’s toolchain would not involve the same risk for false positives as it has been until now. We hope that by upping the standard for lints all around the project we can allow users to expect even more from the already great linter.

If you have a lint which you want to be implemented, you can still open an issue for it, but PRs adding new lints won't be reviewed during the feature freeze. Instead, they will be put into a queue and reviewed (and merged) after the feature freeze is over.

Open pull requests that add new lints and are in a very advanced state might still get reviewed and/or merged during the feature freeze.

Can I help?

As always, any help on the project is very appreciated. Apart from opening bug reports, you can follow our contributing guidelines and check our suggested good first issues for opening pull requests. Everything from fixing diagnostic issues and improving documentation, to fixing application-wide crashes really helps Clippy get into the excellent state that our users deserve.

If you need direct help when fixing a bug, don't hesitate to open a thread on Zulip and/or open a draft PR with the questions you have in order to start the feedback stream.

Conclusion

Thanks a lot for all these years of supporting Clippy, we hope that via this little feature hiatus we can achieve the excellence that the Rust user base deserves.

Clippy: Deprecating `feature = "cargo-clippy"`

2024-02-28T00:00:00+00:00

Since Clippy v0.0.97 and before it was shipped with rustup, Clippy implicitly added a feature = "cargo-clippy" config^[1] when linting your code with cargo clippy.

Back in the day (2016) this was necessary to allow, warn or deny Clippy lints using attributes:

#[cfg_attr(feature = "cargo-clippy", allow(clippy_lint_name))]

Doing this hasn't been necessary for a long time. Today, Clippy users will set lint levels with tool lint attributes using the clippy:: prefix:

#[allow(clippy::lint_name)]

The implicit feature = "cargo-clippy" has only been kept for backwards compatibility, but will be deprecated in upcoming nightlies and later in 1.78.0.

Alternative

As there is a rare use case for conditional compilation depending on Clippy, we will provide an alternative. So in the future (1.78.0) you will be able to use:

#[cfg(clippy)]

Transitioning

Should you only use stable toolchains, you can wait with the transition until Rust 1.78.0 (2024-05-02) is released.

Should you have instances of feature = "cargo-clippy" in your code base, you will see a warning from the new Clippy lint clippy::deprecated_clippy_cfg_attr available in the latest nightly Clippy. This lint can automatically fix your code. So if you should see this lint triggering, just run:

cargo clippy --fix -- -Aclippy::all -Wclippy::deprecated_clippy_cfg_attr

This will fix all instances in your code.

In addition, check your .cargo/config file for:

[target.'cfg(feature = "cargo-clippy")']
rustflags = ["-Aclippy::..."]

If you have this config, you will have to update it yourself, by either changing it to cfg(clippy) or taking this opportunity to transition to setting lint levels in Cargo.toml directly.

Motivation for Deprecation

Currently, there's a call for testing, in order to stabilize checking conditional compilation at compile time, aka cargo check -Zcheck-cfg. If we were to keep the feature = "cargo-clippy" config, users would start seeing a lot of warnings on their feature = "cargo-clippy" conditions. To work around this, they would either need to allow the lint or have to add a dummy feature to their Cargo.toml in order to silence those warnings:

[features]
cargo-clippy = []

We didn't think this would be user friendly, and decided that instead we want to deprecate the implicit feature = "cargo-clippy" config and replace it with the clippy config.

It's likely that you didn't even know that Clippy implicitly sets this config (which was not a Cargo feature). This is intentional, as we stopped advertising and documenting this a long time ago. ↩

Changes at the Clippy Team

2022-07-13T00:00:00+00:00

New Members

We are thrilled to publicly announce that Alex Macleod, dswij, and Jason Newcomb have joined the Clippy Team!

Jason has been contributing to Clippy since late 2020 and was the most active contributor since then. He has contributed in pretty much every area - big refactors, bug fixes, and major improvements to our Clippy utils. Having him as an additional reviewer will be a great improvement to the team.

dswij first started contributing late last summer and has fixed many bugs in Clippy as well as implementing some new lints to make Clippy even more helpful. With their continued contributions to Clippy and engagement in the project, we're happy to now have them as a full team member.

Alex started contributing to Clippy shortly after and has improved our dev tooling quite a bit. Now he wants to continue focusing on our lintcheck tool, which will help detect false positives in new lints before we release them to the public. We're excited to have Alex on our team and looking forward to all the improvements he will bring in the future.

With the new additions to the team, we should be able to handle our long PR queue better. We currently have over 40 open PRs, which is a good sign for the health of the project, but doesn't help when we don't have the reviewers to merge them. Now we do!

Alumni

At the same time, we recently granted some of our oldest members the well-deserved alumni status. We want to thank Pascal Hertleif and Martin Carton for all their contributions, especially in the early days. People joining today probably never worked with them on Clippy, but without them, we probably wouldn't be here.

We also want to thank Philipp Hansch for their contributions to Clippy and all of the review work they've done over the years. To this day phansch is one of the most active Clippy contributors (measured by the number of commits).

And finally, thank you to mikerite, who stepped down from an active reviewer/team member position but will be staying on as a contributor. We're looking forward to continue working with them!

Clippy is removing its plugin interface

2019-11-04T00:00:00+00:00

Today, we're announcing that Clippy will completely remove its plugin interface. Using the plugin interface has been deprecated for about one and a half year now (rust-lang/rust-clippy#2712). Since then, an unsilenceable warning has been emitted. Now that compiler plugins are officially deprecated (rust-lang/rust#64675), Clippy will remove its support for the plugin interface completely (rust-lang/rust-clippy#4714). This change will hit stable with version 1.41.0.

Does this post affect me?

Most likely, no. This post only affects you, if you're still using Clippy through its plugin interface. If you do so, you get the warning

warning: the clippy plugin is being deprecated, please use cargo clippy or rls with the clippy feature

when compiling your crate. If you don't see this warning, nothing will change for you.

How do I migrate from the plugin interface?

If you are still using the Clippy plugin interface, here are some steps you can take to migrate to cargo clippy.

Cargo.toml: Remove every occurrence of the clippy dependency and the clippy feature.
Completely remove every occurrence of feature(plugin) and plugin(clippy).
Replace every occurrence of feature = "clippy" with feature = "cargo-clippy". The cargo-clippy feature is automatically enabled when running cargo clippy.
CI: You now have to install Clippy via rustup, with rustup component add clippy. Once installed, you can run cargo clippy (for more usage instructions, see the Clippy README). Note that Clippy is not included in every nightly, but you can check its availability on the rustup components history page.

Where should I go if I have more questions?

If you need help with migrating from the plugin interface, you can contact us via Discord or open an issue on GitHub.