Re: why does dump_decl dump the scope of a FIELD_DECL?

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

"Giovanni Bajo" <giovannibajo@libero.it> writes:

| Hello Gaby,

Hi Giovanni,

  I'm not the person who decided that dump_decl should print the
membership of a data member (or a member function).  Like you I find
it awful in diagnostic messages.  But sometimes, it can be useful --
my  experience is that those occasions are rare.

  In the new pretty-printer, the membership is not printed by default.
At some point I added a flag to control that scope information (it is
needed in some cases), but while fixing something completely
unrelated, Mark decided to get rid of that flag.

| dump_decl currently prints the scope of a FIELD_DECL, which makes it appear
| like "int A::x" for things like:
| 
| struct A
| {
|     int x;
| };
| 
| It looks pretty goofy to me because if we dump the *field* name we probably
| don't want the class name as well. 

Yes and no.  It really depends on context (which the old errors.c does
not have).  If you're printing a declaration at class scope, you most
certainly don't   want to print the membership.  However, when you're
using that member in a context where there could be many members of
that name (e.g. multiple-inheritance) you probably want to  make
precise which path is used.  Similarly, if you have a virtual call,
you don't want to print the membership, most of the time.

| For instance:
| 
| struct A
| {
|   A();
|   int A;
| };
| error: field `int A::A' with same name as class
| 
| which is confusing. Is there a reason for this which I'm missing? Otherwise,
| does something like this patch, which is sitting in my tree but currently
| untested, makes sense to you?

See the reasons I gave above.  Hopefull, when the new pretty-printer
replaces the old ones, we will have more control instead of the
all-or-nothing we currently do.  I suppose that in meantime, you patch
is OK.

-- Gaby