[antlr-interest] Possible bug in Java grammar (all versions)?

Jim O'Connor Jim.O'Connor at microfocus.com
Wed Mar 2 06:47:33 PST 2005


Hi Bill,
  It's a known problem, but I'm not sure there is an "official" solution.
Jim

On Nov 24, 2004, at 6:24 AM, Jim O'Connor wrote:

> The if condition fails with "_t" holding the SUPER_CTOR_CALL value.
> The SUPER_CTOR_CALL is in the following rule tree, and only in this 
> rule tree.  

> stat: typeDefinition
>
>       |     variableDef
>
>       |     expression
>
> ....... others
>       ;
>
>
> Expression   //Offending parent???? EXPR
>
>       :     #(EXPR expr)
>
>       ;
>
>  
>
> expr: #(QUESTION expr expr expr)    // trinary operator
>
>  
>
> ....... others
>
>       |     primaryExpression
>
>       ;
>
> primaryExpression
>
>     :   IDENT
>
> ....... others
>
>       |     ctorCall
>
> ....... others
>       ;
>
>
> ctorCall
>
>       :     #( CTOR_CALL elist )
>
>       |     #( SUPER_CTOR_CALL
>
>                   (     elist
>
>                   |     primaryExpression elist
>
>                   )
>
>              )
>
>       ;
>
>
> It appears that the SUPER_CTOR_CALL is in the stat list but shoved
> down below the #(EXPR expr) tree.  There are comments about 
> ambiguities.  I don't want to insert the ctorCall into a spot that 
> would cause more problems.  Should I concentrate on java.g or 
> java.tree.g?

//Monty's comments, 
I'm not totally sure what the author's intent was, but the simplest 
solution seems to be to wrap the ctors into a #(EXPR parent)

explicitConstructorInvocation

    :   ( "this"! lp1:LPAREN^ argList RPAREN! SEMI!

            {#lp1.setType(CTOR_CALL);}

    |   "super"! lp2:LPAREN^ argList RPAREN! SEMI!

            {#lp2.setType(SUPER_CTOR_CALL);}
	)
	{ ##=#(#[EXPR],##);}
    ;

 
Monty



> -----Original Message-----
> From: William Bland [mailto:wjb at abstractnonsense.com]
> Sent: Tuesday, March 01, 2005 8:33 PM
> To: antlr-interest at antlr.org
> Subject: [antlr-interest] Possible bug in Java grammar (all versions)?
> 
> Unless I'm doing something particularly stupid (wouldn't be the first
> time!), the following code seems to tickle a bug in the ANTLR parser
> generated from every Java grammar that I could find:
> 
> === Begin Java code ===
> package com.foo;
> 
> public class Example {
>     public Example() {
>         super();
>         System.out.println("ANTLR will not descend to this node in the
> AST, unless the above call to super is commented out!");
>     }
> }
> === End Java code ===
> 
> I added logging calls to each method in the generated
> JavaTreeParser.java so I could see what was happening.  With the above
> code, the parser appeared to fail to descend to the System.out.println
> node of the AST - it only did so if I removed, or commented-out the call
> to super().
> 
> Am I misunderstanding something, or is this a bug?  I tried using the
> Java1.3, Java1.4 and both Java1.5 grammars from the ANTLR website, and I
> am using ANTLR version 2.7.5.
> 
> Thanks for your help.
> Best wishes,
> 		Bill.
> --
> It turns out that while it's easy to undo technical mistakes, it's not
> as easy to undo personality disorders.        (Linus Torvalds)
> 
> 
> 
> This message has been scanned for viruses by MailController -
> www.MailController.altohiway.com


More information about the antlr-interest mailing list