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

Wolfgang Bangerth <bangerth at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bangerth at gmail dot com

--- Comment #1 from Wolfgang Bangerth <bangerth at gmail dot com> 2010-11-17 
23:00:20 UTC ---
I think the patch that has just been posted is awesome. My favorite reasons for
functions not matching is if you pass a const object to a non-const reference
or if there is only a non-const member function that you try to call on a const
object. In either case, assuming that a sufficient number of arguments are
involved and if they are all templates of the kind std::vector<std::vector<T>>
(with all the defaulted template arguments) it becomes essentially impossible
to see easily why the call failed.

May I make a suggestion regarding the proposed format of the error
message/note: the candidate list is currently already indented to align
candidates. Would it be possible to indent the reason why the candidate failed
*relative to the candidate*? For example something of the kind:

1 pr45329.C:26:7: error: no matching function for call to 'foo(int&)'
2 cc1plus: note: candidates are:
3 pr45329.C:7:5: note: int foo(int, int)
4 pr45329.C:7:5:       candidate expects 2 arguments, 1 provided
5 pr45329.C:19:5: note: int foo(const S&)
6 pr45329.C:19:5:       no known conversion for argument 1 from 'int' to 'const
S&'

(note the lack of the "note" text on lines 4,6 relative to the patch you
posted), or

1 pr45329.C:26:7: error: no matching function for call to 'foo(int&)'
2 cc1plus: note: candidates are:
3 pr45329.C:7:5:    int foo(int, int)
4 pr45329.C:7:5:       reason: candidate expects 2 arguments, 1 provided
5 pr45329.C:19:5:   int foo(const S&)
6 pr45329.C:19:5:      reason: no known conversion for argument 1 from 'int' to
'const S&'

In either case, it breaks up the long list of candidates one often gets into
self-contained blocks that are easier to parse for the human eye.

Thanks
 W.

Reply via email to