[GCC-XML]Producing "_0" ids when parsing <string>

[Brad King]

>   We have a problem when parsing std::basic_string<> class. The latest
> version 0.4.2 generates much more elements with id's "_0", which are not
> resolved. For example, the return type of basic_string::substr() is not
> set correctly to what it is in the header file, which is basic_string.
> Is there an explanation for these "_0"? Is any any to avoid them? To
> reproduce easily the problem I just parsed <string> with the following
> commands.

This has come up before, and I can reproduce it.  Here is the full XML
element corresponding to the "substr" to which you refer:

  <Method id="_982" name="substr" returns="_0" const="1" context="_0" location="f2:819">
    <Argument name="__pos" type="_847" default="0"/>
    <Argument name="__n" type="_847" default="std::basic_string<_CharT, _Traits, _Alloc>::npos"/>
  </Method>

Note that the argument type of __n is "std::basic_string<_CharT,...>",
which is not an instantiated template.  Something in GCC's internal parser
is creating nodes that correspond to class templates but not to their
instantiations.  I have not had time to track down the real problem, but
any element that references _0 can be safely ignored.

If you want to get a dump of basic_string, you may use this input file:

// input.cxx
#include <string>
typedef std::string::basic_string stdstring;

Then run gccxml like this:

./gccxml input.cxx -fxml=output.xml -fxml-start=stdstring

GCC-XML does not dump uninstantiated templates (currently).  The above
input file will instantiate the basic_string corresponding to std::string
because it accesses a member of the class with "::".  Since the member it
accesses is basic_string, the typedef of "stdstring" points back at the
exact class template instantiation you want to see.  Then you can specify
-fxml-start=stdstring to get a dump of that exact class and the stuff it
needs, but nothing else.

-Brad