rust-lang
feat(manual_is_variant): Check for `.iter().any()`
Now the linter checks for calling the iter or into_iter method
followed by calling the all or any method.
We have used these methods by mistake ourselves. The developer was not
familiar with the is_some_and method. He tried to use the any
method on an option. The compiler suggested using iter first. The
developer did not get to learn about the idiomatic method.
The lint search_is_some involves converting a closure that takes the
reference into one that takes the value. The code is split between the
function for the lint and a shared function. The new feature that we
are adding involves the same transformation. To do so it needs some of
the same code that is currently in the search_is_some lint. So it is
moved from the lint into the shared function.
Before this patch, line 799 in the file clippy_utils/src/sugg.rs had a
check. It made the function return none in case the closure did not
dereference the argument. However, the code for the lint
search_is_some would then fall back to using the original closure.
That achieved the same effect as the check not existing. So the check
is now removed.
changelog: [manual_is_variant]: check for calling the iter or
into_iter method followed by calling the all or any method
changelog: [manual_is_variant]: skip the check when the MSRV is before
1.70
r? @Alexendoo
rustbot has assigned @Alexendoo. 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
If the input uses .iter().any() on a value that is not Copy, the current version of the patch makes the linter suggest using .as_ref().is_some_and(). The suggestion is longer than the original code. Should the linter skip it instead?
:umbrella: The latest upstream changes (possibly 31d8210a539c7260bd475666cc5bc93927ba0730) made this pull request unmergeable. Please resolve the merge conflicts.
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.
:umbrella: The latest upstream changes (possibly a6dfbb3524e9cb0180214f0666540773fd7b0c8a) made this pull request unmergeable. Please resolve the merge conflicts.
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.