Tracking Issue for properly specifying how lint levels are determined

[jieyouxu]

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"

Language side	Compiler side
Lint levels	Lint level flags -F/D/W/A
Lint level attributes (e.g. #[forbid(..)])	--cap-lints
Lint expectations (#[expect(..)])	--force-warn
Lint groups
The warnings special lint group
Lexical scoping of lint level attributes

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.

• --cap-lints does not downgrade lint levels for subsequent lint control flags #75273
• New "warning incompatible with previous forbid in same scope" error #77713
• enabling a only a single lint is not intuitive #105104

Related discussions

This section is incomplete.

• Support overriding warnings level for a specific lint via command line #113307 (comment)
• New "warning incompatible with previous forbid in same scope" error #77713 (comment)

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.