rust-lintslisted

# Rust lints ## Purpose Lints are the cheapest enforcement layer in a Rust workspace. A lint rejects a whole class of defect at compile time, for every author, forever. A review comment rejects one instance, once. This matters most for machine-generated code. Model-written Rust fails in repeatable ways: undocumented `unsafe`, `let _ = guard;` that swallows an RAII handle, unchecked integer arithmetic, `mem::forget` on a resource type, bare `#[allow(...)]` that hides a violation, oversized stack frames. Every one of these has a lint. Turn the lint on and the class stops arriving in review. Use this skill as the reference for the canonical lint set, for how to extend it, and for how to recover when the gate goes red. ## When to use - You add a crate to the workspace and must wire lint inheritance. - You edit `[workspace.lints.*]` or `clippy.toml`. - You want to promote a lint from `warn` to `deny`, or add a new lint. - You must decide between fixing a violation and suppressing it. - Clippy, rustfmt or `cargo deny` fails and you must classify the failure. - You audit why a defect class reached production without a lint stopping it. ## Lint policy lives at the workspace root Put every lint level in the workspace root `Cargo.toml`. Every member crate inherits with two lines: ```toml [lints] workspace = true ``` Do not put lint levels in a member crate's `Cargo.toml`. A per-crate override is invisible to anybody who reads the root policy, and it drifts. When one crate gen