Lint against calling .clone() on an otherwise copyable value.

[eddyb]

Certain types could start out as having contents that move and then switch to only copyable field, or could just be missing #[deriving(Copy)] initially.

If Copy is implemented after that type has been used in a large codebase (there's a few cases in rustc itself), there will likely be many .clone() calls around, and finding which ones belong to the type could be tedious.

A lint would ease this work, by suggesting the replacement of an unnecessary x.clone() call with a dereference (if x is a reference to the type being cloned - could use the autoderef count here) or nothing at all (since using a Copy lvalue as an rvalue will just copy it).

[nagisa]

Is it really necessary? Doesn’t sound like a footgun type of an issue.

[Gankra]

I agree with @nagisa, especially if your code is generated (macros, syntax extensions, etc...).

[eddyb]

I don't know how else to clean up the compiler code. In a cargo crate I'd just use clippy.

[Gankra]

@eddyb ...is it a serious problem?

[steveklabnik]

Since new lints have a big impact on users of rustc, the policy is that they should go through the RFC process like other user-facing changes. As such, I'm going to give this one a close, but if anyone comes across this ticket and wants this lint, consider adding it to clippy and/or writing up an RFC. Thanks!

[eddyb]

@steveklabnik That's fine, I'm hoping #31123 will let us use clippy on rustc fairly easy.

[Manishearth]

(Exists in clippy, https://github.com/Manishearth/rust-clippy/wiki#clone_on_copy)

[strega-nil]

This seems really useful in normal rust, like with <&T>::clone

[Manishearth]

The current policy is no new lints in Rust unless it's really special.

[strega-nil]

Merp :(