[antlr-interest] Bug in Java grammar 1.3
Marco Hunsicker
development at hunsicker.de
Fri May 31 04:33:06 PDT 2002
Hi all,
the latest java.g (1.18) fails to parse code like
if (file.getClass() == (byte.class))
the problem being rule "unaryExpressionNotPlusMinus" which expects a
type cast after it matched "(byte" and fails because a "." (DOT)
follows.
// If typecast is built in type, must be numeric operand
// Also, no reason to backtrack if type keyword
like int, float...
lpb:LPAREN^ {#lpb.setType(TYPECAST);}
builtInTypeSpec[true] RPAREN!
unaryExpression
I fixed it by myself (using syntactic predicating) but having literally
no experience with ANTLR grammars (grammars at all...), I wonder if
there is a better way to deal with such a case. I've attached the
patch. Any comments highly appreciated.
Many thanks.
Marco
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
-------------- next part --------------
unaryExpressionNotPlusMinus
: BNOT^ unaryExpression
| LNOT^ unaryExpression
| ( // subrule allows option to shut off warnings
options {
// "(int" ambig with postfixExpr due to lack of sequence
// info in linear approximate LL(k). It's ok. Shut up.
generateAmbigWarnings=false;
}
: // If typecast is built in type, must be numeric operand
// Also, no reason to backtrack if type keyword like int, float...
lpb:LPAREN^
(builtInTypeSpec[false] DOT)=>
identifier
| {#lpb.setType(JavaTokenTypes.TYPECAST);} builtInTypeSpec[true]
RPAREN! unaryExpression
// Have to backtrack to see if operator follows. If no operator
// follows, it's a typecast. No semantic checking needed to parse.
// if it _looks_ like a cast, it _is_ a cast; else it's a "(expr)"
| (LPAREN classTypeSpec[true] RPAREN unaryExpressionNotPlusMinus)=>
lp:LPAREN^ {#lp.setType(JavaTokenTypes.TYPECAST);} classTypeSpec[true] RPAREN!
unaryExpressionNotPlusMinus
| postfixExpression
)
;
More information about the antlr-interest
mailing list