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

Jan H. van der Ven jhvdven at xs4all.nl
Thu Nov 17 07:14:36 PST 2005


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
>>>
>>>
>>
>>
>




More information about the antlr-interest mailing list