Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[mec.gnu@mindspring.com (Michael Elizabeth Chastain)]

mec> gdb/826: variables in C++ namespaces have to be enclosed in quotes
mec> 
mec> When referring to a variable in C++ code that is inside a
mec> namespace, you have to put it inside single quotes.

dc> This is only true in rare circumstances, and it was always true in
dc> versions before 6.1!  So whatever it might be, it's not a regression.
dc> (Hmm: I should probably close that bug report, since it should largely
dc> be fixed by now.)

This test case works with gdb 6.0 and it does not work with gdb gdb-6_1-branch.

  # gdb 6.0, gcc 3.3.3, -gstabs+
  (gdb) print (ClassWithEnum::PrivEnum) 42
  $26 = yellow
  PASS: gdb.cp/classes.exp: print (ClassWithEnum::PrivEnum) 42

  # gdb gdb-6_1-branch, gcc 3.3.3, -gstabs+
  (gdb) print (ClassWithEnum::PrivEnum) 42
  A syntax error in expression, near `42'.
  KFAIL: gdb.cp/classes.exp: print (ClassWithEnum::PrivEnum) 42 (PRMS: gdb/826)

Actually, the word 'variable' is funny, because ClassWithEnum::PrivEnum
is a type, not a variable.  But that's what the test script calls this
problem.  And it's definitely a regression.

mec> gdb/931: GDB could be more generous when reading types C++
mec> templates on input
mec> 
mec> When the user types a template, GDB frequently requires the type to be
mec> typed in a certain way (e.g. "const char*" as opposed to "const char *"
mec> or "char const *" or "char const*").

dc> This also has always been the case.  It is the case that GDB's
dc> preferred form has, in some circumstances changed from 6.0 to 6.1, but
dc> GDB has always had a preferred form.

Yes, I know.  If a user has a gdb script which pre-sets a lot of
breakpoints with "break 'Foo<volatile char*>::foo", they have to change
their script with each release of gdb.  That's why I consider this a
regression, because it breaks user scripts.  The regression in the
test scripts is just an indicator that user scripts will break too.
But it was worth some more text here.

mec> gdb/1512: no canonical way to output names of C++ types
mec> 
mec> We currently don't have any canonical way to output names of C++ types.
mec> E.g. "const char *" versus "char const *"; more subtleties aries when
mec> dealing with templates.

dc> Again, this has always been the case - this isn't a regression.

This is more subtle.  gdb has scripted input, but how many people have
scripted output for gdb?

That is, when gdb changes its output from this:

  (gdb) ptype fvpchar
  type = class Foo<volatile char *> {

to this:

  (gdb) ptype fvpchar
  type = class Foo<char volatile *> {

Is that going to break a contract we have with the users?  Are there any
users that are going to be affected, such as front ends that are parsing
or gdb's output?

I'm inclined to say "yes", because we do consider the second form
a KFAIL.  If both output forms are okay then I think the test script
should test them both.  But I'm more flexible on this than I am on
*input* form, where anything that used to be accepted in 6.0 and
is no longer accepted in 6.1 is likely to break a user script.

Michael C