fix incorrect suggestion for !(a >= b) as i32 == c

[CoCo-Japan-pan]

fixes #12761

The expression !(a >= b) as i32 == c got simplified to a < b as i32 == c, but this is a syntax error.
The result we want is (a < b) as i32 == c.
This is fixed by adding a parenthesis to the suggestion given in check_simplify_not when the boolean expression is casted.

changelog: [nonminimal_bool]: fix incorrect suggestion for !(a >= b) as i32 == c

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Centri3 (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[Centri3]

I'd say we should use Sugg::maybe_par in clippy_utils for this. The code is correct for this case, but it's missing other cases (mostly binary ops) where parentheses are required. For example, !(1 >= 2) | true == a also causes the same issue, which the suggested function handles.

[CoCo-Japan-pan]

I wasn't familiar with the clippy_utils::sugg, and I think my code is redundant, but I'll push this for now.
I thought we have to keep the parent expression, so I added a stack, but maybe just applying Sugg::maybe_par to the suggestion in let Some(suggestion) = simplify_not(cx, inner) was sufficient?

[CoCo-Japan-pan]

Given the fact that simplify_not only deals with ExprKind::Binary and ExprKind::MethodCall, I believe the problem occurs only when we simplify ExprKind::Binary, and the expression belongs to ExprKind::Cast or ExprKind::Binary (please let me know if there are more), so I changed the need_parens logic.

[bors]

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

[Centri3]

Well, this code is incorrect when the suggestion is applied:

fn a(a: bool) -> bool {
    (!(4 > 3)).b()
}

trait B {
    fn b(&self) -> bool { true }
}

impl B for bool {}

Really, is there any reason not to use Sugg directly? It's easier (and much less error prone in the future) than getting the parent expression as well.

[Centri3]

You can get the parent using get_parent_expr. You can use for_each_expr to look for expressions with a specific kind if that's needed.

[CoCo-Japan-pan]

Using Sugg::maybe_par would be like this?
Or should we get the modified Expr (not just the String) from simplify_not, and then apply maybe_par?
Currently it doesn't see the parent expression, and adds an unnecessary parenthesis to some expressions like below.

if !(12 == a) {}
   ^^^^^^^^^^ help: try: `(12 != a)`

[CoCo-Japan-pan]

Excluded the case when the parent expression is the ExprKind::DropTemps(_) to avoid adding unnecessary parenthesis.

[Centri3]

and adds an unnecessary parenthesis to some expressions like below.

Yes, I know, this is a non-issue as unused_parens will almost always catch it and if it doesn't that's fine too.

Why do we need the parent expression? Is there any case where it misses required parentheses in that case? This feels overly complicated for 2 characters that will likely be removed on the next clippy run.

[CoCo-Japan-pan]

Deleted the parent expression stuff.