Skip to content

feat(compile): Stabilize build.warnings#16796

Open
epage wants to merge 1 commit intorust-lang:masterfrom
epage:warning
Open

feat(compile): Stabilize build.warnings#16796
epage wants to merge 1 commit intorust-lang:masterfrom
epage:warning

Conversation

@epage
Copy link
Copy Markdown
Contributor

@epage epage commented Mar 26, 2026

View all comments

What does this PR try to resolve?

This allows users to either

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.

@epage epage added the T-cargo Team: Cargo label Mar 26, 2026
@rustbot rustbot added A-configuration Area: cargo config files and env vars A-documenting-cargo-itself Area: Cargo's documentation labels Mar 26, 2026
@rustbot
Copy link
Copy Markdown
Collaborator

rustbot commented Mar 26, 2026

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

@rustbot 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
@epage
Copy link
Copy Markdown
Contributor Author

epage commented Mar 26, 2026

@rfcbot fcp merge cargo

@rust-rfcbot
Copy link
Copy Markdown
Collaborator

rust-rfcbot commented Mar 26, 2026

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.

@rust-rfcbot 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
Copy link
Copy Markdown
Contributor Author

epage commented Mar 26, 2026

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.

Copy link
Copy Markdown
Contributor

@arlosi arlosi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Copy Markdown
Contributor Author

epage commented Apr 1, 2026

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.

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

This comment has been minimized.

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
@rustbot

This comment has been minimized.

@epage
Copy link
Copy Markdown
Contributor Author

epage commented Apr 2, 2026

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

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

kazini commented Apr 3, 2026

I really hope this goes through.

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

This comment has been minimized.

@rustbot
Copy link
Copy Markdown
Collaborator

rustbot commented Apr 7, 2026

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.

@orlp
Copy link
Copy Markdown
Contributor

orlp commented Apr 10, 2026

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

@jyn514
Copy link
Copy Markdown
Member

jyn514 commented Apr 10, 2026

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.

Copy link
Copy Markdown
Member

@0xPoe 0xPoe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

* `"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,
Copy link
Copy Markdown
Member

@0xPoe 0xPoe Apr 14, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

"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),
Copy link
Copy Markdown
Member

@0xPoe 0xPoe Apr 14, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the policy for selecting the version here?

@rust-rfcbot 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
@rust-rfcbot
Copy link
Copy Markdown
Collaborator

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

env:
CARGO_BUILD_WARNINGS: deny
steps:
- uses: actions/checkout@v4
Copy link
Copy Markdown
Member

@weihanglo weihanglo Apr 14, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While we've talked about this (we are not sure whether our CI example is responsible for updating to newer versions), I think we can still use the latest version here.

Suggested change
- uses: actions/checkout@v4
- uses: actions/checkout@v6

View changes since the review

* Default: `"warn"`
* Environment: `CARGO_BUILD_WARNINGS`

Adjust the effective level for local lint warnings.
Copy link
Copy Markdown
Member

@weihanglo weihanglo Apr 14, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A bit clearer?

Suggested change
Adjust the effective level for local lint warnings.
Adjust the effective level for lint warnings from local packages.

View changes since the review

* `"warn"`: continue to emit the lints as warnings (default).
* `"allow"`: hide the lints.
* `"deny"`: emit an error for a crate that has lint warnings.
Use `--keep-going` to see the lint warnings for all crates.
Copy link
Copy Markdown
Member

@weihanglo weihanglo Apr 14, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"for all crates" is a bit confusing. This is not going to show warning for dependencies, right?

View changes since the review

@weihanglo
Copy link
Copy Markdown
Member

weihanglo commented Apr 14, 2026

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-configuration Area: cargo config files and env vars A-documenting-cargo-itself Area: Cargo's documentation A-unstable Area: nightly unstable support disposition-merge FCP with intent to merge final-comment-period FCP — a period for last comments before action is taken S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-cargo Team: Cargo

Projects

Status: FCP merge

Development

Successfully merging this pull request may close these issues.

Tracking Issue for warnings (config build.warnings)