`allow(clippy::expl_impl_clone_on_copy)` stopped working

[dtolnay]

Summary

#![deny(clippy::pedantic)]

pub struct Thing;

impl Copy for Thing {}

#[allow(clippy::expl_impl_clone_on_copy)]
impl Clone for Thing {
    fn clone(&self) -> Self {
        *self
    }
}

$ cargo +nightly-2025-10-07 clippy
(no lint)

$ cargo +nightly-2025-10-08 clippy
error: you are implementing `Clone` explicitly on a `Copy` type
  --> src/lib.rs:8:1
   |
 8 | / impl Clone for Thing {
 9 | |     fn clone(&self) -> Self {
10 | |         *self
11 | |     }
12 | | }
   | |_^
   |
help: consider deriving `Clone` or removing `Copy`
  --> src/lib.rs:8:1
   |
 8 | / impl Clone for Thing {
 9 | |     fn clone(&self) -> Self {
10 | |         *self
11 | |     }
12 | | }
   | |_^
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#expl_impl_clone_on_copy
note: the lint level is defined here
  --> src/lib.rs:1:9
   |
 1 | #![deny(clippy::pedantic)]
   |         ^^^^^^^^^^^^^^^^
   = note: `#[deny(clippy::expl_impl_clone_on_copy)]` implied by `#[deny(clippy::pedantic)]`

error: could not compile `other` (lib) due to 1 previous error

Reproducer

No response

Version

rustc 1.92.0-nightly (f6aa851db 2025-10-07)
binary: rustc
commit-hash: f6aa851dba4b4509ab7e4f3a407b0b1e72a89e4c
commit-date: 2025-10-07
host: aarch64-apple-darwin
release: 1.92.0-nightly
LLVM version: 21.1.2

Additional Labels

No response

[dtolnay]

Bisects to rust-lang/rust#147405. Based on history of clippy_lints/src/derive/expl_impl_clone_on_copy.rs I tried reverting #15709, which fixed the behavior. @samueltardieu @blyxyas

[samueltardieu]

Does it work if you put the #[allow(…)] on the struct itself (it should, and that's the point of this change)?

[blyxyas]

it should, and that's the point of this change

If users find this confusing, I guess we could always just check if the lint is allowed manually in the impl's HirId

[Jarcho]

Why was this lint moved in the first place? The other two make sense since they lint on a derived impl or multiple impls, but this one lints on an impl that was actually written out. Using lint attributes there is the thing that makes the most sense.

[samueltardieu]

Why was this lint moved in the first place? The other two make sense since they lint on a derived impl or multiple impls, but this one lints on an impl that was actually written out. Using lint attributes there is the thing that makes the most sense.

Agreed. I'll move it back, and check if the lint is allowed on the struct definition as well.