feat(compile): Stabilize build.warnings

[epage]

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]

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]

@rfcbot fcp merge cargo

[rust-rfcbot]

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

• @0xPoe
• @Eh2406
• @Muscraft
• @arlosi
• @ehuss
• @epage
• @joshtriplett
• @weihanglo

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]

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]

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]

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

[kazini]

I really hope this goes through.

[rustbot]

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]

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

[jyn514]

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.