fix: separate binary expression from pattern

[jtkiesel]

What changed with this PR:

Rather than treating the optional binary expression following a pattern as part of the pattern itself, treat the entire expression as a binary expression, of which the pattern is a part, so that the usual binary expression formatting applies.

Example

Input

class Example {

  public boolean test(final Object obj) {
    return obj instanceof final Integer x && (x == 5 || x == 6 || x == 7 || x == 8 || x == 9 || x == 10 || x == 11);
  }
}

Output

class Example {

  public boolean test(final Object obj) {
    return (
      obj instanceof final Integer x &&
      (x == 5 || x == 6 || x == 7 || x == 8 || x == 9 || x == 10 || x == 11)
    );
  }
}

Relative issues or prs:

Closes #605

[clementdessoude]

I am not a fan of modifying the CST in order to make it easier to print the code afterwards, as it makes the java parser maintenance much more difficult for each deviation from the spec

[jtkiesel]

@clementdessoude I looked into the spec while implementing this solution, because I had similar concerns. What I found was that a Pattern is a TypePattern, which is a LocalVariableDeclaration, meaning that according to the spec, a Pattern should not contain AndAnd or a binaryExpression within it. I made this change because it seemed to make the parser more aligned with the spec.

All that being said, this solution is occasionally failing tests because it seems to have slowed down parsing, so I'll need to find a fix for that. But I do think this change to the CST is appropriate, unless I'm missing something.

[jtkiesel]

It seems that the && style of the switch label "guarded" pattern is no more, and has been replaced with when in Java 21 (the first version that supports switch label pattern matching outside of a preview feature), which is scheduled to release tomorrow. So I will likely need to rethink this solution regardless. https://docs.oracle.com/javase/specs/jls/se21/html/jls-14.html#jls-SwitchLabel

[jtkiesel]

#611 solves the issue described in #605 also, while simultaneously supporting the now-official "when" style of guards. Assuming that PR is merged, we can close this one.