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

[anforowicz]

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 #75273 reports a related issue, but I am not sure if this is the same issue.

I also see that #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?

[anforowicz]

I have retested and it turns out that I've been wrong about --cap-lints=allow impacting -Zallow-features= (*). So let's keep this issue focused on interactions between -Awarnings, --cap-lints=allow, and -Funsafe_code (i.e. please ignore the crossed-out part of "Other related issues" section in the original issue report above).

(*)

$ rustc --crate-type=lib --cap-lints=allow -Zallow-features= ./third_party_unstable_feature.rs
error[E0725]: the feature `portable_simd` is not in the list of allowed features
 --> ./third_party_unstable_feature.rs:1:12
  |
1 | #![feature(portable_simd)]
  |            ^^^^^^^^^^^^^

error: aborting due to 1 previous error

[Noratrieb]

I think it makes sense that --cap-lints is stronger than --forbid, since --cap-lints behaves as sort of a "postprocessor" of the lint level machinery, capping the lints at that level. therefore I don't think it would make sense to make --forbid, which is part of this machinery that --cap-lints wants to cap, override it. It would likely lead to other problems.
I don't really know how to best support this use case. I think this is one example where unsafe_code being a lint is just a bit suboptimal.

[anforowicz]

Thanks for the feedback!

I think it makes sense that --cap-lints is stronger than --forbid, since --cap-lints behaves as sort of a "postprocessor" of the lint level machinery, capping the lints at that level.

I think that it is preferable/desirable to be able to understand command line flags without having to understand their implementation details. Knowing that --cap-lints behaves as a "postprocessor" seems like an implementation detail.

And FWIW my reasoning above ("-Funsafe_code is more specific than --cap-lints=allow") has a precedent elsewhere - IIUC more specific #[deny(some-specific-lint)] will win over a less specific #[allow(some-lint-group)].

I don't really know how to best support this use case.

Given my explanation above, I hope that we can support this use case by treating -Funsafe_code as more specific than --cap-lints=allow, and therefore having -Funsafe_code "win".

I think this is one example where unsafe_code being a lint is just a bit suboptimal.

That's fair - I agree that unsafe_code is a little bit special. OTOH, there are other lints that are related to undefined behavior (e.g. never-type-fallback-flowing-into-unsafe or ptr-to-integer-transmute-in-consts). So I think that it may still be desirable to handle this use case within the warnings/lints machinery / without making unsafe_code a special, one-off non-warning.

[hanna-kruppe]

The precedence of --cap-lints isn’t leaking implementation details, the flag is designed to make lints triggered in dependencies irrelevant to downstream projects. To achieve that goal it has to trump every way how lints in dependencies may be enabled. For example, if you set RUSTFLAGS=-Dsome_lint that flag is passed to all rustc invocations by Cargo, including those for dependencies, so it must not override the cap-lints flag that Cargo adds to dependencies.