This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/42356] improve list of candidates and error recovery for ambiguous call
- From: "redi at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Sat, 22 Oct 2011 19:43:08 +0000
- Subject: [Bug c++/42356] improve list of candidates and error recovery for ambiguous call
- Auto-submitted: auto-generated
- References: <bug-42356-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42356
--- Comment #13 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-10-22 19:43:08 UTC ---
(In reply to comment #11)
> I wonder why the detailed overload failure that Nathan implemented does not
> trigger here. I would expect to give details of why overload failed.
Name lookup fails due to the ambiguity, so overload resolution never happens.
The detailed overload resolution diagnostics won't be printed if overload
resolution isn't done.
> g++ could also specify which ones are viable candidates, and which ones are not
> even viable, and for the ones not viable, explain why.
There are no viable candidates, because overload resolution is not performed.
Why bother performing overload resolution if the result of name lookup is
ambiguous? How does it help you resolve the ambiguity?
The ambiguity can be resolved by qualifying the name or with a using
declaration, but overload resolution is irrelevant for either of them: you
qualify a *name* and a using declaration names a *name*, not an overload