[antlr-interest] java.g in ANTLR v3
Terence Parr
parrt at cs.usfca.edu
Wed Jun 28 10:48:56 PDT 2006
Ok, I'm looking at the java grammar submitted by Thomas as derived
from the java language spec... when from what I can tell, in the
addition of the generics causes all sorts of problems:
type
: Identifier (typeArguments)?
(DOT Identifier (typeArguments)? )* (LBRACK RBRACK)*
| basicType
;
Note that a<b can be the start of an expression or the start a type
spec a<b>. ANTLR correctly says
java.g:45:15: ANTLR could not analyze this decision in rule type;
often this is because of recursive rule references visible from the
left edge of alternatives. ANTLR will re-analyze the decision with a
fixed lookahead of k=1. Consider using "options {k=1;}" for that
decision and adding a syntactic predicate.
trying decision 3 again with k=1
java.g:45:15: Decision can match input such as "LT" using multiple
alternatives: 1, 2
By looking at the grammar, I quickly realized the problem and added
the option to force lookahead to k=1 for two reasons: there is no way
to find lookahead beyond that to help resolve this nondeterministism
and ANTLR does the right thing anyway. After running as follows:
type
: Identifier (options {k=1;}: typeArguments)?
(DOT Identifier (options {k=1;}: typeArguments)? )* (LBRACK RBRACK)*
| basicType
;
I get the simpler:
java.g:45:15: Decision can match input such as "LT" using multiple
alternatives: 1, 2
still, these errors are annoying. I have a plan to allow these errors
to be turned off by specifying a magic cookie as provided by ANTLR;
and it would give you a warning again if you change the lookahead
decision.
For now, i am wondering if we could figure out way to prevent ANTLR
from going crazy on these decisions. it tried to create a DFA for the
FOLLOW(type), which is huge. :( Hmm....
Ter
More information about the antlr-interest
mailing list