This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC,c++] fix PR 45329, provide information on overload resolution

On 11/17/2010 03:46 PM, Nathan Froyd wrote:
The patch below addresses this.  At each point where we decide that a
candidate function loses, we record a rejection reason.  When we print
the candidates, we also print out the reasons, if any.  This scheme only
really deals with the "no matching function for" case; I can try to
piece something together for the ambiguous match case, though that will
be a bit harder.

Recently it occurred to me that it would be nice to have an -fdump-overload-resolution flag to print out full information about the overload resolution logic. What do you think of that? I don't suggest that instead of this change, but as another possible improvement.

There are two points at which I have not added rejection reasons.  One
of them--convert_class_to_reference--I have described in a comment.  The
second one is in add_function_candidate:

   /* Kludge: When looking for a function from a subobject while generating
      an implicit copy/move constructor/operator=, don't consider anything
      that takes (a reference to) an unrelated type.  See c++/44909.  */

This should never lead to an error message, so I don't think we need to worry about it. Well, it shouldn't once we re-enable implicit declaration of the copy constructor even with an explicit move constructor.

I am clueless about what a decent reason is. Comments welcome.

For the testcase above, a modified g++ prints:

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

which is a little friendlier.

Yes, but the cc1plus: line should have the source position of the call, and the rejection reason should be indented.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]