[GCC-XML]Re-write prototype in CVS

David Abrahams david.abrahams at rcn.com
Thu Mar 14 11:10:43 EST 2002


----- Original Message -----
From: "Brad King" <brad.king at kitware.com>

> Unfortunately, by the time the gcc-xml extension is invoked, the
> translation unit parsing is done.  The internal representation no
longer
> has a direct notion of the order of input code.  All the dump has to
start
> with is a parse tree node called "global_namespace".  Some of the
chains
> of declarations within this are in reverse order, and some are not
(due to
> the way the parser builds them).  Recognizing what came from a certain
> file would be an unbelievable pain to implement.  Perhaps it could be
> done, but my funding source doesn't need it.

Let's see if I understand. The problem is that it would have to
potentially search through the entire tree for elements labelled with
that file, because the links in the data structure doesn't corresponds
to the order in which source was read?

If so, that /does/ sound like it would make problems.

> If you invoke GCC through its "gcc" front-end, it won't decide to run
the
> cc1plus program unless it recognizes a C++ extension.  When I first
wrote
> gcc-xml two summers ago, I still used the front-end.  Now that gcc-xml
is
> an executable based on running cc1plus directly, this is no longer a
> problem.  I just never realized that until now.

Cool.

> > Arf. Are you telling me that it doesn't dump uninstantiated
templates?
>
> Currently, that is correct.  However, there is a spot in the code that
> recognizes an uninstantiated template and purposely ignores it.
Adding
> the output would just be a matter of implementing a few more node
types
> (like template_type_parm).  I'm planning to do this, but it just isn't
> included in the first revision of the re-write in CVS.

Okay; that's absolutely critical for one of my two main applications of
GCC-XML (documentation generation).

> Below is an example of what the output looks like for this code:
>
> template <typename T>
> struct A
> {
>   typedef T Type;
>   void f(T);
> };
>
> if I remove the code that ignores uninstantiated templates.  The
program
> attempts to dump a RECORD_TYPE that is the TREE_TYPE of a
TEMPLATE_DECL,
> but encounters node types that are unimplemented.
>
> <?xml version="1.0"?>
> <GCC_XML>
>   <Namespace id="_1" name="::" members=""/>
>   <Struct id="_2" name="A<T>" context="_1" location="f0:3"
members="_4 _5 " bases=""/>
>   <Unimplemented id="_3" tree_code="183"
tree_code_name="template_type_parm" node="0x4014a000"/>
>   <Typedef id="_4" name="Type" type="_3" context="_2"
location="f0:4"/>
>   <Method id="_5" name="f" returns="_6" context="_2" location="f0:5"
extern="1">
>     <Argument type="_3"/>
>   </Method>
>   <FundamentalType id="_6" name="void"/>
>   <File id="f0" name="template_example.cxx"/>
> </GCC_XML>

Looks as though you're tantalizingly close... ;-D

-Dave




More information about the gccxml mailing list