/review-rust

Clippy scope: what is already mechanical

Load when unsure whether a finding duplicates a lint. Verified 2026-09-14 against the stable (1.98) lint list — 839 lints total, counted from the rendered index rather than recalled.

Group sizes and default levels

489 lints are on by default (422 warn + 67 deny). correctness being deny rather than warn is the detail people get wrong, and it changes what "clippy is clean" means.

Already warn-by-default — never report these

ptr_arg's own rationale is the argument a reviewer would otherwise make by hand: "Requiring the argument to be of the specific type makes the function less useful for no benefit; slices in the form of &[T] or &str usually suffice."

What survives as judgment in those areas is narrower: ptr_arg says nothing about whether a function should take String, &str, impl Into<String> or Cow<'_, str>; await_holding_lock does not cover tokio::sync::Mutex guards, because holding those across .await is legal.

Lints whose group people misremember

Recommending a nursery lint as though it were pedantic misrepresents its false-positive rate.

Worth recommending, by situation

Each of these converts a recurring manual review comment into a compiler check — which is the most useful thing a review can do, because it removes work from the judgment layer permanently.

Useful rustc lints, all allow-by-default: unreachable_pub ("pub items not reachable from crate root"), missing_debug_implementations, missing_docs, missing_copy_implementations, elided_lifetimes_in_paths, let_underscore_drop, unused_qualifications, variant_size_differences, must_not_suspend.

rust_2018_idioms is a group, not a lint — it expands to bare-trait-objects, unused-extern-crates, ellipsis-inclusive-range-patterns, elided-lifetimes-in-paths, explicit-outlives-requirements. The last is the noisy one. rust_2024_compatibility is the migration group for a pre-2024 crate.

The [lints] table

Respected since Cargo 1.74, in both package and workspace form. The tool is the part before ::; no :: means rust.

[workspace.lints.rust]
unsafe_code = "forbid"

[workspace.lints.clippy]
nursery = { level = "warn", priority = -1 }
pedantic = { level = "warn", priority = -1 }
missing_errors_doc = "allow"
must_use_candidate = "allow"

# member crate
[lints]
workspace = true

priority is required whenever a group is combined with an exemption. It is "a signed integer that controls which lints or lint groups override other lint groups: lower (particularly negative) numbers have lower priority, being overridden by higher numbers." Without the negative priority on the group, the entries are unordered and the exemption silently may not win. This is the single most common mistake in a [lints] table.

Cargo applies these only to the current package, not to dependencies.

A lint can be wrong for a codebase

suboptimal_flops (nursery) suggests a.mul_add(b, c) for multiply-then-add — one rounding instead of two, genuinely more accurate. It is also a different number, and f64::mul_add falls back to a software implementation on targets without an FMA instruction, so results can differ between machines. In a simulation whose premise is reproducibility, taking that advice is actively harmful.

The right outcome is an explicit allow with a comment saying why — not a group left off by accident, which produces the right behaviour for the wrong reason and will silently reverse the moment someone enables nursery.

Generalize the check: when recommending a group, scan what it would actually fire on, and name any lint whose advice conflicts with a stated property of the system (determinism, bit-exactness, a documented output format).

Adjacent tooling — the one-time recommendation set

Versions verified 2026-09-14.

Two honesty caveats to carry into any recommendation:

• cargo-semver-checks documents its own ceiling: "Will cargo-semver-checks catch every semver violation? No, it will not — not yet!" It explicitly misses breaking type changes, generics and lifetime changes, and breakage that only appears under a subset of features. It is low-false-positive by design ("If they do occur, they are considered bugs") but has real false negatives — so a clean run is not proof.
• Miri cannot establish soundness. It detects UB in the executions your tests actually perform. "Miri is green" is evidence about the test suite, not about the unsafe.