[Bug c++/19403] [4.0 Regression] name lookup is broken with friends
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-11 20:34 --- (In reply to comment #13) > This looks like a duplicate of PR 1016 to me. It might be a dup bug the example in this bug was able to compile in 3.4.0 and before. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19403
[Bug c++/19403] [4.0 Regression] name lookup is broken with friends
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-02-11 17:37 --- This looks like a duplicate of PR 1016 to me. -- What|Removed |Added CC||reichelt at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19403
[Bug c++/19403] [4.0 Regression] name lookup is broken with friends
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-30 14:28 --- *** Bug 19709 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||debian-gcc at lists dot ||debian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19403
[Bug c++/19403] [4.0 Regression] name lookup is broken with friends
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-30 14:28 --- Confirmed. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|REOPENED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19403
[Bug c++/19403] [4.0 Regression] name lookup is broken with friends
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-30 14:27 --- Reopening as I must have missed GDR's last comment. -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19403
[Bug c++/19403] [4.0 Regression] name lookup is broken with friends
--- Additional Comments From gdr at integrable-solutions dot net 2005-01-14 16:10 --- Subject: Re: [4.0 Regression] name lookup is broken with friends "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | (In reply to comment #2) | > Excuse me? | | You are right, but what is werid here is that ICC even in strict mode and Comeau accept the code. My apologies. After close inspection, ICC and Comeau are right in accepting the code, but with semantics different from what GCC used to do (wrong behaviour). | This is invalid code and a dup of bug 14513. Sadly, I was hastly. The code is valid, this is reject-valid. But the behaivour is not the one we used to implement. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19403
[Bug c++/19403] [4.0 Regression] name lookup is broken with friends
--- Additional Comments From gdr at integrable-solutions dot net 2005-01-14 16:06 --- Subject: Re: [4.0 Regression] name lookup is broken with friends "Woebbeking at web dot de" <[EMAIL PROTECTED]> writes: | Subject: Re: [4.0 Regression] name lookup is broken with friends | | On Thursday 13 January 2005 15:52, lerdsuwa at gcc dot gnu dot org wrote: | > | > > So B's ctor uses the global A without the friend declaration and with the | > > friend declaration the local injected A? Sometimes the holy standard | > > confuses me a bit. | > | > No. With or without friend declaration, the B's ctor should always pick | > the global A. This is one weird rule in C++ standard. | | Now I'm even more confused than before. Who is right, Gaby or lerdsuwa? lerdsuwa is right on all points. Gaby is right on the friend declaration and wrong the fact that the code should not compile. Both lerdsuwa and Gaby agree on what the friend declaration does. The program would compile (as it does in previous versions) but it will not have the same semantics as with previous GCC. The previous behaviour was wrong in the sense that GCC picked the wrong "A". When lerdsuwa's patch is applied, your program will be accpeted, but it will not do what you thought it would do. As a tangential note, sometime ago, I requested that a template-parameter be allowed to be a friend (currently forbidden). As a result of that reuest, Mike Miller proposed a wording to amend the current rules and we will have the new friend syntax friend T; where "T" can be any type-name -- not just an elaborated specifier.. At the moment there is a debate whether that friend-declaration should introduce a new name (current friend-declaration semantics) or just refer to an existing declaration (with error if none exists). John Spicer and I favour the latter semantics. If that semantics get adopted, you could leave out the "class" from your friend-declaration and the semantics would be such that in all cases the compiler will pick ::A. Which I believe is the least surprising behaviour. This proposal had been discussed at several time by both Core and Evolution groups; and Mike already wrote formal standardese for that. My hope is that the next meeting would promote that formal specification to "higher" level, either in the working paper or close to. But I guess that does not help you much, now. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19403
[Bug c++/19403] [4.0 Regression] name lookup is broken with friends
--- Additional Comments From Woebbeking at web dot de 2005-01-14 09:56 --- Subject: Re: [4.0 Regression] name lookup is broken with friends On Thursday 13 January 2005 15:52, lerdsuwa at gcc dot gnu dot org wrote: > > > So B's ctor uses the global A without the friend declaration and with the > > friend declaration the local injected A? Sometimes the holy standard > > confuses me a bit. > > No. With or without friend declaration, the B's ctor should always pick > the global A. This is one weird rule in C++ standard. Now I'm even more confused than before. Who is right, Gaby or lerdsuwa? André -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19403
[Bug c++/19403] [4.0 Regression] name lookup is broken with friends
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-01-13
14:52 ---
> So B's ctor uses the global A without the friend declaration and with the
> friend declaration the local injected A? Sometimes the holy standard confuses
> me a bit.
No. With or without friend declaration, the B's ctor should always pick
the global A. This is one weird rule in C++ standard.
The idea is that name lookup for 'friend struct A;' only find A within
one level outside the classes enclosing the friend declaration:
namespace N {
class A {
class B {
friend class C; // Classes A and B enclosing this friend.
// one level up is namespace N.
// Since there is no B::C nor A::C,
// this refers to N::C
};
};
}
void f() {
class D {
friend class E; // Since there is no D::E, one level up
// is the local class E inside function f.
};
}
When refer to A without the prefix 'class' or 'struct', any name
can be used. However the name introduced by friend must be
explicitly declared first to be visible.
Now it's your example, expanded with more cases and comment describing
the way it should be handled.
struct A {};
namespace Boo
{
struct B
{
friend struct A; // Since there is no B::A, this means Boo::A
// It introduces Boo::A but still invisible
// since there is no Boo::A declaration prior
// to this friend.
B(const A&) {}; // Boo::A is still not visible,
// so ::A is chosen here
};
void f(const A&) {} // Boo::A is still not visible, choose ::A
struct A; // Declare Boo::A explicitly, so Boo::A is now visible
void g(const A&) {} // Choose Boo::A
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19403
[Bug c++/19403] [4.0 Regression] name lookup is broken with friends
--- Additional Comments From Woebbeking at web dot de 2005-01-13 10:07 --- Subject: Re: [4.0 Regression] name lookup is broken with friends On Wednesday 12 January 2005 20:37, gdr at integrable-solutions dot net wrote: > > Excuse me? > > The behaviour mandated by the C++ standard is that if there is no > declaration for type A in the innermost enclosing namespace then an > implicit one is added -- because A is used unqualified. In > particular, the global A should not be found. Thus the code is > ill-formed. So B's ctor uses the global A without the friend declaration and with the friend declaration the local injected A? Sometimes the holy standard confuses me a bit. André -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19403
[Bug c++/19403] [4.0 Regression] name lookup is broken with friends
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-01-13
05:55 ---
Both ICC and Comeau are right.
The declaration
friend struct A;
refers to boo::A, while the declaration
B(const A&) {};
refers to ::A. So the code should compile.
The patch for PR1016, scheduled for 4.1, should fix it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19403
[Bug c++/19403] [4.0 Regression] name lookup is broken with friends
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-12 19:47 --- (In reply to comment #2) > Excuse me? You are right, but what is werid here is that ICC even in strict mode and Comeau accept the code. This is invalid code and a dup of bug 14513. *** This bug has been marked as a duplicate of 14513 *** -- What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19403
[Bug c++/19403] [4.0 Regression] name lookup is broken with friends
--- Additional Comments From gdr at integrable-solutions dot net 2005-01-12 19:37 --- Subject: Re: [4.0 Regression] name lookup is broken with friends "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | : Search converges between 2004-11-25-014001-trunk (#656) and 2004-11-25-161001-trunk | (#657). | | Yes this is valid code. we should have found the global A for the statement "friend struct A;" but instead | it adds a class to the namespace Boo which is wrong. Excuse me? The behaviour mandated by the C++ standard is that if there is no declaration for type A in the innermost enclosing namespace then an implicit one is added -- because A is used unqualified. In particular, the global A should not be found. Thus the code is ill-formed. The PR should be closed as invalid. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19403
[Bug c++/19403] [4.0 Regression] name lookup is broken with friends
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-12 18:42 --- : Search converges between 2004-11-25-014001-trunk (#656) and 2004-11-25-161001-trunk (#657). Yes this is valid code. we should have found the global A for the statement "friend struct A;" but instead it adds a class to the namespace Boo which is wrong. I am alomst certain it is caused by one of the "Friend class name lookup" patches. -- What|Removed |Added CC||lerdsuwa at users dot ||sourceforge dot net Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||rejects-valid Last reconfirmed|-00-00 00:00:00 |2005-01-12 18:42:20 date|| Summary|name lookup is broken |[4.0 Regression] name lookup ||is broken with friends Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19403
