Consider this testcase: ----------------------------------------------------------- namespace A { namespace B { template <typename T> struct N {int n_;}; } template <typename T> int N( T p ) { return p->n_; } template <typename T> void f( T p ) { N(p); } // #1 } int main() { A::B::N<int> n; A::f(&n); return 0; } ----------------------------------------------------------- The expression #1 "N(p)" is interpreted by the parser as a function call because the lookup finds the function A::N. Then, Koenig lookup fires up: the type of "p" is "A::B::N<int>" so the associated namespace is "A::B". There, the lookup finds "A::B::N" which is a template and not a function. GCC emits an error at this point: jeff.cc: In function `void A::f<A::B::N<int> *>(A::B::N<int> *)': jeff.cc:13: instantiated from here jeff.cc:5: `template <class T> A::B::N<T>' is not a function, jeff.cc:7: conflict with `template <class T> A::N(T)' jeff.cc:8: in call to `N' This looks weird. The standard does not have a definitive answer, but this paragraph looks interesting to me: [basic.lookup.unqual]/3 "For purposes of determining (during parsing) whether an expression is a postfix-expression for a function call, the usual name lookup rules apply. The rules in [basic.lookup.koenig] have no effect on the syntactic interpretation of an expression. So, it would be strange if koenig lookup found also non-functions, as it cannot change the interpretation of the expression anyway. This also agrees with what EDG does (consider the code above valid). I think this is a bug in GCC, where we reject the above code but we should not.
Created attachment 7073 [details] Patch This patch fixes the bug, but requires testing. If someone wants to beat me at it...
Subject: Re: New: Should Koenig lookup find non-functions? "giovannibajo at libero dot it" <gcc-bugzilla@gcc.gnu.org> writes: [...] | [basic.lookup.unqual]/3 | "For purposes of determining (during parsing) whether an expression | is a postfix-expression for a function call, the usual name lookup | rules apply. The rules in [basic.lookup.koenig] have no effect on the | syntactic interpretation of an expression. | | | So, it would be strange if koenig lookup found also non-functions, as it cannot | change the interpretation of the expression anyway. This also agrees with what | EDG does (consider the code above valid). Whether "argument dependent name lookup" should find a non-function is a HOT topic and an issue in Core, with active status. I don't think anything should be done in this area before we know where we head. Most definitely the wording is sufficiently ambiguous to allow GCC behaviour. As noted in the corresponding Core issue, name lookup is applied uniformly and anything else is pure accident and should be fixed -- which means that ADL can find non-functions. Please consult the "summary" on the debate on the Core issue list (the whole debate is much much larger than the summary publically made available). -- Gaby
Subject: Re: Should Koenig lookup find non-functions? "giovannibajo at libero dot it" <gcc-bugzilla@gcc.gnu.org> writes: | Created an attachment (id=7073) | --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7073&action=view) | Patch | | This patch fixes the bug, but requires testing. If someone wants to beat me at | it... The patch should be put on hold, given my previous comment. -- Gaby
Confirmed.
But supsending it based on comment #2.
Subject: Re: Should Koenig lookup find non-functions? gdr at integrable-solutions dot net wrote: > Whether "argument dependent name lookup" should find a non-function > is a HOT topic and an issue in Core, with active status. I don't > think anything should be done in this area before we know where we > head. Most definitely the wording is sufficiently ambiguous to allow > GCC behaviour. As noted in the corresponding Core issue, name lookup > is applied uniformly and anything else is pure accident and should be > fixed -- which means that ADL can find non-functions. Please consult > the "summary" on the debate on the Core issue list (the whole debate > is much much larger than the summary publically made available). Thanks for the explanation. Yes, we can keep this suspended, the patch was merely a proof of concept. Giovanni Bajo
Bug 17045 looks like the same issue.
http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_active.html#218
*** Bug 25980 has been marked as a duplicate of this bug. ***
Since the issue in question is now a DR, can this bug be re-activated? http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_defects.html#218 Thanks.
Reopening.
Subject: Bug 17365 Author: jason Date: Wed Nov 4 18:13:57 2009 New Revision: 153905 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153905 Log: PR c++/17365, DR 218 * name-lookup.c (add_function): Ignore non-functions. Added: trunk/gcc/testsuite/g++.dg/lookup/koenig6.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/name-lookup.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/lookup/koenig5.C trunk/gcc/testsuite/g++.dg/template/crash56.C trunk/gcc/testsuite/g++.old-deja/g++.ns/koenig5.C
Fixed for 4.5.0.