GeezerVison

Summary

The Pratt expression loops give XOR the same precedence as OR and place |, &, <<, >> on one left-associative level, in every dialect. MySQL's table differs on both counts:

• XOR sits between AND and OR, so 1 OR 1 XOR 1 must parse as 1 OR (1 XOR 1) and not (1 OR 1) XOR 1 (MySQL dialect gives logical XOR the same tier as OR #2835)
• << and >> bind tighter than &, which binds tighter than |, so 1 | 2 & 4 must parse as 1 | (2 & 4) and 3 & 1 << 2 as 3 & (1 << 2) (MySQL bitwise |, &, and shifts still share one parser precedence tier #2834)

Both tiers are gated on Dialect.MYSQL. Every other dialect keeps the shared, left-associative levels that #2833 established, so the default behavior and its regression tests are untouched. Under MySQL SimpleExpression now enters the arithmetic loop at floor 2 so | is admitted at all.

One subtlety this uncovered: the javacc plugin can leave target/generated-sources stale across incremental compiles, which made the fix look broken locally until a full regen.

Test plan

• 1 | 2 & 4 under MySQL parses as BitwiseOr(1, BitwiseAnd(2, 4))
• 3 & 1 << 2 under MySQL parses as BitwiseAnd(3, BitwiseLeftShift(1, 2))
• 1 OR 1 XOR 1 under MySQL parses as OrExpression(1, XorExpression(1, 1))
• 1 XOR 1 AND 1 under MySQL parses as XorExpression(1, AndExpression(1, 1))
• Default dialect 4 | 1 & 0 still parses as (4 | 1) & 0 (fix: bind bitwise operators looser than + and - #2833 test intact)
• New regression tests in ExpressionPrecedenceTest
• Full suite: 10,663 tests, 0 failures