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

[Mark Mitchell <mark at codesourcery dot com>]

On 11/17/2010 12: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.

I like this.

> I can try to piece something together for the ambiguous match case,
> though that will be a bit harder.

That's going to be very hard in full generality.  But, I think you could
at least print the best cases.  Trying to actually explain which
parameters match which arguments with which level of match is going to
be hard, and incredibly arcane; the bottom line is that only a computer
can actually understand some of the more complex overload rules.

> We don't keep track of multiple rejection reasons.  It would be a 
> trivial modification to do so if people felt that was worthwhile.

Naw.

> /* 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.  */ 

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

I don't grok that either; I hope Nathan can help.

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

I think your output is fine.  Give Jason and Gaby a day or two to
comment, though, before you go whole-hog with the implementation.

> +struct rejection_reason {

I think GNU style is:

  struct rejection_reason
  {
    ...
  };

The overall patch looks pretty sane to me.  If Jason doesn't have
comments, please come back to me and I'll do a complete review.

Thank you,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713