...
Within the special rule, ANTLR looks for binary operators and the suffix operators. It also looks one level deep into rules referenced from the special rule. In this case, ANTLR identifies '*' '+' '-' '=' as binary operators and '.' '[' '(' as suffix operators. All other alternatives are lumped together into a new rule:
No Format |
---|
parse_expr_alts
options {backtrack=true;}
: primary
| '(' type ')' e // cast
;
|
The backtrack option is specified in case it is needed, which is in this case because of the cast versus parenthesized expression in primary.
The suffix rule has left recursive references to e
sell those must be removed. The parse_expr rule invokes a suffix after having matched e
already:
No Format |
---|
suffix : '[' e ']' | '(' e (',' e)* ')' ; |
Affect on lookahead
ANTLR can only compute LL(1) lookahead sets for these special rules. So, rules that need to look into expressions might have to backtrack:
No Format |
---|
s : e ';' // nondeterministic; must use option backtrack=true!!!
| e '!'
;
|
Tree construction and actions
Implementation
Have ANTLR build parse_expr rules as templates and then call ANTLRParser.rule() on that text. It will be like an include. This is the mechanism I use for nextToken generation.
It's possible that I could make the precedence tables and the parse_expr rule itself members of the Parser superclass.