-
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
Expands manual_memcpy
to lint ones with loop counters
#5727
Conversation
r? @flip1995 (rust_highfive has picked a reviewer for you, use r? to override) |
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.
Quick early review (didn't read the PR description, only skimmed the code). I will do a in-depth review once the rustup is through and the below mentioned rustc PR is merged.
☔ The latest upstream changes (presumably #5711) made this pull request unmergeable. Please resolve the merge conflicts. |
…ishearth Make AssocOp Copy Found that this enum is not `Copy` while reviewing this Clippy PR: rust-lang/rust-clippy#5727 (comment) There shouldn't be a reason why this should not be `Copy`.
@rail-rain |
Thank you for the information. I've subscribed #5751, so you don't have to ping me again when it gets merged. I will reflect the change in |
☔ The latest upstream changes (presumably #5751) made this pull request unmergeable. Please resolve the merge conflicts. |
20a4453
to
4ae85e0
Compare
@flip1995 I've run |
Yes, I think that would be reasonable in that case, especially, since there are multiple |
☔ The latest upstream changes (presumably #5763) made this pull request unmergeable. Please resolve the merge conflicts. |
Ah, I see. That perfectly make sense. However, I'm afraid squashing could really affects reviews (e.g. the |
Yeah, let's squash right before merging, this is a rather complex PR. I try to leave an in depth review in the coming days (maybe even today). |
I still didn't get to review this in-depth, and I'm sorry! I try to get to this soon. |
That's all right. Take your time. Actually, I don't feel so energetic recently and even haven't been working on other issues. |
4ae85e0
to
2579e43
Compare
Sorry, I wasn't aware of the number of the changes made in |
No problem, thanks for low key reminding me, that I still have to review this 😄 |
☔ The latest upstream changes (presumably #6076) made this pull request unmergeable. Please resolve the merge conflicts. Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:
|
2579e43
to
e855fe3
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.
Sorry for taking so long to review this. Expect multiple review cycles for this lint.
Secondly, manual copying with loop counters are likely to trigger
needless_range_loop
andexplicit_counter_loop
along withmanual_memcpy
; in fact, I explicitly allowed them in the tests. Is there any way to disable these two lints when a code triggersmanual_memcpy
?
Generally triggering two lints with conflicting suggestions at the same time is bad. Normally we can handle this, if they are in the same lint pass with something like this:
if !lint_a_linted {
lint_b()
}
And then only run the lint B, if lint A didn't trigger.
And, another thing I'd like to note is that
Sugg
adds unnecessary parentheses when expressions with parentheses passed to itshir
function, as seen here:
Don't worry about this for now. This is a easy fix in a second pass, because the unnecessary_parens
lint will trigger, which is also auto-applicable.
The suggestion you currently generate only replaces the expression, that creates the range in the loop. You want to replace the whole loop. That means you need to use the span for the whole loop in the suggestion. You can keep the span you currently using for the lint message though (or make it so the span for the lint message starts with for
).
Hello, I've addressed Regarding the span for the suggestion, I've replaced the span with the whole loop; but I'm not sure if I've got what you meant by saying "You can keep the span you currently using". Can I use different spans for tools (namely
PS: I've also implemented |
Changes LGTM, I will do a complete review again right after writing this comment. I just want to write down my thoughts before forgetting them.
Yes, in Clippy with But seeing the suggestion as it is now, I don't think this is necessary and the suggestion is fine now.
Splitting the tests definitely make sense here. I would keep it that way. |
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.
Round 2/3?: Mostly documentation and some style things I noticed.
clippy_lints/src/loops.rs
Outdated
let print_limit = | ||
|end: &Expr<'_>, end_str: &str, base: &Expr<'_>, sugg: MinifyingSugg<'static>| -> MinifyingSugg<'static> { |
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.
Is there a reason, that this is a closure and not a function? Scanning over the code I couldn't find any upvars, so it should be possible to make it a function for consistency.
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.
print_limit
captures cx
and reduces the number of its argument. I actually prefer to make it a function; I kept it just because it was, and there's a couple of examples of this practice in Clippy.
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.
Ah ok. I'm good with both, so you decide if you want to turn it into a function 👍
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.
It turned out print_limit
also captures limits
, and print_offset_and_limit
captures so many; and then I changed my mind. I'd like to keep these closures. (I even removed the explicit return type from print_limit
)
...and also swap their position
* `dst.len()` as the end of the range with loop counters * the increment of the loop counter at the top of the loop
for i in 3..src.len() { | ||
dst[i] = src[count]; | ||
count += 1 | ||
} |
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 should be the last review round:
I would like two more tests (correct me if they won't make sense):
- Use
dst.len()
instead ofsrc.len()
- put
count += 1;
in front ofdst[i] = src[count];
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 probably thought it was fine because the dst.len()
case is tested in without_loop_counters.rs
, and the 'loop counters at the top of the loop' (am I understand what you said correctly?) case is the almost same as #6076, a FP in expilcit_counter_loop
which shares the same visitor to check this case. Having said that, I cannot say these cases don't make sense. So I will add these. Done.
Thanks for all the great work! And for addressing my reviews so quickly, even though I was really slow myself. @bors r+ Let's finally merge this 🚀 |
📌 Commit b541884 has been approved by |
☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test |
Closes #1670
This PR expands
manual_memcpy
to lint ones with loop counters as described in #1670 (comment)Although the current code is working, I have a couple of questions and concerns.
Firstly, I manually implementedThe PR was made.Clone
forSugg
becauseAssocOp
lacksClone
. AsAssocOp
only holds an enum, which isCopy
, as a value, it seemsAssocOp
can beClone
; but, I was not sure where to ask it. Should I make a PR torustc
?Secondly, manual copying with loop counters are likely to trigger
needless_range_loop
andexplicit_counter_loop
along withmanual_memcpy
; in fact, I explicitly allowed them in the tests. Is there any way to disable these two lints when a code triggersmanual_memcpy
?And, another thing I'd like to note is that
Sugg
adds unnecessary parentheses when expressions with parentheses passed to itshir
function, as seen here:However, using the
hir
function is needed to prevent the suggestion causing errors when users use bitwise operations; and also this have already existed, for example:verbose_bit_mask
. Thus, I think this is fine.changelog: Expands
manual_memcpy
to lint ones with loop counters