No way to suppress all third-party crate warnings **except** a few selected warnings

Requirements

Let me try to describe my issue in terms of two requirements and three example .rs files.

Requirement 1: don’t suppress -Funsafe_code injected by build system

I use a custom, non-cargo-based build system to build Rust code. In this build system, we want to maintain a centralized, per-crate metadata that says if a crate uses unsafe code. If this metadata says allow_unsafe = false, then the build system will pass -Funsafe_code when building a given crate.

This -Funsafe_code should not be suppressed by whatever mechanism is used to meet requirement #2.

For example, the following crate should fail to build, because it uses unsafe code (assuming that it doesn’t say allow_unsafe = true to the build system to stop the build system from injecting -Funsafe_code command-line flag into rustc invocation):

// third_party_unsafe.rs:
pub fn foo() -> &'static str {
    unsafe { str::from_utf8_unchecked(b"foo") }
}

Requirement 2: Warnings in third-party crates should be suppressed

The following third-party crate should not emit any build warnings, despite violating non_snake_case warning:

// third_party_default_warning.rs:
pub fn UNexpectEDcase() {}

And warnings should stay suppressed even if a crate uses #![deny…]:

// third_party_deny.rs:
#![deny(warnings)]
pub fn UNexpectEDcase() {}

Requirements taken together

Combining the two requirements above means that I expect that a single combination of rustc command-line flags should exist for getting the following results:

• third_party_default_warning.rs: no warnings
• third_party_deny.rs: no warnings
• third_party_unsafe.rs: unsafe_code warning reported as an error

Problem

• Requirements are not met when using -Awarnings -Funsafe_code (e.g. rustc --crate-type=lib -Awarnings -Funsafe_code ./third_party_default_warning.rs):
  • third_party_default_warning.rs: ✔ no warnings
  • third_party_deny.rs: ❌ warnings because #![deny…] overrides -Awarnings
  • third_party_unsafe.rs: ✔ unsafe code results in warnings-as-errors
• Requirements are not met when using --cap-lints=allow -Funsafe_code (e.g. rustc --crate-type=lib --cap-lints=allow -Funsafe_code ./third_party_default_warning.rs):
  • third_party_default_warning.rs: ✔ no warnings
  • third_party_deny.rs: ✔ no warnings
  • third_party_unsafe.rs: ❌ no unsafe_code warnings because --cap-lints=allow overrides -Funsafe_code

Affected Rust version

I've tested the above with:

$ rustc --version
rustc 1.90.0-nightly (706f244db 2025-06-23)

Other related issues

I see that https://github.com/rust-lang/rust/issues/75273 reports a related issue, but I am not sure if this is the same issue.

I also see that https://github.com/rust-lang/rust/issues/142610 tracks specifying lint levels in general.

This issue is a follow-up to https://crbug.com/428207407, where Chromium tries to enforce allow_unsafe via -Funsafe_code. Interestingly --cap-lints=allow also negatively affects Chromium's ability to disallow unstable language features via -Zallow-features=.

Exploring expectations / potential solutions

Would it be reasonable to expect that -F… overrides --cap-lints=allow and not the other way around? Clearly those two command-line flags are in conflict, but -Funsafe_code is more specific than --cap-lints=allow, so maybe using them together should suppress all lints except for unsafe_code, right?

Start by reproducing the three cases with rustc using -Awarnings -Funsafe_code and --cap-lints=allow -Funsafe_code, including the three example .rs files in the issue. Read related issues #75273 and #142610, then define the intended precedence between lint caps and explicit lint levels; done means the behavior and required tests are agreed.