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

PR 45329 is a problem with GCC's overload resolution diagnostics.  For
the testcase:

struct S
{
 int x;
 int y;
};

int foo(int x, int y)
{
 return x+y;
}

int foo(const S &s)
{
 return s.x + s.y;
}

int foo2(int x)
{
 foo(x);
}

gcc prints:

./tst.cc: In function ‘int foo2(int)’:
./tst.cc:19:8: error: no matching function for call to ‘foo(int&)’
./tst.cc:7:5: note: candidates are: int foo(int, int)
./tst.cc:12:5: note:                 int foo(const S&)

and the bug reporter indicates it would be helpful if GCC provided some
information about why the candidate functions did not match.

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.

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

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.  */
  else if (parmlist
	   && ((flags & LOOKUP_SPECULATIVE)
	       || (current_function_decl
		   && DECL_DEFAULTED_FN (current_function_decl))))
    {
      if (DECL_CONSTRUCTOR_P (fn))
	i = 1;
      else if (DECL_ASSIGNMENT_OPERATOR_P (fn)
	       && DECL_OVERLOADED_OPERATOR_P (fn) == NOP_EXPR)
	i = 2;
      else
	i = 0;
      if (i && len == i)
	{
	  parmnode = chain_index (i-1, parmlist);
	  if (!reference_related_p (non_reference (TREE_VALUE (parmnode)),
				    ctype))
	    viable = 0;
	}

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.

Part of the reason for asking for comments here is that moving the
diagnostics around as above will require the modification of a bajillion
testcases; before I embark on that, I'd like comments on the approach
and whether the formatting seems reasonable.  I moved the formatting
around because leaving the formatting as before resulted in:

pr45329.C: In function 'int foo2(int)':
pr45329.C:26:7: error: no matching function for call to 'foo(int&)'
pr45329.C:7:5: note: candidates are: int foo(int, int)
pr45329.C:7:5: note: candidates are: 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 IMHO takes up a lot of space for little gain.  I suppose one
obvious improvement to the proposed format might be something like:

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:note: candidate expects 2 arguments, 1 provided
pr45329.C:19:5: note: int foo(const S&)
pr45329.C: note: no known conversion for argument 1 from 'int' to 'const S&'

though I wouldn't be thrilled about dg-message matching that.

I have gone through testlogs from check-g++ and the messages look
reasonable.

Comments?  Concerns?  Ollie, you reported the bug; what do you think
about the changes?

-Nathan

gcc/cp/
	PR c++/45329
	* cp-tree.h (location_at): Declare.
	* error.c (location_at): Export.
	* call.c (struct conversion): Document bad_p field.
	(enum rejection_reason_code): Define.
	(struct rejection_reason): Define.
	(struct z_candidate): Add `reason' field.
	(add_candidate): Add `reason' parameter.  Store it in CAND.
	(alloc_rejection, arity_rejection, arg_conversion_rejection):
	New functions.
	(bad_arg_conversion_rejection): New function.
	(convert_class_to_reference): Add comment.
	(add_function_candidate): Record rejection reason and pass it to
	add_candidate.
	(add_conv_candidate, build_builtin_candidate): Likewise.
	(add_template_candidate_real): Likewise.
	(print_z_candidate): Print CAND->REASON if it exists.  Adjust
	diagnostic strings.
	(print_z_candidates): Adjust calling sequence for print_z_candidate.
	Print header line directly.
	(build_user_type_conversion_1): Add reason for rejection to CAND.

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

Commit Message

Comments

Patch