`#[expect(redundant_lifetimes)]` doesn't work when `#[derive(Debug)]` is present

[LuisFerLCC]

Consider the following code:

#![deny(redundant_lifetimes)]

use std::fmt::Debug;

#[derive(Debug)]
pub struct RefWrapper<'a, T>
where
    'a: 'static,
    T: Debug,
{
    pub t_ref: &'a T
}

As expected, the compiler throws an error because the 'a lifetime is redundant:

➜  rust-playground git:(master) ✗ cargo check
    Checking rust-playground v0.1.0 (/Users/luisferlcc/rust-playground)
error: unnecessary lifetime parameter `'a`
 --> src/lib.rs:6:23
  |
6 | pub struct RefWrapper<'a, T>
  |                       ^^
  |
  = note: you can use the `'static` lifetime directly, in place of `'a`
note: the lint level is defined here
 --> src/lib.rs:1:9
  |
1 | #![deny(redundant_lifetimes)]
  |         ^^^^^^^^^^^^^^^^^^^

error: unnecessary lifetime parameter `'a`
 --> src/lib.rs:6:23
  |
6 | pub struct RefWrapper<'a, T>
  |                       ^^
  |
  = note: you can use the `'static` lifetime directly, in place of `'a`

error: could not compile `rust-playground` (lib) due to 2 previous errors

Adding #[allow(redundant_lifetimes)] to the type definition...

#![deny(redundant_lifetimes)]

use std::fmt::Debug;

#[derive(Debug)]
#[allow(redundant_lifetimes)]
pub struct RefWrapper<'a, T>
where
    'a: 'static,
    T: Debug,
{
    pub t_ref: &'a T
}

...predictably eliminates the error:

➜  rust-playground git:(master) ✗ cargo check
    Checking rust-playground v0.1.0 (/Users/luisferlcc/rust-playground)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.02s

However, changing the allow attribute to expect...

#![deny(redundant_lifetimes)]

use std::fmt::Debug;

#[derive(Debug)]
#[expect(redundant_lifetimes)]
pub struct RefWrapper<'a, T>
where
    'a: 'static,
    T: Debug,
{
    pub t_ref: &'a T
}

...inexplicably fails to make the linter stand down:

➜  rust-playground git:(master) ✗ cargo check
    Checking rust-playground v0.1.0 (/Users/luisferlcc/rust-playground)
error: unnecessary lifetime parameter `'a`
 --> src/lib.rs:7:23
  |
7 | pub struct RefWrapper<'a, T>
  |                       ^^
  |
  = note: you can use the `'static` lifetime directly, in place of `'a`
note: the lint level is defined here
 --> src/lib.rs:1:9
  |
1 | #![deny(redundant_lifetimes)]
  |         ^^^^^^^^^^^^^^^^^^^

error: could not compile `rust-playground` (lib) due to 1 previous error

But removing #[derive(Debug)] allows the expect attribute to take effect:

#![deny(redundant_lifetimes)]

use std::fmt::Debug;

#[expect(redundant_lifetimes)]
pub struct RefWrapper<'a, T>
where
    'a: 'static,
    T: Debug,
{
    pub t_ref: &'a T
}

➜  rust-playground git:(master) ✗ cargo check
    Checking rust-playground v0.1.0 (/Users/luisferlcc/rust-playground)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.04s

Meta

This issue occurs on the latest versions of all three channels:

➜  rust-playground git:(master) ✗ rustc --version --verbose
rustc 1.92.0 (ded5c06cf 2025-12-08)
binary: rustc
commit-hash: ded5c06cf21d2b93bffd5d884aa6e96934ee4234
commit-date: 2025-12-08
host: aarch64-apple-darwin
release: 1.92.0
LLVM version: 21.1.3

➜  rust-playground git:(master) ✗ rustc +beta --version --verbose
rustc 1.93.0-beta.5 (72b6488ba 2025-12-21)
binary: rustc
commit-hash: 72b6488ba485fd08cd96f194ffdd83ba8aa0b057
commit-date: 2025-12-21
host: aarch64-apple-darwin
release: 1.93.0-beta.5
LLVM version: 21.1.8

➜  rust-playground git:(master) ✗ rustc +nightly --version --verbose
rustc 1.94.0-nightly (0e8999942 2025-12-30)
binary: rustc
commit-hash: 0e8999942552691afc20495af6227eca8ab0af05
commit-date: 2025-12-30
host: aarch64-apple-darwin
release: 1.94.0-nightly
LLVM version: 21.1.8

