Support `build.warnings`

[kpreid]

Cargo has stabilized the build.warnings configuration option. When used as build.warnings = "deny", this causes build, check, etc. to exit with an error status if any warnings are emitted, without changing those warnings to errors individually, and without changing the value of RUSTFLAGS.

For consistency with cargo check, cargo clippy should support the same behavior. That is,

cargo --config='build.warnings="deny"' clippy

should exit with a nonzero exit code if there are any warnings. Currently (clippy 0.1.97 (ad3a598ca4 2026-05-03)), it exits successfully.

---

@rustbot label +A-ui +C-enhancement +T-cargo

[Gri-ffin]

wouldn't this work out of the box? I tried using cargo clippy --config='build.warnings="deny"' on nightly rustc 1.97.0-nightly (f53b654a8 2026-04-30) and got this output:

warning: unused variable: `x`
 --> src/main.rs:2:9
  |
2 |     let x = 3;
  |         ^ help: if this is intentional, prefix it with an underscore: `_x`
  |
  = note: `#[warn(unused_variables)]` (part of `#[warn(unused)]`) on by default

error: `foo` (bin "foo") generated 1 warning (run `cargo clippy --fix --bin "foo" -p foo -- ` to apply 1 suggestion)
error: warnings are denied by `build.warnings` configuration

I don't think cargo --config='build.warnings="deny"' clippy would exit with a nonzero code since the outer cargo would just consume that arg, so clippy would have no idea about it.

[kpreid]

I don't think cargo --config='build.warnings="deny"' clippy would exit with a nonzero code since the outer cargo would just consume that arg, so clippy would have no idea about it.

It is news to me that there would be such a difference, or anything describable as an “inner cargo”. The presence of a --config option to clippy is not documented in cargo clippy --help or https://doc.rust-lang.org/stable/clippy/usage.html.

From an outside perspective, the current behavior is surprising, in a way that is completely silent.

[Gri-ffin]

It is news to me that there would be such a difference, or anything describable as an “inner cargo”. The presence of a --config option to clippy is not documented in cargo clippy --help or https://doc.rust-lang.org/stable/clippy/usage.html.

technically, clippy doesn't actually handle --config by itself, when you run cargo it will consume the global args before the subcommand, when it finds clippy it will then invoke the cargo-clippy binary, which then will itself invoke either cargo check or cargo fix, so when you put it after clippy, it works purely because clippy blindly passes it to the cargo check that it spawns.

I'm not sure if the --config should be documented as a clippy argument, but i can definitely understand why it's surprising since it looks and feels like a built in subcommand.