[GCC-XML]Re-write prototype in CVS
Brad King
brad.king at kitware.com
Thu Mar 14 10:48:32 EST 2002
Dave,
> > that the starting name is surprisingly easy to use. Most of the time,
> > people are interested in dumping header files.
>
> I'm one of those people. It seems obvious to say "start at line 1 of
> foo.hpp".
Okay, I misunderstood what you meant. The idea of a "start location" with
-fxml-start is to specify a certain entity in the C++ program. Anything
to which that entity refers will also be dumped (and anything to which
those things refer, etc). I thought you were saying that gcc-xml should
find a specific single declaration that exists on that line, and start the
subgraph walk from there.
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.
> Does g++ refuse to compile a file if it has an .hpp extension?
[snip]
> Are you telling me that GCC will refuse to compile a .hpp file based
> on its extension?
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.
> 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.
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>
-Brad
More information about the gccxml
mailing list