[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