Evan Schwartz

Your Clippy Config Should Be Stricter

“If it compiles, it works.” This feeling is one of the main things Rust engineers love most about Rust, and a reason why using it with coding agents is especially nice. After debugging some code that compiled but mysteriously stopped in production, I realized that it’s useful to enable more Clippy lints to catch bugs that the compiler won't prevent by itself. It's especially useful as guardrails for coding agents, but stricter linting can make your code safer, whether or not you’re coding with LLMs.

Motivating Bug: UTF-8-Oblivious String Slicing

Scour is the personalized content feed that I work on. Every Friday, Scour sends an email digest to each user with the top posts that matched their interests. On a recent Friday, the email sending job mysteriously stopped. This was puzzling because I had already put in place multiple type system-level safeguards and tests to ensure that it would continue with a log on all types of errors.

After digging into the logs, I found the culprit to be thread 'tokio-runtime-worker' panicked... byte index 200 is not a char boundary. A function naively truncated article summaries without checking for UTF-8 character boundaries, which caused a panic and stopped the Tokio worker thread running the email sending loop.

The solution for this particular bug was a safer method for truncating article summaries that respects UTF-8 character boundaries. However, this problem was reminiscent enough of the 2025 Cloudflare unwrap bug that "broke the internet" that I wanted some more general solution.

Rust's compiler prevents many types of bugs but there are still production problems it can't catch. Panics will either crash your program or quietly kill Tokio worker threads. Deadlocks and dropped futures can make work silently stop. And plenty of numeric operations can silently cause incorrect behavior.

We can stave off many of these types of bugs by making Clippy even stricter than it already is.

This is especially relevant in the age of coding agents. A seasoned Rust engineer might naturally avoid patterns that could cause problems. An agent or a junior colleague might not. Stricter Clippy rules make it easier to rely on code you didn't personally write. Also, enabling new lints on an existing codebase is tedious, and exactly the kind of task that is good to hand to a coding agent.

Enabling More Clippy Lints

Clippy ships with hundreds of lints that are disabled by default. Some are disabled because they might have false positives and some are style choices which you might reasonably not want.

Which lints should we enable to help us get back the "if it compiles [and passes Clippy], it works" feeling?

Why Not Enable Lint Categories?

Clippy's lints are grouped into categories: Correctness, Suspicious, Complexity, Perf, Style, Pedantic, Restriction, Cargo, Nursery, and Deprecated.

Unfortunately, none of these categories cleanly map onto "don't let this panic or do the wrong thing in production".

In fact, the Clippy docs say that "The restriction category should, emphatically, not be enabled as a whole." Clippy even includes a dedicated lint, blanket_clippy_restriction_lints, to discourage you from enabling this category. While the restriction category includes many useful lints, it also includes some that directly contradict one another. For example, it contains lints to enforce both big_endian_bytes and little_endian_bytes.

The docs say "Lints should be considered on a case-by-case basis before enabling". Of course, you can enable whole categories like pedantic and restriction and then allow specific ones you want to disable, but I'm outlining a selective opt-in here.

Lints That Don't Fire Are Still Useful

Even if you don't use a certain pattern in your code base today, it's not bad to enable the lint anyway. Inapplicable lints serve as cheap tripwires in case the given pattern is ever added later, whether by you, a colleague, or a coding agent.

My Lints

Every project is different and you should look through the available lints to see which ones make sense for your project.

Also, check when lints landed in stable if your Minimum Supported Rust Version predates 1.95, as some of these may have been added after your MSRV.

With those caveats out of the way, here are the lints I enabled, roughly categorized by what kind of behavior they prevent. You can skip to the bottom if you just want to copy my config.

Don't Panic

This group prevents panics from unwraps and unsafe slicing or indexing into arrays and strings.

Note that some of these, like string_slice and indexing_slicing may produce many warnings throughout your code base. That may be annoying to fix. However, using safe methods like .get() and iterators instead of slicing prevents pretty severe footguns, so I would argue that it's worth it.

You might or might not want to enable expect_used. Calling .expect on an Option or Result can result in a panic. However, the message you pass to expect should already document why that thing shouldn't happen. Enabling the lint and then selectively disabling it throughout your code with #[expect(expect_used, reason = "...")] may end up duplicating the same rationale for using it in the first place.

