-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
wrong_self_convention: fix FP inside trait impl for to_*
method taking &self
#7002
Merged
bors
merged 1 commit into
rust-lang:master
from
mgacek8:issue6983_wrong_self_convention_inside_trait_impls
Apr 1, 2021
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,32 @@ | ||
// edition:2018 | ||
#![warn(clippy::wrong_self_convention)] | ||
#![warn(clippy::wrong_pub_self_convention)] | ||
#![allow(dead_code)] | ||
|
||
fn main() {} | ||
|
||
mod issue6983 { | ||
pub struct Thing; | ||
pub trait Trait { | ||
fn to_thing(&self) -> Thing; | ||
} | ||
|
||
impl Trait for u8 { | ||
// don't trigger, e.g. `ToString` from `std` requires `&self` | ||
fn to_thing(&self) -> Thing { | ||
Thing | ||
} | ||
} | ||
|
||
trait ToU64 { | ||
fn to_u64(self) -> u64; | ||
} | ||
|
||
struct FooNoCopy; | ||
// trigger lint | ||
impl ToU64 for FooNoCopy { | ||
fn to_u64(self) -> u64 { | ||
2 | ||
} | ||
} | ||
} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,11 @@ | ||
error: methods with the following characteristics: (`to_*` and `self` type is not `Copy`) usually take `self` by reference | ||
--> $DIR/wrong_self_convention2.rs:28:19 | ||
| | ||
LL | fn to_u64(self) -> u64 { | ||
| ^^^^ | ||
| | ||
= note: `-D clippy::wrong-self-convention` implied by `-D warnings` | ||
= help: consider choosing a less ambiguous name | ||
|
||
error: aborting due to previous error | ||
|
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This still triggers on the trait implementation, not on the trait definition. Is this intended?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I put that intentionally.
The issue pointed out that a trait method signature is controlled by the trait, and there might be other types implementing the same trait that are not
Copy
. That's why we should allow aCopy
type to take&self
instead of justself
in the case ofto_*
method when it comes from a trait.But, the other way around, where we have a
to_*
method from a trait that requiresself
and the type implementing it is notCopy
then probably that's not something desirable. As I see (e.g. based onto_string(&self)
fromstd::string::ToString
trait) if you expect types implementing your trait to not always beCopy
you should mark yourto_*
method as&self
. That's why I thought a lint, in this case, might be useful. Having said that, I'm not super strong on that, so if someone thinks differently that we should also allow this case, I can change that.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, but in order to change this, you would also have to change the trait definition, so you could just as well directly lint on the trait definition. Do you have a reason why it shouldn't lint on trait definitions?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One reason is that from trait definition alone you don't know what types will implement it. It might be that a particular trait is implemented only by
Copy
types. E.g. as in the #6727There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense. Do you think we should stop linting completely then, if traits are involved?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you motivated to put some more work into this, so that this lint doesn't trigger on the
to
variant in trait definitions and implementations anymore?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, sure, I can do that. Do you think there might be some valid use-cases for that scenario ? (non-
Copy
type implementing trait'sto_*
method takingself
). Or is it just better to stay less stringent?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
Yes, I think there is value to a lint saying "your trying to implement a trait that is probably meant for a
Copy
type, but you're implementing it on a non-Copy
type". But I don't think we should do this in this lint, but rather make a new allow-by-default (pedantic
) lint for this. I don't think Clippy should warn by default for this.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, agree that having this as allow-by-default would be better!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PR: #7182