I have a type, Id, which is really cheap to copy, yet unfortunately cannot implement Copy: it uses just a u64 in-memory representation in almost all cases, and a reference-counted heap-allocated representation in the remaining cases. It also gets used quite frequently, and I want to make it easy to use and pass around. I mean, I'm almost tempted to let heap-allocated instances leak just so that I can implement Copy.
It's also common to want to copy an Option<Id> around. Queue Clippy's assigning_clones recommending usage of clone_from instead, despite the fact that Id does not implement clone_from (or have anything to gain if it did, since the
heap-allocated representations are not mutable).
Besides which, usages of Id are not particularly performance sensitive. Remember premature optimisation is the root of all evil? There may be cases where this lint significantly improves code, but it's not here.
Expectation
Either that Clippy can recognise the false positive (Option impls clone_from but T doesn't) or that this lint can be disabled with an annotation on the type.
Lint Name
assigning_clones
Reproducer
I tried this code:
mod inner {
#[derive(Clone, Debug, PartialEq, Eq)]
pub struct Id(u64);
impl From<u64> for Id {
fn from(n: u64) -> Self {
Id(n)
}
}
}
use inner::Id;
fn main() {
let a = Some(Id::from(123));
let mut b = None;
assert!(a != b);
b = a.clone();
assert_eq!(a, b);
dbg!(b);
}
I saw this happen:
$ cargo clippy
Checking assigning_clones v0.1.0 (/home/dhardy/projects/small/assigning_clones)
warning: assigning the result of `Clone::clone()` may be inefficient
--> src/main.rs:17:5
|
17 | b = a.clone();
| ^^^^^^^^^^^^^ help: use `clone_from()`: `b.clone_from(&a)`
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#assigning_clones
= note: `#[warn(clippy::assigning_clones)]` on by default
warning: `assigning_clones` (bin "assigning_clones") generated 1 warning
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.04s
Summary
Motivation
I have a type,
Id
, which is really cheap to copy, yet unfortunately cannot implementCopy
: it uses just au64
in-memory representation in almost all cases, and a reference-counted heap-allocated representation in the remaining cases. It also gets used quite frequently, and I want to make it easy to use and pass around. I mean, I'm almost tempted to let heap-allocated instances leak just so that I can implementCopy
.It's also common to want to copy an
Option<Id>
around. Queue Clippy'sassigning_clones
recommending usage ofclone_from
instead, despite the fact thatId
does not implementclone_from
(or have anything to gain if it did, since the heap-allocated representations are not mutable).Besides which, usages of
Id
are not particularly performance sensitive. Remember premature optimisation is the root of all evil? There may be cases where this lint significantly improves code, but it's not here.Expectation
Either that Clippy can recognise the false positive (
Option
implsclone_from
butT
doesn't) or that this lint can be disabled with an annotation on the type.Lint Name
assigning_clones
Reproducer
I tried this code:
I saw this happen:
I expected to see this happen: no warning.
Version
Additional Labels
No response