Extend manual_filter to cover and_then

[profetia]

View all comments

Closes #14440

Implemented as enhancement to manual_filter

changelog: [manual_filter] enhance to cover and_then

[rustbot]

r? @llogiq

rustbot has assigned @llogiq.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[github-actions]

Lintcheck changes for 3351369

Lint	Added	Removed	Changed
clippy::manual_filter	3	0	0

This comment will be updated if you push new changes

[profetia]

r? clippy

[profetia]

r? clippy

[ada4a]

@Jarcho since you are intending to eventually split the lints crate, these changes would probably require eventually splitting this lint into two as well: one for the matches pass, and one for the methods pass. But imo that would be awkward -- not least because we'll need to invent a new name for what's essentially the same lint. So I was thinking about some alternative approaches.

At first, I thought we could:

1. move the declare_clippy_lint! to clippy_lints/src/lib.rs
2. import the lint struct from both methods/mod.rs and matches/mod.rs, and add it to both passes
3. have matches/manual_filter.rs for the part of the lint that deals with matches (the current code), and methods/manual_filter.rs for the part that deals with methods (the new code in this PR), and call their corresponding functions from inside the passes.

One problem with that is this helper function get_cond_expr which is shared between the two parts of the implementation, pushing us toward having the whole lint in one file. Therefore, a second idea would be to:

1. have a new crate like clippy_multipass_lints for crates like this one, and add it as a dependency for each pass crate as needed
2. define the whole lint (including the declaration) in this new crate, in one file
3. import the declaration and the functions to both passes' crates, and use them there

I think this would retain the benefits of crate splitting (lower compile times), since this multipass crate, while being a dependence of many pass crates, should be pretty small, and so should compile quickly and let the parallelism kick in directly afterwards.

What do you think?

[profetia]

@ada4a Is there any update needed for this PR? Or maybe we can have it merged.

[ada4a]

One more question, after that let's merge this -- it should be easy enough to adjust later if desired

View changes since this review

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[ada4a]

Thank you:)

View changes since this review