[antlr-interest] java.g, java.tree.g, and SUPER_CTOR_CALL

Jim O'Connor Jim.OConnor at microfocus.com
Wed Nov 24 06:24:04 PST 2004


Hi All,
  I'm having a difficulty with the java grammars and it's handling of
"super()" in a constructor.  Sorry if this has been addressed elsewhere.
 
Example:
 
public class AB {
      public AB() {
            super();
      ABC abc = new ABC();
            abc.toString();
            abc.myABC();
      }
}
 
The java.g file has the following code:
 
constructorBody
    :   lc:LCURLY^ {#lc.setType(SLIST);}
            ( options { greedy=true; } : explicitConstructorInvocation)?
            (statement)*
        RCURLY!
    ;
/** Catch obvious constructor calls, but not the expr.super(...) calls */
explicitConstructorInvocation
    :   "this"! lp1:LPAREN^ argList RPAREN! SEMI!
            {#lp1.setType(CTOR_CALL);}
    |   "super"! lp2:LPAREN^ argList RPAREN! SEMI!
            {#lp2.setType(SUPER_CTOR_CALL);}
    ;
 
This is appears to construct a good tree with the SUPER_CTOR_CALL as a child
of the SLIST parent.
 
The problem shows itself in the tree grammar.  The condensed generated code
is below.
 
 
      public final void slist(AST _t) throws RecognitionException {
            match(_t,SLIST);
            _t = _t.getFirstChild();
            {
            _loop20035:
            do {
                  if ((_tokenSet_1.member(_t.getType()))) {
                        stat(_t);
                        _t = _retTree;
                  }
                  else 
                        break _loop20035;
            } while (true);
      }
 
 
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 using the 1.3 java.g but the 1.5 java.g appears to have the same
construct.
 
 
 
The tree grammar runs "successfully?".  It ignores the input and moves on.
 
 
 
 
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/antlr-interest/attachments/20041124/6a201434/attachment.html


More information about the antlr-interest mailing list