Backtrace

➜  rust-playground git:(master) ✗ RUST_BACKTRACE=1 cargo check
    Checking rust-playground v0.1.0 (/Users/luisferlcc/rust-playground)
error: unnecessary lifetime parameter `'a`
 --> src/lib.rs:7:54
  |
7 | pub struct RefWrapper<#[expect(redundant_lifetimes)] 'a, T>
  |                                                      ^^
  |
  = note: you can use the `'static` lifetime directly, in place of `'a`
note: the lint level is defined here
 --> src/lib.rs:1:9
  |
1 | #![deny(redundant_lifetimes)]
  |         ^^^^^^^^^^^^^^^^^^^

error: could not compile `rust-playground` (lib) due to 1 previous error

[Urgau]

The difference between the #[allow] case and #[expect] lies in the keeping of the attribute in the generated derive code.

We see that #[expect] is not kept when expending the derive(Debug) macro.

#[expect(redundant_lifetimes)]
pub struct RefWrapper<'a, T> where 'a: 'static, T: Debug {
    pub t_ref: &'a T,
}
#[automatically_derived]
impl<'a, T: ::core::fmt::Debug> ::core::fmt::Debug for RefWrapper<'a, T> where
    'a: 'static, T: Debug {
    #[inline]
    fn fmt(&self, f: &mut ::core::fmt::Formatter) -> ::core::fmt::Result {
        ::core::fmt::Formatter::debug_struct_field1_finish(f, "RefWrapper",
            "t_ref", &&self.t_ref)
    }
}

[Urgau]

We are missing the expect lint attribute when filtering the attributes to keep:

rust/compiler/rustc_builtin_macros/src/deriving/generic/mod.rs

Lines 534 to 551 in b49c7d7

	// Keep the lint attributes of the previous item to control how the
	// generated implementations are linted
	let mut attrs = newitem.attrs.clone();
	attrs.extend(
	item.attrs
	.iter()
	.filter(|a| {
	a.has_any_name(&[
	sym::allow,
	sym::warn,
	sym::deny,
	sym::forbid,
	sym::stable,
	sym::unstable,
	])
	})
	.cloned(),
	);

[Urgau]

However adding the #[expect] attribute to the generated code could cause some code to start having a warning for unfilled expectations. Example below.

#[expect(non_camel_case_types)]  // currently only applied to the struct, so no unfilled expectation
#[derive(Debug)]
pub struct SCREAMING_CASE {
    pub t_ref: i64,
}

#[expect(non_camel_case_types)]  // applied to the struct and derived code
pub struct SCREAMING_CASE_2 {
    pub t_ref: i64,
}
#[expect(non_camel_case_types)]  // unfilled expectation
#[automatically_derived]
impl ::core::fmt::Debug for SCREAMING_CASE_2 {
    #[inline]
    fn fmt(&self, f: &mut ::core::fmt::Formatter) -> ::core::fmt::Result {
        todo!()
    }
}

One way I could see us fix this mismatch could be to downgrade the #[expect] to #[allow] in the derived code. That would avoid having unfilled expectations while also hiding any warnings (as asked in this issue).

In any-case, this is a language question. cc @rust-lang/lang-ops
@rustbot labels +T-lang -needs-triage

[LuisFerLCC]

One way I could see us fix this mismatch could be to downgrade the #[expect] to #[allow] in the derived code. That would avoid having unfilled expectations while also hiding any warnings (as asked in this issue).

That seems like a great solution, and actually one that would work for all other lints, not just for redundant_lifetimes. Hopefully we can implement it that way.

[joshtriplett]

(@tmandry is planning to write a lang comment here.)

[tmandry]

We discussed this on the lang team and our preferred model (articulated by @joshtriplett) is one where every time you write #[expect] it acts as an allow, and warns if there was not at least one suppression of the lint for that attribute.

Duplicating expect attributes on derives and changing them to allows on derives both deviate from this model, which would be unfortunate.

Question: Is it feasible to change the implementation of the expect check to group suppressed lints based on the span of the expect attribute? That would preserve the model from the user's perspective.

[traviscross]

We talked as well about how this is a good use case for having some syntax to group items. If we had that, then the expect could be applied to that in the desugaring.