-
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: to_
convention respects Copy
types
#6924
Conversation
r? @llogiq (rust-highfive has picked a reviewer for you, use r? to override) |
/// |`to_` | not `_mut` |`&self` | | ||
/// |Prefix |Postfix |`self` taken | `self` type | | ||
/// |-------|------------|-----------------------|--------------| | ||
/// |`as_` | none |`&self` or `&mut self` | any | |
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.
I'm wondering if it wouldn't be more clear to have n/a
instead of none
where the Postfix doesn't matter.
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.
I personally don't think an abbreviation of "not applicable" is clearer than "none" when there is no suffix, but that may be my dislike of needless abbreviations.
0bc7ac1
to
e1abe44
Compare
e1abe44
to
ea15fb2
Compare
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 looks pretty solid, I just have one nitpick in the tests.
@@ -79,6 +79,7 @@ mod issue2894 { | |||
} | |||
|
|||
// This should not be linted |
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.
If this comment is correct, then why the #[allow(..)]
below?
@@ -79,6 +79,7 @@ mod issue2894 { | |||
} | |||
|
|||
// This should not be linted |
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.
Same here. I get that it's probably a different lint that should not trigger, but it still feels wrong.
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, the comment says that use_self
shouldn't trigger.
I added the #[allow(clippy::wrong_self_convention)]
to suppress the warning that occurred there, after current changes. I wasn't sure whether I should adjust the self convention there.
Agree it's better to adjust that uitest to the proper self convention, which I did in the next commit.
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.
I had another look and found another nit to pick 😉
@@ -191,5 +175,21 @@ LL | fn from_i32(self); | |||
| | |||
= help: consider choosing a less ambiguous name | |||
|
|||
error: methods with the following characteristics: (`to_*` and `self type is Copy`) usually take self by value |
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.
Looking once more at the resulting error message, this gave me pause: "`self type is Copy`" should probably read "`self` type is `Copy`" (note the double space and the backticks).
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.
Good catch, thanks!
980dbd3
to
39cabcd
Compare
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 is almost it... Just remove the "
s from the characteristics.
--> $DIR/wrong_self_convention.rs:40:15 | ||
| | ||
LL | fn is_i32(self) {} | ||
| ^^^^ | ||
| | ||
= help: consider choosing a less ambiguous name | ||
|
||
error: methods called `to_*` usually take self by reference | ||
error: methods with the following characteristics: ("to_*" and "`self` type is not `Copy`") usually take self by reference |
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.
Oops, I think you copied the "
signs, which I only used to split the characteristics from the sentence.
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 thing I'm not sure about now, should to_* have backticks or not?
E.g. this way:
error: methods with the following characteristics: (to_* and self
type is not Copy
) usually take self by reference
Or this:
error: methods with the following characteristics: (to_*
and self
type is not Copy
) usually take self by reference
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.
I think it should be the latter, to drive home that this should match a method name. We could also backtick the self
in "usually take self
by reference".
39cabcd
to
b6175cd
Compare
b6175cd
to
1f2d016
Compare
Thank you! @bors r+ |
📌 Commit 1f2d016 has been approved by |
☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test |
Fix FP in `wrong_self_convention` lint Previously, this lint didn't check into impl block when it was implementing a trait. Recent improvements (#6924) have moved this check and some impl blocks are now checked but they shouldn't, such as in #7032. Fixes #7032 changelog: Fix FP when not taking `self` in impl block for `wrong_self_convention` lint
fixes #6727
changelog: wrong_self_convention:
to_
convention respectsCopy
types