Some unused_parens suggestions can result in keyword soup (even if technically correct).

[eddyb]

During some testcase minimization, I expanded an a && b by hand and ended up with this:

pub fn if_and_and<T>(a: bool, b: bool, x: T, y: T) -> T {
    if (if a { b } else { false }) {
        x
    } else {
        y
    }
}

The parens make it possible to read it as "nested if, in if condition", but rustc is having none of that:

warning: unnecessary parentheses around `if` condition
 --> src/lib.rs:2:8
  |
2 |     if (if a { b } else { false }) {
  |        ^                         ^
  |
  = note: `#[warn(unused_parens)]` on by default
help: remove these parentheses
  |
2 -     if (if a { b } else { false }) {
2 +     if if a { b } else { false } {
  |

I'm guessing this triggers for any combination like if (match, match (match, match (if, while (if etc.
Even if it may parse successfully, successful keywords like that is a really bad idea IMO.

Other than the expressions of the form keyword EXPR {...}, I also think e.g. return return and break break would be more readable as return (return) and break (break) (so pretty much all keyword-introduced expressions, really).

Maybe such expressions can be accidentally typed (or the result of some automated refactor?), so suggesting adding parens around them (if we had that capability) could help the user understand what rustc is even parsing their keyword soup as - but at least we shouldn't discourage them from adding the parens themselves.

---

Looking at other unused_parens issues it seems there's even false positive where the lint isn't even technically correct (and its suggestions wouldn't parse at all).
Maybe all the false positives should be combined into one issue? (might also help raise visibility)