feat(compile): Stabilize `build.warnings` by epage · Pull Request #16796 · rust-lang/cargo

epage · 2026-03-26T21:46:53Z

What does this PR try to resolve?

This allows users to either

hide warnings (silence warnings in the terminal #14258)
error on warnings (Add --deny-warnings functionality for all commands. #8424)

build.warnings serves a similar purpose as RUSTFLAGS=-Dwarnings / RUSTFLAGS=-Awarnings but without invalidation caches.

build.warnings = "deny" will

only errors for lint warnings and not hard warnings
only errors for local warnings and not non-local warnings visible with --verbose --verbose
stop the build without --keep-going

(this matches RUSTFLAGS=-Dwarnings)

These conditions were not originally met and also came as feedback from rust-lang/rust which has been dogfooding this since the merge of rust-lang/rust#148332.

build.warnings = "allow" will

only hide lint warnings and not hard warnings
- Note: RUSTFLAGS=-Awarnings will suppress rustc hard warnings
hide non-local warnings for --verbose --verbose
hide the warning summary line (number of warnings per crate)

Closes #14802

How to test and review this PR?

My main concern over this was how the naming scheme would extend to rust-lang/rfcs#3730 but that RFC has not gained much interest

build seems as good of a home as any.

rustbot · 2026-03-26T21:46:57Z

r? @weihanglo

rustbot has assigned @weihanglo.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: @ehuss, @epage, @weihanglo
@ehuss, @epage, @weihanglo expanded to ehuss, epage, weihanglo
Random selection from ehuss, weihanglo

epage · 2026-03-26T21:47:06Z

@rfcbot fcp merge cargo

rust-rfcbot · 2026-03-26T21:47:24Z

Team member @epage has proposed to merge this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

epage · 2026-03-26T21:48:54Z

Right now, we exactly mirror RUSTFLAGS=[AD]warnings behavior.

My one concern is with build.warnings = "allow" with hard warnings.

Right now, rustc warnings are hidden and cargo warnings are shown. We likely want these to be consistent
We shouldn't be hiding the Cargo Script warning
Hard warnings should be rare
deny ignores hard warnings

From this, I would lean towards making allow show hard warnings always.

arlosi

I agree with stabilizing the existing behavior, but I think we need to be clear about exactly what this option impacts.

"Hard warnings" don't seem to be defined as term in our documentation.

View changes since this review

epage · 2026-04-01T20:59:37Z

FYI I found a bug where build.warnings = "allow" would hide denied lints causing no message to be shown and an abnormal rustc exit message. I have a local fixed prepared, just waiting on #16821.

This allows users to either - hide warnings (rust-lang#14258) - error on warnings (rust-lang#8424) `build.warnings` is setup to mirror the behavior of `RUSTFLAGS=-Dwarnings`, including - only errors for lint warnings and not hard warnings - only errors for local warnings and not non-local warnings visible with `--verbose --verbose` - stop the build without `--keep-going` These conditions were not originally met and also came as feedback from rust-lang/rust which has been dogfooding this since the merge of rust-lang/rust#148332. Things are a bit different with `RUSTFLAGS=-Awarnings`: - Hard warnings are hidden for rustc but not cargo (rustc seems in the wrong imo) - In particular, we shouldn't mask the edition warning for Cargo Script - both hide the warning summary line (number of warnings per crate) - both hide non-local warnings for `--verbose --verbose` One design constraint we are operating on with this is that changing `build.warnings` should not cause a rebuild, unlike a `RUSTFLAGS` solution. Closes rust-lang#14802

epage · 2026-04-02T20:33:49Z

I've updated the stabilization report to reflect #16827 being merged. I also found and fixed #16824.

kazini · 2026-04-03T18:44:06Z

I really hope this goes through.

orlp · 2026-04-10T09:52:44Z

Regarding the "hard warnings" discussion, I provided a suggestion here to add a deny-all option: #14802 (comment).

jyn514 · 2026-04-10T10:06:14Z

Please do not allow people to override rustc's decision to force-show a warning :/ we only do that for cases where it really matters.

0xPoe

Thanks!

View changes since this review

0xPoe · 2026-04-14T20:17:16Z

+* `"deny"`: emit an error for a crate that has lint warnings.
+  Use `--keep-going` to see the lint warnings for all crates.
+
+Only warnings are affected, which are within the user's control to resolve or adjust the level of are affected,


Your English is definitely better than mine 😆, but I'm not sure if using "are affected" twice makes sense here.

You are right. I tweaked this.

0xPoe · 2026-04-14T20:19:40Z

            "package-workspace" => stabilized_warn(k, "1.89", STABILIZED_PACKAGE_WORKSPACE),
            "build-dir" => stabilized_warn(k, "1.91", STABILIZED_BUILD_DIR),
            "config-include" => stabilized_warn(k, "1.93", STABILIZED_CONFIG_INCLUDE),
+            "warnings" => stabilized_warn(k, "1.97", STABILIZED_WARNINGS),


What is the policy for selecting the version here?

The version of nightly for which this will be stabilized in. 1.96 has been branched to beta, so this will be stabilized in 1.97 atm.

See https://forge.rust-lang.org/

rust-rfcbot · 2026-04-14T20:24:47Z

🔔 This is now entering its final comment period, as per the review above. 🔔

weihanglo · 2026-04-14T21:37:29Z

@rust-rfcbot reviewed

Though

only errors for lint warnings and not hard warnings

only hide lint warnings and not hard warnings

Could we have some definition of hard warnings written down somewhere? I don't think we need to make a formal/stable definition, but at least we should capture what we have today. I guess they are

cargo::warnings from Cargo build scripts
Compiler diagnostics that doesn't have a code field in their JSON diagonstic

The current implementation is somehow subtle and I am lost

rustbot · 2026-04-15T15:02:49Z

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

epage · 2026-04-15T15:03:54Z

@rust-rfcbot reviewed

Though

only errors for lint warnings and not hard warnings
only hide lint warnings and not hard warnings

Could we have some definition of hard warnings written down somewhere? I don't think we need to make a formal/stable definition, but at least we should capture what we have today. I guess they are
* `cargo::warnings` from Cargo build scripts

* Compiler diagnostics that doesn't have a `code` field in their JSON diagonstic
The current implementation is somehow subtle and I am lost

Hard warnings are those that you cannot control the level of, including

build script warnings
some compiler diagnostics
warnings that are currently stable within Cargo

weihanglo · 2026-04-15T15:38:41Z

+## Checking for warnings
+
+Customarily, projects want to be "warnings clean" on official branches while being lax for local development.
+[`build.warnings = "deny"`] can be used to fail a CI job if warnings are present.


Not a blocker: would love to see we discourage RUSTFLAGS=-Dwarnings explicitly. Maybe this could even be a build optimization topic, like you can reuse dependencies between builds if dropping RUSTFLAGS=-Dwarnings in favor or this.

View changes since the review

ehuss · 2026-04-15T23:30:56Z

Should there be a consideration for unknown config strings? I'm considering the suggestion in #14802 (comment) that there be additional options for different behaviors. If cargo just errors on an unknown string, that could make it more difficult to add new options in the future.

epage · 2026-04-15T23:46:39Z

I think there are some unsaid assumptions that I want to check. You are suggesting we warn on unknown values so that for persistent configs, we act like it is warn, rather than erroring, when also using stable-without-new-value Cargo versions. These new values should not have a signicifant enough impact which makes it safe to fall back to warn, not needing our default process of assuming new features are significant and erroring.

Did I get that right?

weihanglo · 2026-04-16T00:18:15Z

Should there be a consideration for unknown config strings? I'm considering the suggestion in #14802 (comment) that there be additional options for different behaviors. If cargo just errors on an unknown string, that could make it more difficult to add new options in the future.

This is a valid concern, though the one of the major use cases here is setting CARGO_BUILD_WARNINGS=deny in CI, and if it is a warn itself when there is a typo, it may be hard to catch.

Behavior of some existing config:

These enum-based will error during deserialize time.

term.progress.when: auto, never, always
future-incompat-report.frequency: always, never
resolver.incompatible-rust-versions: allow, fallback
cargo-new.vcs: git, hg, pijul, fossil, none
resolver.feature-unification: package, selected, workspace (unstable)

The http.ssl-version config also errors out at usage site IIUC, but it is very likely to have tlsv1.4 in the future. This is reasonable because TLS is important enough not to misconfigure.

We added "default" to build.jobs but I forgot whether we have talked about forward compatibility (its FCP here). There might be more if we have some clever idea to control/suppress parallelism.

Besides, [profile] settings in config are warning-based as they go to a different code path.

ehuss · 2026-04-16T14:33:55Z

You are suggesting we warn on unknown values so that for persistent configs, we act like it is warn, rather than erroring

I don't know what the expected behavior should be.

For example, if you have CARGO_BUILD_WARNINGS=deny or CARGO_BUILD_WARNINGS=xyz with Rust 1.83, it is just ignored. Unfortunately starting in 1.84 it is erroring on unknown variants even without -Zwarnings (but still ignoring known variants).

I suppose it depends on how it is expected that people use and specify the setting. If it is mostly CI, or things like rustc bootstrap, then there might be decent ways to work around it if new options are added (and they error on old versions). I'm thinking like how hard would it be to have different settings in a GitHub Actions matrix on different versions?

epage added the T-cargo Team: Cargo label Mar 26, 2026

rustbot assigned weihanglo Mar 26, 2026

rustbot added A-configuration Area: cargo config files and env vars A-documenting-cargo-itself Area: Cargo's documentation labels Mar 26, 2026

rustbot added A-unstable Area: nightly unstable support S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 26, 2026

rust-rfcbot added proposed-final-comment-period An FCP proposal has started, but not yet signed off. disposition-merge FCP with intent to merge labels Mar 26, 2026

epage mentioned this pull request Mar 26, 2026

RFC: Custom lint profiles rust-lang/rfcs#3926

Open

arlosi reviewed Mar 27, 2026

View reviewed changes

Comment thread src/doc/src/reference/config.md Outdated

Comment thread src/doc/src/reference/config.md Outdated

Comment thread src/doc/src/reference/config.md Outdated

ehuss added this to Cargo status tracker Mar 31, 2026

ehuss moved this to FCP merge in Cargo status tracker Mar 31, 2026

epage changed the title ~~feat: Stabilize build.warnings~~ feat(compile): Stabilize build.warnings Apr 2, 2026

This comment has been minimized.

Sign in to view

epage force-pushed the warning branch from da169f3 to 3e5b2b9 Compare April 2, 2026 20:21

This comment has been minimized.

Sign in to view

epage force-pushed the warning branch 4 times, most recently from a4e366a to e98cf0d Compare April 2, 2026 20:56

shian15810 reviewed Apr 5, 2026

View reviewed changes

Comment thread src/doc/src/guide/continuous-integration.md Outdated

shian15810 mentioned this pull request Apr 5, 2026

Why not to set rustflags empty by default? actions-rust-lang/setup-rust-toolchain#48

Closed

epage force-pushed the warning branch 2 times, most recently from 953e363 to f1831ee Compare April 7, 2026 18:32

This comment has been minimized.

Sign in to view

epage force-pushed the warning branch from f1831ee to de56dff Compare April 7, 2026 18:32

This comment has been minimized.

Sign in to view

0xPoe reviewed Apr 14, 2026

View reviewed changes

rust-rfcbot added final-comment-period FCP — a period for last comments before action is taken and removed proposed-final-comment-period An FCP proposal has started, but not yet signed off. labels Apr 14, 2026

weihanglo reviewed Apr 14, 2026

View reviewed changes

Comment thread src/doc/src/guide/continuous-integration.md

Comment thread src/doc/src/reference/config.md Outdated

Comment thread src/doc/src/reference/config.md Outdated

epage force-pushed the warning branch from de56dff to f22322a Compare April 15, 2026 15:02

weihanglo approved these changes Apr 15, 2026

View reviewed changes

Conversation

epage commented Mar 26, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What does this PR try to resolve?

How to test and review this PR?

Uh oh!

rustbot commented Mar 26, 2026

Uh oh!

epage commented Mar 26, 2026

Uh oh!

rust-rfcbot commented Mar 26, 2026 • edited by weihanglo Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

epage commented Mar 26, 2026

Uh oh!

arlosi left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

epage commented Apr 1, 2026

Uh oh!

This comment has been minimized.

This comment has been minimized.

epage commented Apr 2, 2026

Uh oh!

kazini commented Apr 3, 2026

Uh oh!

Uh oh!

This comment has been minimized.

This comment has been minimized.

orlp commented Apr 10, 2026

Uh oh!

jyn514 commented Apr 10, 2026

Uh oh!

0xPoe left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

0xPoe Apr 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

epage Apr 15, 2026

Choose a reason for hiding this comment

Uh oh!

0xPoe Apr 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

epage Apr 15, 2026

Choose a reason for hiding this comment

Uh oh!

rust-rfcbot commented Apr 14, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

weihanglo commented Apr 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Apr 15, 2026

Uh oh!

epage commented Apr 15, 2026

Uh oh!

weihanglo Apr 15, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ehuss commented Apr 15, 2026

Uh oh!

epage commented Apr 15, 2026

Uh oh!

weihanglo commented Apr 16, 2026

Uh oh!

ehuss commented Apr 16, 2026

Uh oh!

Reviewers

epage commented Mar 26, 2026 •

edited by rustbot

Loading

rust-rfcbot commented Mar 26, 2026 •

edited by weihanglo

Loading

arlosi left a comment •

edited by rustbot

Loading

0xPoe left a comment •

edited by rustbot

Loading

0xPoe Apr 14, 2026 •

edited

Loading

0xPoe Apr 14, 2026 •

edited

Loading

weihanglo commented Apr 14, 2026 •

edited

Loading

weihanglo Apr 15, 2026 •

edited by rustbot

Loading