This is the mail archive of the gcc-bugs@gcc.gnu.org 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]

[Bug c++/42356] improve list of candidates and error recovery for ambiguous call


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42356

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-10-22 13:00:32 UTC ---
(In reply to comment #2)
> Well, I see several issues with the diagnostics. 
> 
> 1) The call is not ambiguous, because if it were (only) ambiguous then removing
> the base "baz" would disambiguate. Instead the case without "baz" gets you:
>    s3:~/ootbc/memspec$ g++ foo.cc
>    foo.cc: In function âint main()â:
>    foo.cc:27: error: no matching function for call to âfoo::newNode()â
> That is, a call cannot be both ambiguous and have no matching function.

The call is ambiguous, because the name is found in two different base classes,
see the rules in [class.member.lookup].  Removing one of the bases means the
names are only found from one scope, and so overload resolution can proceed,
which fails because there are no viable functions.

Name lookup happens first, then overload resolution.
In your case the result of name lookup is ambiguous, like this:

struct A {
  void f(int);
};
struct B {
  void f(double);
};
struct C : A, B { };

int main() {
  C c;
  c.f(0);
}

even though A::f(int) is a better match, the call is ambiguous.

Clang's diagnostic refers to viable functions, which is wrong, because finding
viable functions happens as part of overload resolution, which shouldn't even
happen here because name lookup is ambiguous.

> 2) The reported list of overloads include those which have the wrong number of
> arguments.

That's by design. Maybe that's the function you meant to call.  If you call a
function with the wrong number of args you want the compiler to tell you name
lookup found something, but overload resolution failed because the number of
arguments didn't match.

> 3) The diagnostic contains "freeList::newNode(U, V) [with U = U, V = V, T =
> bar]" as the call citation, which makes it look like the local U matches a
> (non-existent in this case) global U and local V matches a global V, the way
> that local T matches global bar. Perhaps it could say something like
> "freeList::newNode(U, V) [with U = ?, V = ?, T = bar]"

That might be an improvement, yes.  That's the only issue I see here.


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