[antlr-interest] Tree parser tree building bug and workaround

[Ric Klaren]

Hi,

On 11/29/06, Monty Zukowski <monty at codetransform.com> wrote:
> On 11/29/06, Micheal J <open.zone at virgin.net> wrote:
> > Hi Monty,
> >
> > > I just found a bug in 2.7.7 (and 2.7.4).  I have a tree
> > > parser rule that builds a tree (just adding a new parent
> > > node), like this:
> > >
> > > rule1:
> > > #( T1 T2 T3
> > >   { ##=#(#[NEWROOT],##); }
> > >   )
> > >   ;
> >
> > Shouldn't that be:
> >
> > Rule1
> >   :  #( T1 T2 T3
> >      )
> >      { ##=#(#[NEWROOT],##); }
> >   ;
> >
> > With the action block following the tree pattern matching specification.
> >
> > > >From inside the action, I see that the tree is built properly.  But
> > > for some reason, upon exit of the rule the AST for rule1 is
> > > replaced by the original.  (You can see it in the generated code).
> >
> > This resonates with my preposition that action block placement might be the
> > issue here.
> >
>
> I suppose that is it, but I don't understand why.  What does it
> matter?  I would expect the root to be built after T1 has been
> matched.  Why can't I manipulate it from inside the #() ?

This is probably an artifact of how the code gets generated for the #(
.. ). After the closing ')' of the #() some code is probably emitted
that borks the ## pointer/reference or something similar. Hmm those
T1..3 are those terminals or subrules in your case? Or I'm missing
something or I made my example .g file to simple.....

Cheers,

Ric