Removing unspecified template parameters from error messages

Removing unspecified template parameters from error messages

[Theodore Papadopoulo]

Hi, since the topic was raised again last week, I tried to give a try 
at allowing gcc not to display the default template parameters when 
the defaults are in usage (ie when the user has not specified the 
argument). I'm not sure how an improvement it will be, but decided it 
was worth to try....

I think I made some progress toward such a goal (even though I'm sure 
that my first trial would need many corrections): I think I now mark 
correctly the arguments that were not specified.

Actually, the biggest problem I encounter is with the diagnostic 
machinery which does not propagate the proper information to the
function that displays a template class type (in this case it might
be just the number of template parameters to display or the args tree).

Solving this with minimal modifications require having a global variable
(this is what I may use to get first results), but this is rather ugly...

Would it be acceptable to replace the curreny flag parameter with sthg
slightly more complicated in all the diagnostic routines: eg a struct 
that conveys the actual flag + some "user data" (eg depending on the 
flag). This seems to be an overkill for one just little added value, 
however it might also be of some use elsewhere. I have not checked 
and do not know the diagnostic well enough yet.

Opinions are very welcome...

	Theo.
 


 --------------------------------------------------------------------
 Theodore Papadopoulo
 Email: Theodore.Papadopoulo@sophia.inria.fr Tel: (33) 04 92 38 76 01
 --------------------------------------------------------------------

Re: Removing unspecified template parameters from error messages

[Gabriel Dos Reis]

Theodore Papadopoulo <Theodore.Papadopoulo@sophia.inria.fr> writes:

| Hi, since the topic was raised again last week, I tried to give a try 
| at allowing gcc not to display the default template parameters when 
| the defaults are in usage (ie when the user has not specified the 
| argument). I'm not sure how an improvement it will be, but decided it 
| was worth to try....
| 
| I think I made some progress toward such a goal (even though I'm sure 
| that my first trial would need many corrections): I think I now mark 
| correctly the arguments that were not specified.
| 
| Actually, the biggest problem I encounter is with the diagnostic 
| machinery which does not propagate the proper information to the
| function that displays a template class type (in this case it might
| be just the number of template parameters to display or the args tree).
| 
| Solving this with minimal modifications require having a global variable
| (this is what I may use to get first results), but this is rather ugly...

Where are you making the changes?  In cp/error.c?  I think
cp/cxx-pretty-print.c is a better place, as it allows for more
information to flow in properly and naturally.

| Would it be acceptable to replace the curreny flag parameter with sthg
| slightly more complicated in all the diagnostic routines: eg a struct 
| that conveys the actual flag + some "user data" (eg depending on the 
| flag). This seems to be an overkill for one just little added value, 
| however it might also be of some use elsewhere. I have not checked 
| and do not know the diagnostic well enough yet.

cxx_pretty_printer has a flag, pp_c_base(pp)->flags, that you can use
to add more meaningful information.  You might want to augment
cxx_pretty_printer itself with such information that cannot fit into
the enumeration. 

-- Gaby

Re: Removing unspecified template parameters from error messages

[Theodore Papadopoulo]

gdr@cs.tamu.edu said:
> Where are you making the changes?  In cp/error.c?

Yes since as far as I can tell it seems that it is the machinery 
within cp/error.c that gets called for diagnostics, not the one in
cp/cxx-pretty-print.c. Am I missing something ?

I saw cp/cxx-pretty-print.c but using gdb found that it was not used 
for emitting diagnostics.

>  I think cp/cxx-pretty-print.c is a better place, as it allows for more
> information to flow in properly and naturally. 

I will look at it during the week-end.... But again, how can I make 
use of cp/cxx-pretty-print.c for diagnostics. There is clearly 
something that I did not understood.

gdr@cs.tamu.edu said:
> cxx_pretty_printer has a flag, pp_c_base(pp)->flags, that you can use
> to add more meaningful information.  You might want to augment
> cxx_pretty_printer itself with such information that cannot fit into
> the enumeration.  

Thank's for the tip...

	Theo.

--------------------------------------------------------------------
Theodore Papadopoulo
Email: Theodore.Papadopoulo@sophia.inria.fr Tel: (33) 04 92 38 76 01
 --------------------------------------------------------------------

Re: Removing unspecified template parameters from error messages

[Gabriel Dos Reis]

Theodore Papadopoulo <Theodore.Papadopoulo@sophia.inria.fr> writes:

| gdr@cs.tamu.edu said:
| > Where are you making the changes?  In cp/error.c?
| 
| Yes since as far as I can tell it seems that it is the machinery 
| within cp/error.c that gets called for diagnostics, not the one in
| cp/cxx-pretty-print.c. Am I missing something ?

At the moment, it is a combination of cp/error.c and
cp/cxx-pretty-print.c (as you can see by grepping for "pp_*").

cp/error.c is scheduled to go away.  Currently, cp/error.c is still
used for the type printing part but if you're looking at the default
template arguments issue, you should really consider enabling
cp/cxx-pretty-print.c to print all types -- not just some of them.

| 
| I saw cp/cxx-pretty-print.c but using gdb found that it was not used 
| for emitting diagnostics.
| 
| >  I think cp/cxx-pretty-print.c is a better place, as it allows for more
| > information to flow in properly and naturally. 
| 
| I will look at it during the week-end.... But again, how can I make 
| use of cp/cxx-pretty-print.c for diagnostics. There is clearly 
| something that I did not understood.

The way I was doing this is to gradually replace dump_type() with
pp_cxx_type_id() and such.  If you want to switch completely, you
modify cp_printer() to call pp_cxx_* instead of the dump_*.  Last time
I tried, I got some regressions in the testsuite -- but they were very
serious. 

-- Gaby