Hello! On Tue, Jan 15, 2019 at 3:09 AM Alex Buckley <[email protected]> wrote: > That's an odd assumption, because SwitchLabeledRule appears in the > SwitchBlock of a SwitchExpression, and we obviously intend any kind of > expression to be allowed after the -> in a switch expression. That is, > in a switch expression, what comes after the -> is not just an > expression statement (x=y, ++x, --x, x++, x--, x.m(), new X()) but any > expression (including this, X.class, x.f, x[i], x::m). Only in a switch > statement do we restrict the kind of expression allowed after the -> but > that's a semantic rule (14.11.2), not syntactic, in order to share the > grammar between switch expressions and switch statements.
My bad, I should have been more explicit here. We are IDE, so dealing with incomplete/erroneous code is our first priority. In our grammar an expression statement is any expression plus semicolon. This allows to build well-formed AST from something like "a+b()%c;". Of course, error highlighter marks this as invalid code when visits such node, but other features work nicely. E.g. you can introduce variable here, inline b() call or have a division-by-zero warning if c happens to be always zero at this point. Also this was expanded to enhanced switches nicely: for switch statement SwitchLabeledExpression we just reuse the same error highlighting code as for expression statements, because semantic rule is the same. The only ugliness is switch expression inside SwitchLabeledExpression which I mentioned in the first message. With best regards, Tagir Valeev.
