how canonical are template names?

[David Carlton <carlton@math.stanford.edu>]

I'm testing a patch on my branch that tries to figure out when a class
lives inside a namespace by looking at the demangled names of the
methods of the classes.

When I tested the patch, I saw some regressions in
gdb.c++/templates.exp.  But, on looking at the situation further, I'm
not sure that they qualify as regressions.  Basically, there are
different ways to write the same types; it turns out that G++'s debug
info and the demangler choose different ways in some circumstances.

In an ideal world, maybe GDB would always print types in one canonical
way and allow users as much flexibility as possible in how they input
types.  But, for now, it seems quite reasonable to allow GDB to print
types however it wishes and to require users to input types the same
way that GDB outputs them in some circumstances.  Usually, users can
figure out what name GDB thinks a templated class has by calling
'ptype' on a variable of the appropriate type.

Here's the differences in question, taken from gdb.logs in testsuite
runs.  I'll show the differences test by test, marking the current
output with "* Current:" my new output with "* Branch:", and my
discussion of differences with "* Discussion:".

* Current:

ptype fvpchar
type = class Foo<volatile char*> {
  public:
    int x;
    volatile char *t;

    volatile char * foo(int, char volatile*);
}
(gdb) PASS: gdb.c++/templates.exp: ptype fvpchar

* Branch:

ptype fvpchar
type = class Foo<char volatile*> {
  public:
    int x;
    volatile char *t;

    volatile char * foo(int, char volatile*);
}
(gdb) FAIL: gdb.c++/templates.exp: ptype fvpchar

* Discussion:

Here, the new output switches the 'char' and 'volatile'.  It's still
the same type.


* Current:

print Foo<volatile char *>::foo
No symbol "Foo<volatile char *>" in current context.
(gdb) FAIL: gdb.c++/templates.exp: print Foo<volatile char *>::foo

* Branch:

print Foo<volatile char *>::foo
$4 = {volatile char *(Foo<volatile char*> * const, int, volatile char *)} 0x80493be <Foo<char volatile*>::foo(int, char volatile*)>
(gdb) FAIL: gdb.c++/templates.exp: print Foo<volatile char *>::foo

* Discussion:

I have no idea what bizarre interaction between the parser and
templates is causing the new version to print something useful in this
situation even though the current version doesn't.  (For what it's
worth, the current version does print something useful if you omit the
space in 'char *'.)


* Current:

ptype Bar
type = class Bar<int,33> {
  public:
    int x;
    int t;

    int bar(int, int);
}
(gdb) XFAIL: gdb.c++/templates.exp: ptype Bar

* Branch:

ptype Bar
type = class Bar<int, 33> {
  public:
    int x;
    int t;

    int bar(int, int);
}
(gdb) XFAIL: gdb.c++/templates.exp: ptype Bar

* Discussion:

Here, the new output puts spaces between template arguments.  (I have
no idea what's up with the XFAIL: I haven't looked into that yet.)
There are a few more examples that differ only by spaces (some of
which turn PASS into FAIL rather than maintaining an XFAIL); I'll skip
them.


* Current:

ptype Baz
type = class Baz<int,'s'> {
  public:
    int x;
    int t;

    int baz(int, int);
}
(gdb) XFAIL: gdb.c++/templates.exp: ptype Baz

* Branch:

ptype Baz
type = class Baz<int, 115> {
  public:
    int x;
    int t;

    int baz(int, int);
}
(gdb) XFAIL: gdb.c++/templates.exp: ptype Baz

* Discussion:

Here, not only is there an extra space, but the character constant is
printed using its numerical value.  There are a few more examples like
this.


* Current:

ptype Qux
type = class Qux<char,&string> {
  public:
    int x;
    char t;

    char qux(int, char);
}
(gdb) XFAIL: gdb.c++/templates.exp: ptype Qux

* Branch:

ptype Qux
type = class Qux<char, &(string)> {
  public:
    int x;
    char t;

    char qux(int, char);
}
(gdb) XFAIL: gdb.c++/templates.exp: ptype Qux

* Discussion:

Besides the space difference, there are parens around 'string'.  There
are more examples like this, too.


Those are the differences that the testsuite reveals.  Any opinions as
to which of these should be considered serious, if any?  I'm leaning
towards not worrying about any of them, but filing a low-priority PR
about it just to get it into the database.  (The main reason for the
latter is because it would be nice if input were a bit more flexible;
I don't care so much about variations in GDB's output.)

David Carlton
carlton@math.stanford.edu