[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