[Bug c++/53822] spell out typedefs in ambiguous call

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53822

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug c++/53822] spell out typedefs in ambiguous call

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53822

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed|2013-04-16 00:00:00 |2021-8-9

--- Comment #8 from Andrew Pinski  ---
clang does not even print out the argument type :).
NOTE that is actually worse.
ICC and MSVC both print out the typedef name.

[Bug c++/53822] spell out typedefs in ambiguous call

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53822

--- Comment #7 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Marc Glisse from comment #6)
 Probably depends on cases. Sometimes it is good to have the explanation
 right next to the type, other times it takes up all the space and you can't
 even find the commas separating the arguments anymore (maybe if the whole
 {aka ...} block was a different color?).

That could be possible. On the other hand, the {aka ...} thing is not really
ideal (in general). Currently,

1) It is not translated
2) You need to know what aka means (not obvious relation with 'typedef')
3) It is not correctly quoted, that is, instead of `NT {aka int}', we should
print `NT' {aka `int'}.
4) The aka should not be colored in the same way as the types. Fixing the
quoting will fix this.
5) Complex declarations lead to many repetitions of aka: `f(NT {aka int},UT
{aka unsigned int},DT {aka double int})'.

[Bug c++/53822] spell out typedefs in ambiguous call

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53822

--- Comment #4 from Marc Glisse glisse at gcc dot gnu.org ---
Created attachment 31564
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31564action=edit
patch

(mostly untested)

This changes the message to:
error: call of overloaded 'f(NT)' {aka 'f(unsigned int)'} is ambiguous

As far as I can tell, %#A is unused, so it seems ok to hijack it.

It isn't very nice because without typedefs it will repeat the same thing
twice, but printing [with NT=unsigned int] seems more complicated to me.

Then maybe the example is not that well chosen, because in the more interesting
cases NT depends on template parameters, and that may make [with ...] easier to
implement (or not).

[Bug c++/53822] spell out typedefs in ambiguous call

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53822

--- Comment #5 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Marc Glisse from comment #4)
 Created attachment 31564 [details]
 patch
 
 (mostly untested)
 
 This changes the message to:
 error: call of overloaded 'f(NT)' {aka 'f(unsigned int)'} is ambiguous
 
 As far as I can tell, %#A is unused, so it seems ok to hijack it.
 
 It isn't very nice because without typedefs it will repeat the same thing
 twice, but printing [with NT=unsigned int] seems more complicated to me.

There is code in error.c:type_to_string to print {aka . It does some tricks
to avoid printing aka when there are no typedefs. Perhaps args_to_string()
should call type_to_string() instead of calling dump_type directly. With that,
it prints:


test.cc:6:6: error: call of overloaded ‘f(NT {aka unsigned int})’ is
ambiguous

I am not sure if that is clearer or not. But it avoids the repetition.

[Bug c++/53822] spell out typedefs in ambiguous call

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53822

--- Comment #6 from Marc Glisse glisse at gcc dot gnu.org ---
(In reply to Manuel López-Ibáñez from comment #5)
 (In reply to Marc Glisse from comment #4)
 There is code in error.c:type_to_string to print {aka . It does some
 tricks to avoid printing aka when there are no typedefs. Perhaps
 args_to_string() should call type_to_string() instead of calling dump_type
 directly. With that, it prints:
 
 test.cc:6:6: error: call of overloaded ‘f(NT {aka unsigned int})’ is
 ambiguous

Nice!

 I am not sure if that is clearer or not.

Probably depends on cases. Sometimes it is good to have the explanation right
next to the type, other times it takes up all the space and you can't even find
the commas separating the arguments anymore (maybe if the whole {aka ...} block
was a different color?).