-
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
Don't lint vec_init_then_push
when further extended
#8699
Conversation
r? @flip1995 (rust-highfive has picked a reviewer for you, use r? to override) |
24974f7
to
4e501fa
Compare
☔ The latest upstream changes (presumably #8563) made this pull request unmergeable. Please resolve the merge conflicts. |
r? @dswij 🙃 |
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.
Changes LGTM, only a suggestion to document the lint behavior
Hey @Jarcho, could you resolve the conflicts? Then we could see if the CI passes 🙃 |
ff3ba2f
to
94ec421
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.
Looks good to me overall, a few nits and that it should be ready.
Also thank you for your patience, I forgot this was on my todo list 😅
&& adjusted_mut == Mutability::Mut | ||
&& !adjusted_ty.peel_refs().is_slice() => | ||
{ | ||
return ControlFlow::Break(true); |
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.
Shouldn't this also set needs_mut = true
?
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.
That case doesn't lint.
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.
But it could, couldn't it? The code later checks:
if res == ControlFlow::Break(true) && self.found <= required_pushes_before_extension {
return;
}
Which could still be false if self.found
is > 4. Or should that be an or check in the if statement?
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.
Ignore my previous comment. I don't know what I was looking.
It will already be set by that point, either by explicitly taking a mutable reference, or from an adjustment taking a mutable reference.
I'll add a note about it.
fn _from_iter(items: impl Iterator<Item = u32>) -> Vec<u32> { | ||
let mut v = Vec::new(); | ||
v.push(0); | ||
v.push(1); | ||
v.extend(items); | ||
v | ||
} |
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.
Could you add a second test like this, that reaches the threshold and triggers the lint? From my understanding, it should be as simple as:
fn _from_iter_trigger(items: impl Iterator<Item = u32>) -> Vec<u32> {
let mut v = Vec::new();
v.push(0);
v.push(1);
v.push(2);
v.push(3);
v.extend(items);
v
}
Also, a test with the capacity would be good, like:
let mut cap_err = Vec::with_capacity(4);
cap_err.push(0);
cap_err.push(1);
cap_err.push(2);
That shouldn't lint either from my understanding
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.
The reason for avoiding the boundary case is to avoid having to change the test if we decide to nudge it a little. It doesn't really matter either way, just that the specific number isn't important.
with_capacity
could do with a case right at the edge though.
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.
The reason for avoiding the boundary case is to avoid having to change the test if we decide to nudge it a little.
Okay, then could you add one with some more space, it doesn't have to be at the boundary, but I don't see one for this case 🙃
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.
The last test covers it with a much larger number.
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.
The last test covers an if statement. The lint already took if statements into account, that's why I didn't consider this a test to this case. Since you want to add a note about the other comment, could you add a test with extend
or some other method?
94ec421
to
0e70f29
Compare
0e70f29
to
f1574cc
Compare
@bors r=dswij,xFrednet |
📌 Commit f1574cc has been approved by |
☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test |
fixes #7071
This will still lint when a larger number of pushes are done (four currently). The exact number could be debated, but this is more readable then a sequence of pushes so it shouldn't be too large.
changelog: Don't lint
vec_init_then_push
when further extended.changelog: Remove
mut
binding fromvec_init_then_push
when possible.