[antlr-interest] java.g, java.tree.g, and SUPER_CTOR_CALL
Monty Zukowski
monty at codetransform.com
Wed Nov 24 08:18:54 PST 2004
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?
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
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/antlr-interest/
<*> To unsubscribe from this group, send an email to:
antlr-interest-unsubscribe at yahoogroups.com
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
More information about the antlr-interest
mailing list