Skip to content

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

Open
@anforowicz

Description

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-CLIArea: Command-line interface (CLI) to the compilerA-lint-levelsArea: lint levelsC-bugCategory: This is a bug.needs-triageThis issue may need triage. Remove it if it has been sufficiently triaged.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions