[Bug c++/51277] Feature request: C++ diagnostic for ambiguous overloads

["zeratul976 at hotmail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #2 from Nathan Ridge <zeratul976 at hotmail dot com> 2011-11-23 16:30:35 UTC ---
(In reply to comment #1)
> (In reply to comment #0)
> >  - in the first case, the location of the using-declaration or using-
> >    directive (if there are several, any one of them should suffice)
> 
> 
> 
> > // What I would like to see
> > test.cpp: In function 'int main()':
> > test.cpp:12:9: error: call of overloaded 'foo(int)' is ambiguous
> > test.cpp:12:9: note: candidates are:
> > test.cpp:3:10: note: void n1::foo(double)
> > test.cpp:6:13: note: visible in global namespace because of using-declaration
> > located here
> 
> Should 'global namespace' refer to the scope containing the using-declaration
> or the scope containing the ambiguous call? (They're both the global namespace
> in your example, but don't have to be.)
> A using-directive can also appear at block scope and a using-declaration can
> also appear at block scope and class scope, so the note would have to be able
> to decide between printing "global namespace" vs "namespace X" vs "current
> scope" vs ...?
> A using-declaration /declares/ the name in that scope as a synonym for the
> other entity, it doesn't just make it visible.  A using-directive just makes
> the names visible.
> To keep the diagnostics simpler maybe the note could just say:
>   test.cpp:6:13: note: found due to using-declaration here
> or
>   test.cpp:6:13: note: found due to using-directive here
> I think that still conveys enough information, without having to worry about
> whether it's at namespace scope (and global vs named vs unnamed) or block scope
> or class scope.

That would be fine. The key is that the compiler give me the line number where
the using declaration/directive is found. (More often than not, the using
declaration/directive shouldn't be there, and getting rid of it, or moving it
to an appropriate inner scope, resolves the ambiguity, but tracking down a
using declaration in a large codebase where a namespace can span hundreds or
thousands of files is a huge pain...)

> > // What I would like to see
> > test.cpp: In function 'int main()':
> > test.cpp:12:20: error: call of overloaded 'foo(int, n1::Bar)' is ambiguous
> > test.cpp:12:20: note: candidates are:
> > test.cpp:8:6: note: void foo(float, n1::Bar)
> > test.cpp:5:10: note: void n1::foo(double, n1::Bar)
> > test.cpp:3:14: note: found by argument-dependent lookup because second argument
> > is of type n1::Bar
> 
> Printing "argument 2" is easier than "second argument" (or the diagnostic
> machinery needs to be able to print ordinal numbers for any value in any
> language!)

You're absolutely right, my bad.

> Would that note still be useful if it said "is of type X<Y<n1::Bar>>" ?

Yes. The key here is to see the relationship between the argument type and the
associated namespace.

> What about if it said "is of type Derived" where that type has n1::Bar as an
> indirect base class?

By the above argument, no. The error should explain why n1 is an associated
namespace - in this case by mentioning that n1::Bar is a(n indirect) base class
of the argument type.

> Would it help to add "so n1 is an associated namespace" or would that make it
> too long?
> test.cpp:3:14: note: found by argument-dependent lookup because 'n1' is an
> associated namespace of argument 2 of type 'n1::Bar'

That looks fine, but again, in cases where the relationship is not obvious,
(e.g. because the name of the associated namespace does not appear anywhere in
the name of the argument type), a note that makes the relationship clear would
be helpful.

> > Does this sound doable?
> 
> I have no idea :)

I'm not familiar with GCC internals, but it seems to me that this is all
information the compiler should already have at overload resolution time... it
just needs to share it with us!