Add information about group a lint belongs to

[karolzwolak]

Description

Fixes: #65464

Changes Made

• Extended the default lint settings message to include the lint group they belong to
• Modified the proposed fix message wording from "part of" to "implied by" for better accuracy
  • Old message: `#[warn(unused_variables)]` (part of `#[warn(unused)]`) on by default
  • New message: `#[warn(unused_variables)]` (implied by `#[warn(unused)]`) on by default

Rationale

1. The new wording ("implied by") better reflects the actual relationship between lint groups and their members
2. It maintains consistency with messages shown when manually setting lint levels
3. The change helps users understand the hierarchy of lint settings

Implementation Notes

• Only affects messages for default lint levels (not shown when levels are overridden)
• External lints remain unchanged (potential discussion point for future changes)

Examples

Case 1: Unchanged behavior when lint level is overridden

#[deny(unused)]
fn main() {
    let x = 5;
}

Result:

note: the lint level is defined here
 --> src/main.rs:1:8
  |
1 | #[deny(unused)]
  |        ^^^^^^
  = note: `#[deny(unused_variables)]` implied by `#[deny(unused)]`

Case 2: Changed behavior for default lint levels

fn main() {
    let x = 5;
}

New output:

= note: `#[warn(unused_variables)]` (part of `#[warn(unused)]`) on by default

Previous output:

= note: `#[warn(unused_variables)]` on by default

Discussion Points

• Should we extend this change to external lints as well?
• Is "part of" the most accurate terminology?
• Doesn't this additional info bloat the message? Perhaps a clippy lint suggesting overriding a whole group instead of a few lints manually would be better

[rustbot]

r? @davidtwco

rustbot has assigned @davidtwco.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

[karolzwolak]

I'm not satisfied with tests for this change, I tried to add clippy ui test, but I wasn't able to do so, because they use -D warnings option, which triggers different messages. I'd grateful for ideas how to get around this. Similarly, unused group cannot be tested, because of -A unused option is used in ui tests.

[karolzwolak]

I gathered my thoughts about possible approaches

Possible Approaches

Option 1: Status Quo (No Change)

Current behavior:

= note: `#[warn(unused_variables)]` on by default

Pros:

• Clean and concise
• No added complexity

Cons:

• Doesn’t inform users about group relationships
• Makes bulk configuration harder to discover
• Encourages piecemeal overrides

---

Option 2: Group Annotation (Current PR)

Example:

= note: `#[warn(unused_variables)]` (part of `#[warn(unused)]`) on by default

Alternatives:

• “from group #[warn(unused)]”
• “member of #[warn(unused)] group”

Pros:

• Adds valuable context with minimal noise
• Raises awareness of groupings

Cons:

• Terminology might be unclear
• Doesn’t offer direct action or suggestions

---

Option 3: Group Override Lint

Behavior:
Suggests a group-level override when multiple members of the same group are explicitly overridden:

#[allow(unused_variables)]
#[allow(unused_imports)]

Could trigger a suggestion like:

#[allow(unused)]

Pros:

• Encourages cleaner, more scalable configs
• Helps users write more maintainable code

Cons:

• Could result in over-grouping if users suppress more than they intended
• Might introduce “suggestion clutter” unless carefully scoped
• Needs opt-in/out mechanism to avoid surprising behavior

---

Option 4: Link to Documentation

Example:

= note: `#[warn(unused_variables)]` on by default
         see https://doc.rust-lang.org/rustc/lints/... for details

Pros:

• Keeps messages tidy while enabling deeper exploration
• Reuses existing documentation infrastructure

Cons:

• Less actionable than inline info
• Requires regular doc maintenance to stay accurate

---

Questions for Discussion

1. Terminology:

   • Which phrasing feels clearest:
     “implied by”, “from group”, “part of”, “member of”?

2. Configuration Defaults:

   • For the group annotation message, should it trigger for external lints?

   • For the override lint, what should be the default behavior?

     • Allow-by-default (opt-in)
     • Warn-by-default (opt-out)

[karolzwolak]

cc @hkBst
I'd like to hear your thoughts.

[Centri3]

I'm not satisfied with tests for this change, I tried to add clippy ui test, but I wasn't able to do so, because they use -D warnings option, which triggers different messages. I'd grateful for ideas how to get around this. Similarly, unused group cannot be tested, because of -A unused option is used in ui tests.

We already have a few tests that are full workspaces/crates (thus have access to RUSTFLAGS). I see no reason against that unless compiletest overwrites the lint levels we set there.

A better option, if possible, is to have RUSTFLAGS passed by compiletest. There is //@compile-flags which might work, I'm not sure.

[Centri3]

Option 2: Group Annotation (Current PR)

So, about the topic at hand. This current PR feels like it adds a ton of noise for not much benefit tbh, raising awareness for lint groups is -fine- but they aren't really all that commonly needed. Extra noise and confusion just so the user knows about unused is a bit overkill imo.

I was going to suggest the alternative of only doing this when the user specifies deny(unused) or something but it turns out rustc already does this (I knew I recognized this from somewhere). Really, that's the only place I could see there having been potential confusion.

All that said, clippy adding links to documentation everywhere is quite a bit of noise too.

Option 3: Group Override Lint

