-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Rework only_used_in_recursion
#8804
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
Conversation
r? @Manishearth (rust-highfive has picked a reviewer for you, use r? to override) |
r? @Alexendoo Would you maybe like to review this PR? 🙃 |
Sure thing, I'll take a look at it |
44646b9
to
97a5177
Compare
☔ The latest upstream changes (presumably #8856) made this pull request unmergeable. Please resolve the merge conflicts. |
Hey @Alexendoo, was this PR done after your comment was fixed? 🙃 |
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 wonder whether we want to mirror the unused
behaviour of ignoring self
entirely, I could see a preference for having method syntax even where it's not technically needed. It may also be surprising that adding a call would cause an unused style warning to appear
Other than that I have a few small bits of feedback, nothing major is jumping out at me but this is still a fairly complex lint
I tested this branch on bunch of crates and found a false positive.
This is what the function looks like. The lint misses the usage
|
Auto-deref makes linting not fun. Fixed. |
I assume the reason for not linting The reasons for having an unused parameter in the first place are less applicable for this lint. Either the existence of the type has meaning, or API compatibility. The former is a pattern definitely used for |
I'll leave this PR to you @Alexendoo. Please don't hesitate to reach out if you need any assistance. r? @Alexendoo |
Should be fine now. |
/// Sets the `block_lint` flag on each parameter. | ||
fn flag_for_linting(&mut self) { | ||
// Stores the list of parameters currently being resolved. Needed to avoid cycles. | ||
let mut eval_stack = Vec::new(); | ||
for param in &self.params { | ||
self.try_block_lint_for_param(param, &mut eval_stack); | ||
} | ||
} |
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! Just one last thing, a couple references to block_lint
remain
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.
Done.
☔ The latest upstream changes (presumably #8957) made this pull request unmergeable. Please resolve the merge conflicts. |
Thanks! @bors r+ |
☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test |
this PR doesn't resolve the false positive here - marshallpierce/rust-base64#188 |
fixes #8782
fixes #8629
fixes #8560
fixes #8556
This is a complete rewrite of the lint. This loses some capabilities of the old implementation. Namely the ability to track through tuple and slice patterns, as well as the ability to trace through assignments.
The two reported bugs are fixed with this. One was caused by using the name of the method rather than resolving to the
DefId
of the called method. The second was cause by using the existence of a cycle in the dependency graph to determine whether the parameter was used in recursion even though there were other ways to create a cycle in the graph.Implementation wise this switches from using a visitor to walking up the tree from every use of each parameter until it has been determined the parameter is used for something other than recursion. This is likely to perform better as it avoids walking the entire function a second time, and it is unlikely to walk up the HIR tree very much. Some cases would perform worse though.
cc @buttercrab
changelog: Scale back
only_used_in_recursion
to fix false positiveschangelog: Move
only_used_in_recursion
back tocomplexity