New lint: unnecessary_map_or

[Jacherr]

Closes #10118

This lint checks map_or method calls to check if they can be consolidated down to something simpler and/or more readable.

For example, the code

let x = Some(5);
x.map_or(false, |n| n == 5)

can be rewritten as

let x = Some(5);
x == Some(5)

In addition, when the closure is more complex, the code can be altered from, say,

let x = Ok::<Vec<i32>, i32>(vec![5]);
x.map_or(false, |n| n == [5])

into

let x = Ok::<Vec<i32>, i32>(vec![5]);
x.is_some_and(|n| n == [5])

This lint also considers cases where the map_or can be chained with other method calls, and accommodates accordingly by adding extra parentheses as needed to the suggestion.

changelog: add new lint unnecessary_map_or

[rustbot]

r? @Centri3

(rustbot has picked a reviewer for you, use r? to override)

[WaffleLapkin]

@Jacherr this seems to be waiting on you, since Catherine left you a review.
@rustbot author

[Jacherr]

Hi, apologies for the lack of movement on this. I’ll make changes based on the review now, and once everything is up to standard I’ll go through the conflicts.

[Jacherr]

@rustbot ready

[bors]

☔ The latest upstream changes (presumably #12310) made this pull request unmergeable. Please resolve the merge conflicts.

[bors]

☔ The latest upstream changes (presumably #12507) made this pull request unmergeable. Please resolve the merge conflicts.

[xFrednet]

Hey @Jacherr Sorry for the delay. @Centri3 was sadly busy, but now she indicated that she'll have time for reviews again. Would you mind rebasing again? Next time there is a long delay, you can also pick a new reviewer with r? clippy.

[bors]

☔ The latest upstream changes (presumably #12999) made this pull request unmergeable. Please resolve the merge conflicts.

[Centri3]

Just a couple more changes then this is good <3

[xFrednet]

Never mind: My GH view was outdated

[xFrednet]

Hey, this is a ping from triage. @Centri3 can you give this PR a review? It's totally fine if you don't have the time right now, you can reassign the PR to a random team member using r? clippy.

@rustbot ready

[bors]

☔ The latest upstream changes (presumably #13168) made this pull request unmergeable. Please resolve the merge conflicts.

[bors]

☔ The latest upstream changes (presumably #13496) made this pull request unmergeable. Please resolve the merge conflicts.

[Jacherr]

Apologies for the slow turnover again. I hope this is the last of the issues now and this can finally be merged 😅

[samueltardieu]

It looks like you marked the comment in #11796 (comment) as resolved but it is not. The example:

fn main() {
    struct S;
    let r: Result<i32, S> = Ok(3);
    let _ = r.map_or(false, |x| x == 7);
}

will incorrectly suggest using (r == Ok(7)) (also, note the extra parentheses, but this is not the main problem, which is that Result<i32, S> does not implement PartialEq). A proposed fix is given in the linked comment.

Could you also add this as a testcase? As well as one where S is a type which implements PartialEq (such as i32), to check for the extra parentheses?

[samueltardieu]

These ( should be removed, shouldn't they?

[Jacherr]

I think this is just an effect of maybe_par deciding they should be present. While I'd usually agree, I'm not sure there is a better way to tackle that?