This will have huge issues in Clippy, whose categories are just for lint levels and aren't really related lints at all. So we do definitely need that opt-out behavior.

This should probably be special cased to unused only—that said, future-incompatible and nonstandard-style seem reasonable enough too

Option 4: Link to Documentation

This is already done for clippy lints and is pretty standard. These are auto-generated and the same can probably be done in rustc as well. Seems reasonable to me considering prior art. It would be nice if there was something like rustc's error codes index to make this a bit more concise, that is perhaps something to look into if you go down this route.

[Centri3]

Option 3: Group Override Lint

sup dawg, I heard you like your linters, so I added a linter for your linter so you can lint your lints while you lint

[hkBst]

Suggested change

	// in such tests, and the we're testing a scenario with no modification to the default settings.
	// in such tests, and we want to test a scenario with no modification of the default settings.

Do we want that, or are the default settings the only option here? To be honest, I wonder if this test is necessary at all, given the coverage provided by all the existing tests.

[karolzwolak]

Hmm you may be right, the test in current state doesn't actually test anything better than rest of the tests that capture lint output.

[hkBst]

Hi @karolzwolak,

I really like your work, and the current PR seems like the most natural option of the proposed alternatives. I think this is a very good way of teaching users about the existence of various lint groups and adds a lot of value to the compiler messages.

Let's consider the following program, which contains all three case of individual lint specified, lint group specified, default lint:

pub fn unused_var() {
    #[warn(unused_variables)]
    let x = 5;
}

pub fn unused() {
    #[warn(unused)]
    let x = 5;
}

pub fn default_() {
    let x = 5;
}

My proposed change from current (stable) output would be:

warning: unused variable: `x`
 --> src/lib.rs:3:9
  |
3 |     let x = 5;
  |         ^ help: if this is intentional, prefix it with an underscore: `_x`
  |
note: the lint level is defined here
 --> src/lib.rs:2:12
  |
2 |     #[warn(unused_variables)]
  |            ^^^^^^^^^^^^^^^^
+  = note: lint `unused_variables` is part of lint group `unused`

warning: unused variable: `x`
 --> src/lib.rs:8:9
  |
8 |     let x = 5;
  |         ^ help: if this is intentional, prefix it with an underscore: `_x`
  |
note: the lint level is defined here
 --> src/lib.rs:7:12
  |
7 |     #[warn(unused)]
  |            ^^^^^^
-  = note: `#[warn(unused_variables)]` implied by `#[warn(unused)]`
+  = note: `#[warn(unused)]` implies `#[warn(unused_variables)]`

warning: unused variable: `x`
  --> src/lib.rs:12:9
   |
12 |     let x = 5;
   |         ^ help: if this is intentional, prefix it with an underscore: `_x`
   |
-   = note: `#[warn(unused_variables)]` on by default
+   = note: default `#[warn(unused)]` implies `#[warn(unused_variables)]`

This last case with "default", assumes that defaults are lint groups instead of individual lints. I'm not sure that is (always) the case. If this is wrong, then perhaps instead just add this line (like for the first function):

+  = note: lint `unused_variables` is part of lint group `unused`

[karolzwolak]

This last case with "default", assumes that defaults are lint groups instead of individual lints. I'm not sure that is (always) the case. If this is wrong, then perhaps instead just add this line (like for the first function):

+  = note: lint `unused_variables` is part of lint group `unused`

In my understanding, individual lints are set on default, and the groups are a way to refer to bunch of lints at the same time, but I could be wrong. However I really like the your suggestions for the messages, and perhaps this slight inaccuracy (if I'm right) is okay here, because it makes the messages consistent.

[karolzwolak]

My proposed change from current (stable) output would be:

warning: unused variable: `x`
 --> src/lib.rs:3:9
  |
3 |     let x = 5;
  |         ^ help: if this is intentional, prefix it with an underscore: `_x`
  |
note: the lint level is defined here
 --> src/lib.rs:2:12
  |
2 |     #[warn(unused_variables)]
  |            ^^^^^^^^^^^^^^^^
+  = note: lint `unused_variables` is part of lint group `unused`

warning: unused variable: `x`
 --> src/lib.rs:8:9
  |
8 |     let x = 5;
  |         ^ help: if this is intentional, prefix it with an underscore: `_x`
  |
note: the lint level is defined here
 --> src/lib.rs:7:12
  |
7 |     #[warn(unused)]
  |            ^^^^^^
-  = note: `#[warn(unused_variables)]` implied by `#[warn(unused)]`
+  = note: `#[warn(unused)]` implies `#[warn(unused_variables)]`

warning: unused variable: `x`
  --> src/lib.rs:12:9
   |
12 |     let x = 5;
   |         ^ help: if this is intentional, prefix it with an underscore: `_x`
   |
-   = note: `#[warn(unused_variables)]` on by default
+   = note: default `#[warn(unused)]` implies `#[warn(unused_variables)]`

I think these messages look great, and might be the way to go, since as @Centri3 pointed out, lint wouldn't work too well in this example. @Centri3 thanks for providing feedback, what do you thing about these messages?

EDIT:
What about external lints?
This change would make messages for rustc lints consistent, but that would make them inconsistent with external lints like clippy, unless we'd also change the messages for them. It think I'd be great, but

This will have huge issues in Clippy, whose categories are just for lint levels and aren't really related lints at all.