Another lint that is a real judgement call is arithmetic_side_effects. This can prevent overflows and division by zero. However, it will cause Clippy to warn you about every place you use math operators: +, -, *, <<, /, and %. I tried enabling it in my code base and would estimate that around 15% of the warnings caught real issues and 85% was just noise.

Don't Fail Silently

Don't Do Bad Async Stuff

These prevent various concurrency bugs and deadlocks:

Don't Do Unsafe Things with Memory

Don't Do Potentially Incorrect Things with Numbers

The lints cast_possible_wrap, cast_precision_loss, cast_possible_truncation effectively force you to document invariants when doing lossy casts between numeric types. You might or might not find that useful.

Don't Do Bad Things That are Easy to Avoid

Don't allow Your Way Around These Lints

These two are especially useful if you're using a coding agent. Instead of letting the agent write #[allow(lint_we_wanted_to_enable)], it should provide a reason wherever it's disabling a lint.

Workaround for Workspace Inheritance

If you're using a Cargo workspace, you'll want to enable these lints in the workspace Cargo.toml. Unfortunately, each workspace crate needs to opt in to inheriting lints with lints.workspace = true, rather than inheriting the lints by default. On nightly, there's a missing_lints_inheritance lint that specifically checks for this.

If you're using stable Rust, you can use cargo-workspace-lints or a simple shell script run on CI to make sure you don't forget to make a workspace crate inherit the lints.

Warn or Deny?

When enabling lints, you can either set Clippy to warn or deny them. Either works but I personally prefer setting these to warn and running Clippy with -D warnings before committing and on CI. This makes local iteration marginally easier because you can compile your code initially without fixing all the lints right away.

My Configs

# Workspace Cargo.toml

[workspace.lints.clippy]
# Don't Panic - prevent panics from unwraps and unsafe slicing or indexing
string_slice = "warn"
indexing_slicing = "warn"
unwrap_used = "warn"
panic = "warn"
todo = "warn"
unimplemented = "warn"
unreachable = "warn"
get_unwrap = "warn"
unwrap_in_result = "warn"
unchecked_time_subtraction = "warn"
panic_in_result_fn = "warn"
# Optional - see post for caveats
# expect_used = "warn"
# arithmetic_side_effects = "warn"

# Don't Fail Silently - prevent dropped futures and swallowed errors
let_underscore_future = "warn"
let_underscore_must_use = "warn"
unused_result_ok = "warn"
map_err_ignore = "warn"
assertions_on_result_states = "warn"

# Don't Do Bad Async Stuff - prevent deadlocks and concurrency bugs
await_holding_lock = "warn"
await_holding_refcell_ref = "warn"
if_let_mutex = "warn"  # only relevant on editions before 2024
large_futures = "warn"

# Don't Do Unsafe Things with Memory
mem_forget = "warn"
undocumented_unsafe_blocks = "warn"
multiple_unsafe_ops_per_block = "warn"
unnecessary_safety_doc = "warn"
unnecessary_safety_comment = "warn"

# Don't Do Potentially Incorrect Things with Numbers
float_cmp = "warn"
float_cmp_const = "warn"
lossy_float_literal = "warn"
cast_sign_loss = "warn"
invalid_upcast_comparisons = "warn"
# Optional - these effectively force you to document numeric invariants
# cast_possible_wrap = "warn"
# cast_precision_loss = "warn"
# cast_possible_truncation = "warn"

# Don't Do Bad Things That are Easy to Avoid
rc_mutex = "warn"
debug_assert_with_mut_call = "warn"
iter_not_returning_iterator = "warn"
expl_impl_clone_on_copy = "warn"
infallible_try_from = "warn"
dbg_macro = "warn"

# Don't `allow` Your Way Around These Lints - every suppression must be
# a deliberate #[expect(..., reason = "…")] rather than a silent #[allow]
allow_attributes = "warn"
allow_attributes_without_reason = "warn"

# Workspace clippy.toml

allow-indexing-slicing-in-tests = true
allow-panic-in-tests = true
allow-unwrap-in-tests = true
allow-expect-in-tests = true
allow-dbg-in-tests = true

Conclusion

Ultimately, as Clippy's docs say, "You can choose how much Clippy is supposed to annoy help you." But especially in the age of coding agents, I think it's worth tightening the guardrails so you end up with even fewer mysterious bugs in production and more code where you can say "if it compiles and lints, it should work."

#rust #scour