incorrect_clone_impl_on_copy_type false positive when macro-generated code doesn't know whether the type is Copy
Opened this issue · 1 comments
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
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.