-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
issue#3424 improve filter_map lint docs #3461
Conversation
I've tested all of these on the rust playground. One thing I'm not certain about is whether or not it's okay to create multiple example headings -- I thought it would be a good idea to create a separate section for each combination. Also, I have to say that the |
We had discussion about this lint in issue #3188 and concluded that |
Actually linting |
} | ||
|
||
/// lint use of `filter().flat_map()` for `Iterators` | ||
fn lint_filter_flat_map<'a, 'tcx>( |
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.
@mikerite I added a commit to this PR that removes the linting of filter().flat_map()
since I couldn't think of a simpler way to achieve the same behavior based on the example you gave. I'd be happy to add it back and include it in the updated docstring if you have any guidance for me here. Thanks!
6926b28
to
c2eb74f
Compare
☔ The latest upstream changes (presumably #3529) made this pull request unmergeable. Please resolve the merge conflicts. |
Ping @waynr. I'm going over old PRs, that were abandoned by us reviewers (sorry for that!) or by the authors. Are you still interested in completing this? |
@flip1995 I am still interested, it just fell off my radar! I'll try to get to it no later than Monday next week (but possibly as early as tonight). Thanks for the ping! |
* issue#3188 make the 'filter_map' lint more specific * Remove filter + flat_map lint * Run 'util/dev update_lints' * Update filter_methods.stderr * Address dogfood ci failure * Add FILTER_MAP_MAP to the methods LintPass
Okay I've resolved the merge conflicts and I think everything is order again so this should be ready for re-review. Reviewers may want to ensure that I haven't unintentionally changed anything important while rebasing -- I don't remember much about this work and haven't worked with Rust since so I'm missing much of the context I had back in December when originally working on it. |
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 for getting back to this!
cc @mikerite can you also take a look at this please?
clippy_lints/src/methods/mod.rs
Outdated
pedantic, | ||
"using `filter_map` followed by `map` can more concisely be written as a single method call" | ||
} | ||
|
||
declare_clippy_lint! { | ||
/// **What it does:** Checks for usage of `_.filter(_).map(_)`, | ||
/// `_.filter(_).flat_map(_)`, `_.filter_map(_).flat_map(_)` and similar. |
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 doc needs to be adapted
Co-Authored-By: Philipp Krones <hello@philkrones.com>
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 need to do a in depth review of this, but probably won't have time for this until next week...
/// println!("{:?}", correct); | ||
/// assert_eq!(correct, more_correct); | ||
/// ``` | ||
/// .iter() |
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.
You forgot to remove the old example code 😉
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 finally got to reviewing this more in depth. Sorry for the long wait time :(
I think removing both filter().flat_map()
and filter_map().flat_map()
is totally fine, since I can only think of some few edge cases where rewriting this into one function call would maybe make sense.
let mut span = expr.span; | ||
if let hir::ExprKind::MethodCall(_, _, ref expr_vec) = expr.node { | ||
if let hir::ExprKind::MethodCall(_, ref filter_span, _) = expr_vec[0].node { | ||
span = Span::new(filter_span.lo(), expr.span.hi(), expr.span.ctxt()); |
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.
There's already a function for this on Span
: https://doc.rust-lang.org/nightly/nightly-rustc/src/syntax_pos/lib.rs.html#217-219
span = Span::new(filter_span.lo(), expr.span.hi(), expr.span.ctxt()); | |
span = expr.span.with_lo(filter_span.lo()); |
|
||
error: called `filter_map(p).flat_map(q)` on an `Iterator`. This is more succinctly expressed by calling `.flat_map(..)` and filtering by returning an empty Iterator. | ||
--> $DIR/filter_methods.rs:13:21 | ||
error: redundant closure found |
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.
Can you allow redundant_closure
for these tests?
.collect(); | ||
|
||
// validate iterator of options triggers filter + flat_map 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.
This was removed in this PR, wasn't it?
.map(|s| format!("{}{}", s, s)) | ||
.collect(); | ||
|
||
// validate iterator of values **does not** trigger filter + flat_map 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.
Same as above: Wasn't this removed completely anyway?
☔ The latest upstream changes (presumably #4259) made this pull request unmergeable. Please resolve the merge conflicts. |
Hi @waynr, would you still be up to finish this PR? No worries if not, it's been a long time =) |
Thanks for contributing to Clippy! Sadly this PR was not updated in quite some time. If you waited on input from a reviewer, we're sorry that this fell under the radar. If you want to continue to work on this, just reopen the PR and/or ping a reviewer. |
@rustbot label -S-inactive-closed |
for #3424