public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "zeratul976 at hotmail dot com" <gcc-bugzilla@gcc.gnu.org> 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 [thread overview] Message-ID: <bug-51277-4-dKlUn7lw5r@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-51277-4@http.gcc.gnu.org/bugzilla/> 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!
prev parent reply other threads:[~2011-11-23 16:30 UTC|newest] Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-11-23 1:51 [Bug c++/51277] New: " zeratul976 at hotmail dot com 2011-11-23 12:34 ` [Bug c++/51277] " redi at gcc dot gnu.org 2011-11-23 16:43 ` zeratul976 at hotmail dot com [this message]
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-51277-4-dKlUn7lw5r@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).