Description
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 warningsthird_party_deny.rs
: no warningsthird_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 warningsthird_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 warningsthird_party_deny.rs
: ✔ no warningsthird_party_unsafe.rs
: ❌ nounsafe_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?