[antlr-interest] Re: Why no children in tree generated by C++ parser?

Maurice van der Pot griffon26 at kfk4ever.com
Sat Oct 16 09:04:04 PDT 2004


On Mon, Oct 11, 2004 at 12:05:52PM +0100, David Wigg wrote:
> 
> I was glad to hear that you have been able to run it 
> successfully. However, if you find any problems with it please 
> let me know.

I am planning to make a relatively simple program that checks 
the exception specifications and exception handlers in a C++ file
to see if any unexpected exceptions can be raised.

I found that the grammar only allows max 2 exceptions in an exception 
specification. The trivial patch:

--- CPP_parser.g.original       2004-10-16 17:44:54.005621592 +0200
+++ CPP_parser.g.exceptionspecfix       2004-10-16 17:45:56.829070976 +0200
@@ -1328,7 +1328,7 @@
        {char *so;}
        :       "throw" 
                LPAREN 
-               (       (so = scope_override ID (COMMA so = scope_override ID)? )? 
+               (       (so = scope_override ID (COMMA so = scope_override ID)* )? 
                |       ELLIPSIS
                )
                RPAREN

At first I thought I would add only tree construction to the grammar
so I could later parse the tree to check for properties. Later I 
realised that there are several variables (functionDefinition, 
in_parameter_list, enclosingClass, etc) that are specifically meant 
to help the programmer do something useful within functions that 
are called while parsing the source file (the virtual member functions 
of the parser class).

I'm not sure what would be the best approach. I have the feeling that
the number of variables required to do any and all kinds of checking 
will be too large. Maybe it is better to not have any of those variables 
in the source parser and put them in the application specific tree parser
instead.

> I would very much like to offer tree parser output, but I do not 
> have sufficient spare time at present. If anyone would like to 
> co-operate with me to modify the parser to produce a suitable 
> AST from this parser then I would be pleased to help.

Do you have a specific structure in mind? I am going to spend some
time on this anyway, so I may as well try to make a structure that 
is useful for more people than just yours truly.

Best regards,
Maurice.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://www.antlr.org/pipermail/antlr-interest/attachments/20041016/4e6733cd/attachment.bin


More information about the antlr-interest mailing list