[antlr-interest] Upgrade a token/AST from inside the parser.

[Martin Probst]

You probably created a loop in your AST somehow. Somewhat is calling
make() with an AST node whose children have a loop. Check your
construction syntax!

Martin

On Thu, 2005-11-17 at 16:14 +0100, Jan H. van der Ven wrote:
> And the race condition is in
> ASTFactory:
>     public AST make(AST[] nodes) {
>         if (nodes == null || nodes.length == 0) return null;
>         AST root = nodes[0];
>         AST tail = null;
>         if (root != null) {
>             root.setFirstChild(null);	// don't leave any old pointers set
>         }
>         // link in children;
>         for (int i = 1; i < nodes.length; i++) {
>             if (nodes[i] == null) continue;	// ignore null nodes
>             if (root == null) {
>                 // Set the root and set it up for a flat list
>                 root = tail = nodes[i];
>             }
>             else if (tail == null) {
>                 root.setFirstChild(nodes[i]);
>                 tail = root.getFirstChild();
>             }
>             else {
>                 tail.setNextSibling(nodes[i]);
>                 tail = tail.getNextSibling();
>             }
> ---->            // Chase tail to last sibling
> ---->            while (tail.getNextSibling() != null) {
> ---->                tail = tail.getNextSibling();
> ---->            }
> // bites its own tail
>         }
>         return root;
>     }
> 
> <quote who="Jan H. van der Ven">
> > Sorry my first response went out to you personally. Luckily the others did
> > not get my newbie response.
> > In the meantime i did some reading and coding and headstomping.
> >
> > My simplified statement parser now sometimes knows when it is dealing with
> > a table or a column but when i have a common construction like select
> > table.column from table my cpu rises to 100% even though my ambiguities on
> > this (there are 2 that I think do not matter) are resolved.
> >
> > I have attached my .g. The trouble is with the dbObject I think.
> >
> > The statement that's giving me headaches is: SELECT a.b from C (see how
> > far I am already ;-)
> >
> > Please advise.
> >
> > <quote who="Peggy Fieland">
> >> I use different token types in the parser, eg
> >>   SQL_E_COLUMN_NAME
> >>   SQL_E_TABLE_NAME
> >> usually in the case of column names, the actual name
> >> is a child of this node:
> >> Here is part of the column_name definition for one of
> >> the databases:
> >>
> >>  o0:schema_name DOT!
> >>             t0:table_name DOT! c0:column_name_ref
> >>             { ## = #([SQL_E_COLUMN_NAME,
> >> "COLUMN_NAME"], #c0, #t0, #o0); }
> >> ...
> >>
> >> --- "Jan H. van der Ven" <jhvdven at xs4all.nl> wrote:
> >>
> >>> Hi,
> >>>
> >>>
> >>> I am currently working on a SQL parser (we want to
> >>> support all databases,
> >>> but I am taking baby steps). I used the MS SQL
> >>> select statement from
> >>> Tomasz Jastrzebski that can be downloaded from
> >>> antlr.org. It checks my
> >>> statements ok, but that is not the only result I am
> >>> looking for.
> >>>
> >>> What I want is that after the parsing the tokens
> >>> contain extra information
> >>> about their syntactic nature. For instance, the
> >>> parser will find out that
> >>> a certain 'identifier' is actually a column and I
> >>> would like that
> >>> knowledge to become part of the token or the AST.
> >>>
> >>> I am new to all of this, so if this is something you
> >>> guys do all day
> >>> please let me know.
> >>>
> >>> If it is not, could you point me in the right
> >>> direction.
> >>>
> >>>
> >>> Kind regards,
> >>>
> >>>
> >>> Jan van der Ven
> >>>
> >>>
> >>
> >>
> >
> 
> 
>