Enable more clippy lints - #24466
Merged
Dandandan merged 15 commits intoAug 21, 2026
Merged
Conversation
Copy link
Copy Markdown
Contributor
Sorry, something went wrong.
Turn on the whole `pedantic` group and opt out of individual lints, rather than opting in to them one at a time. `pedantic` has 143 lints on the toolchain we pin. 58 of them were already enabled explicitly, so those lines are gone. 72 lints still fire, so they are set to "allow" with their hit count recorded. The other 71 fire nowhere and are now enforced, 13 of them for the first time: copy_iterator, doc_broken_link, maybe_infinite_iter, naive_bytecount, no_mangle_with_rust_abi, nonminimal_bool, overly_complex_bool_expr, ptr_offset_by_literal, range_minus_one, ref_binding_to_reference, unnecessary_join, unsafe_derive_deserialize and verbose_bit_mask. No code changes: `cargo clippy --workspace --all-targets --all-features` reports no warnings. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
`all` covers the correctness, suspicious, style, complexity and perf groups, which clippy already warns about by default, so nothing new fires and no lint needs an opt-out. It does make one explicit opt-in redundant: `unnecessary_lazy_evaluations` is a member of `all`, so its line is gone. The other 46 explicit lints are in `restriction` or `nursery`, which `all` does not cover. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Use inclusive ranges instead of `a..b + 1`. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Use `sort_unstable` where the element type makes sort stability irrelevant. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Match on `Ord::cmp` instead of chaining `<`, `==` and `else`. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Name the expected panic so the test cannot pass on an unrelated panic. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Use `assert_eq!`/`assert_ne!` (and the `debug_` variants) so a failure prints both values. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
emilk
force-pushed
the
emilk/enable-more-pedantic-lints
branch
from
8bb85a9 to
c201ca1
Compare
August 18, 2026 19:55
Copy link
Copy Markdown
Codecov Report❌ Patch coverage is 75.05882% with 106 lines in your changes missing coverage. Please review. @@ Coverage Diff @@
## main #24466 +/- ##
==========================================
- Coverage 81.32% 81.31% -0.01%
==========================================
Files 1117 1117
Lines 396759 396649 -110
Branches 396759 396649 -110
==========================================
- Hits 322658 322537 -121
- Misses 55197 55202 +5
- Partials 18904 18910 +6 ☔ View full report in Codecov by Harness.
|
Sorry, something went wrong.
Use `for` loops instead of `for_each` on iterators, which reads better and allows `break`, `continue` and `?`. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Use `let ... else` instead of a `match` whose only job is to bind one pattern and diverge on the rest. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
emilk
force-pushed
the
emilk/enable-more-pedantic-lints
branch
from
c201ca1 to
e72d6e3
Compare
August 19, 2026 03:01
emilk
marked this pull request as ready for review
August 19, 2026 06:40
`for x in &v` / `&mut v` / `v` instead of `v.iter()` / `v.iter_mut()` / `v.into_iter()`, for the loops that the previous commit rewrote from `for_each`. This is what `explicit_iter_loop` and `explicit_into_iter_loop` ask for; both are still allowed workspace-wide because the rest of the codebase has many more of them. Two loops in `repartition` keep `iter_mut`: they iterate a `&mut Vec` that is used again afterwards, so moving it into the loop does not compile and a reborrow would only add noise. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The loops iterated over `&mut hashes_buffer` where the buffer is already `&mut [u64]`, which only compiles when the surrounding `cfg(not(feature = "force_hash_collisions"))` code is skipped. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Dandandan
approved these changes
Aug 21, 2026
Dandandan
enabled auto-merge
August 21, 2026 08:35
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Which issue does this PR close?
Rationale for this change
Turn on all clippy::pedantic lints, and do opt-out instead of opt-in.
Then enable these lints (remove their opt-outs):
What changes are included in this PR?
One commit per lint, each removing its "allow" line from Cargo.toml
and fixing every site. Review one commit at a time!
Let me know if you disagree with any and I'll revert it
Are these changes tested?
cargo clippy --workspace --all-targets --all-features reports no
warnings, and the extended test suite passes. The changes are mechanical
and behavior-preserving, so no new tests.
Are there any user-facing changes?
No.