incorrect_clone_impl_on_copy_type false positive when macro-generated code doesn't know whether the type is Copy

[dtolnay]

Summary

Consider this code using https://github.com/dtolnay/ghost:

#[phantom]
#[derive(Clone)]
pub struct MyPhantom<T: ?Sized>;

This expands to a pub type MyPhantom and impl Clone for MyPhantom.

That impl Clone needs to emit the same code regardless of whether the caller of this macro has handwritten impl<T> Copy for MyPhantom<T> {} somewhere else in this crate. The attribute macro can't possibly know whether they have.

So the macro can't produce fn clone(&self) -> Self { *self } because the type may or may not be Copy.

But if it produces fn clone(&self) -> Self { /* other correct implementation */ } and the type happens to be Copy, then Clippy's incorrect_clone_impl_on_copy_type lint will be sad about this.

Would this situation be worth documenting as a "known issue" for the lint?

Lint Name

incorrect_clone_impl_on_copy_type

Reproducer

No response

Version

rustc 1.72.0-nightly (839e9a6e1 2023-07-02)
binary: rustc
commit-hash: 839e9a6e1210934fd24b15548b811a97c77138fc
commit-date: 2023-07-02
host: x86_64-unknown-linux-gnu
release: 1.72.0-nightly
LLVM version: 16.0.5

Additional Labels

No response

[Centri3]

Does #[phantom] not add #[automatically_derived]? That should prevent it from firing.

I think checking if it's from a proc macro could be worthwhile, though, when that's not done.