-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clone
should be *self
for types which are always Copy
#10700
Labels
A-lint
Area: New lints
Comments
Here's an example of a place in the wild where this lint is would have been applicable: bevyengine/bevy#8247. This one is made especially nicer by dereferencing, since it allows us to skip referring to a |
This was referenced Jun 9, 2023
This was referenced Jul 3, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What it does
If a type's
Clone
impl has the samewhere
bounds as itsCopy
impl, then this gives a warning unless theClone
impl body is exactlyInspired by the incorrect code in https://users.rust-lang.org/t/why-is-the-value-expression-with-the-type-implemented-copy-not-desugared-to-e-clone/92921?u=scottmcm, which currently gets no clippy warnings https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=3fa61e0abb79c6a444d2ef77a5c6033c.
Lint Name
overcomplicated_clone_impl
Category
suspicious, complexity
Advantage
It's shorter to write than other options, and it always correct -- anything with different behaviour would be a violation of the
Copy
+Clone
contract.Thus using any other implementation is just asking for that more-complicated implementation to have a logic error.
Drawbacks
Macros might not want to special-case their generation to meet this.
Example
Could be written as:
(Which, notably, can't just use
#[derive(Copy, Clone)]
.)The text was updated successfully, but these errors were encountered: