This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC,c++] fix PR 45329, provide information on overload resolution
- From: Jason Merrill <jason at redhat dot com>
- To: Nathan Froyd <froydnj at codesourcery dot com>
- Cc: gcc-patches at gcc dot gnu dot org, mark at codesourcery dot com, aaw at gcc dot gnu dot org
- Date: Fri, 19 Nov 2010 17:42:30 -0500
- Subject: Re: [RFC,c++] fix PR 45329, provide information on overload resolution
- Newsgroups: gmane.comp.gcc.patches
- References: <20101117204631.GE24469@nightcrawler>
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.
Jason