From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5911 invoked by alias); 23 Nov 2011 16:30:57 -0000 Received: (qmail 5901 invoked by uid 22791); 23 Nov 2011 16:30:54 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 23 Nov 2011 16:30:38 +0000 From: "zeratul976 at hotmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/51277] Feature request: C++ diagnostic for ambiguous overloads Date: Wed, 23 Nov 2011 16:43:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: zeratul976 at hotmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2011-11/txt/msg02331.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51277 --- Comment #2 from Nathan Ridge 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>" ? 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!