Tracking Issue for properly specifying how lint levels are determined

This is a tracking issue for working towards properly specifying how lint levels are determined. This tracking issue is intended to serve as a connecting hub between related issues / discussions and efforts towards properly specifying the lint level mechanism. This tracking issue intentionally combines the "language side" (the concept of lint levels and lints, and in-source lint level attributes) and the "implementation side" (compiler flags), because both are underspecified and under-tested.

Notable lint level "components"

Notable interactions

• Between warnings and lint groups, and constituent lints.
• Lint level flags and annotations, versus --cap-lints and --force-warn
• Between --cap-lints and --force-warn
• Lint level flags versus in-source lint level attributes
• #[forbid(..)] and #[deny(..)], and macros
• Precedence: ordering of the lint level affecting compiler flags, and their interactions with lint level attributes: e.g. -A warnings -D lint is not necessarily the same as -D lint -A warnings (?)
• Non-interactions: non-lint warnings and errors

Existing public-facing documentation

• Lint levels | rustc book
• Lint check attributes | Reference

Possible bugs, unclear/unintuitive behavior and unresolved questions

This section is incomplete.

• https://github.com/rust-lang/rust/issues/75273
• https://github.com/rust-lang/rust/issues/77713
• https://github.com/rust-lang/rust/issues/105104

Related discussions

This section is incomplete.

• https://github.com/rust-lang/rust/pull/113307#issuecomment-1726329956
• https://github.com/rust-lang/rust/issues/77713#issuecomment-707326546

Significant lint level related decisions and changes

This section is incomplete.

• Allow #[deny] inside #[forbid] as a no-op
• Let's #[expect] some lints: Stabilize lint_reasons (RFC 2383)
  • Tracking issue for RFC 2383, "Lint Reasons RFC"
  • Decision: semantics of the #[expect] attribute

Steps towards properly specifying lint level mechanism

This section is a work-in-progress.

• Collect backlinks to changes and discussions related to lint levels.
• Collect backlinks to possible bugs and unclear/unintuitive language and compiler behavior.
• Figure out gaps in existing public-facing lint level documentation.
• Implement supporting changes to test infra to inhibit test suite preset lint level flags (e.g. add a directive that inhibit UI test suite preset lint level flags like -A unused).
• Survey existing lint level mechanism test coverage, and reorganize them into a specific-purpose test subdirectory.
• Draft up some kind of RFC-like document which aims to reaffirm (or at least properly reflect) the status quo backed by coverage from the test suite. That is, how it currently works.

Start with the rustc book's Lint levels page and the Reference's lint check attributes section, then review the linked issues, discussions, and decisions. Survey existing lint-level test coverage and the proposed UI-test infrastructure changes. Done means the behavior is backed by tests and the public-facing lint-level mechanism is properly specified.