public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/13935] [3.4/3.5 Regression] Template friend lookup bug
  2004-01-30 16:50 [Bug c++/13935] New: [3.4/3.5 Regression] Template friend lookup bug giovannibajo at libero dot it
@ 2004-01-30 16:50 ` giovannibajo at libero dot it
  2004-01-30 17:10 ` bangerth at dealii dot org
                   ` (7 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: giovannibajo at libero dot it @ 2004-01-30 16:50 UTC (permalink / raw)
  To: gcc-bugs


------- Additional Comments From giovannibajo at libero dot it  2004-01-30 16:50 -------
Can anybody check this on the 3.3 branch?

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |3.4.0 3.5.0
      Known to work|                            |3.2.2


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


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug c++/13935] New: [3.4/3.5 Regression] Template friend lookup bug
@ 2004-01-30 16:50 giovannibajo at libero dot it
  2004-01-30 16:50 ` [Bug c++/13935] " giovannibajo at libero dot it
                   ` (8 more replies)
  0 siblings, 9 replies; 10+ messages in thread
From: giovannibajo at libero dot it @ 2004-01-30 16:50 UTC (permalink / raw)
  To: gcc-bugs

Posted by MattT originally within PR13813, but it's not related to that bug so 
I moved it to a different PR.

----------------------------------------------
template < class TP1 >
class MainClass {
public:
  
  class A;
  
  friend class B;
  
  A a;
  
  template < class TP2 > class B {};
  
  class A {
    
    template < class TP2 > friend class B;
    
  };
  
};

int main(int argc, char *argv[]) {
  MainClass<int> var;
}
----------------------------------------------
matt.cc: At global scope:
matt.cc: In instantiation of `MainClass<int>::A':
matt.cc:9:   instantiated from `MainClass<int>'
matt.cc:22:   instantiated from here
matt.cc:13: error: `template<class TP2> struct MainClass<int>::B' redeclared as 
different kind of symbol
matt.cc:13: error: previous declaration of `struct B'


EDG is confused because it refuses the definition of variable "a" at parsing 
time (which is wrong, since its type is dependent - MainClass<T>::A - even 
under DR224). 

It *looks* like the code should be accepted to me.

-- 
           Summary: [3.4/3.5 Regression] Template friend lookup bug
           Product: gcc
           Version: 3.5.0
            Status: UNCONFIRMED
          Keywords: rejects-valid
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: giovannibajo at libero dot it
                CC: gcc-bugs at gcc dot gnu dot org,mattyt-bugzilla at tpg
                    dot com dot au


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


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug c++/13935] [3.4/3.5 Regression] Template friend lookup bug
  2004-01-30 16:50 [Bug c++/13935] New: [3.4/3.5 Regression] Template friend lookup bug giovannibajo at libero dot it
  2004-01-30 16:50 ` [Bug c++/13935] " giovannibajo at libero dot it
@ 2004-01-30 17:10 ` bangerth at dealii dot org
  2004-01-30 17:45 ` gdr at integrable-solutions dot net
                   ` (6 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: bangerth at dealii dot org @ 2004-01-30 17:10 UTC (permalink / raw)
  To: gcc-bugs


------- Additional Comments From bangerth at dealii dot org  2004-01-30 17:10 -------
It fails with the same error on 3.3.3-pre. 
 
However, I'm not sure whether this is not illegal: you first say 
  friend class B; 
but then you declare B as a template: 
  template <typename TP2> class B 
What confuses me is that this is not detected. 
 
W. 

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|3.4.0 3.5.0                 |3.4.0 3.5.0 3.3.3


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


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug c++/13935] [3.4/3.5 Regression] Template friend lookup bug
  2004-01-30 16:50 [Bug c++/13935] New: [3.4/3.5 Regression] Template friend lookup bug giovannibajo at libero dot it
  2004-01-30 16:50 ` [Bug c++/13935] " giovannibajo at libero dot it
  2004-01-30 17:10 ` bangerth at dealii dot org
@ 2004-01-30 17:45 ` gdr at integrable-solutions dot net
  2004-01-30 17:58 ` giovannibajo at libero dot it
                   ` (5 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: gdr at integrable-solutions dot net @ 2004-01-30 17:45 UTC (permalink / raw)
  To: gcc-bugs


------- Additional Comments From gdr at integrable-solutions dot net  2004-01-30 17:45 -------
Subject: Re:  [3.4/3.5 Regression] Template friend lookup bug

"bangerth at dealii dot org" <gcc-bugzilla@gcc.gnu.org> writes:

| It fails with the same error on 3.3.3-pre. 
|  
| However, I'm not sure whether this is not illegal: you first say 
|   friend class B; 
| but then you declare B as a template: 
|   template <typename TP2> class B 
| What confuses me is that this is not detected. 

You're right in thinking that the program is invalid. Indeed it is.
A template-name ought to designate a unique entity in a given
declarative region, e.g. there is no "struct hack" for template
names.  Same for namespace names.  And that is Good!

-- Gaby


-- 


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


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug c++/13935] [3.4/3.5 Regression] Template friend lookup bug
  2004-01-30 16:50 [Bug c++/13935] New: [3.4/3.5 Regression] Template friend lookup bug giovannibajo at libero dot it
                   ` (2 preceding siblings ...)
  2004-01-30 17:45 ` gdr at integrable-solutions dot net
@ 2004-01-30 17:58 ` giovannibajo at libero dot it
  2004-01-30 19:23 ` gdr at integrable-solutions dot net
                   ` (4 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: giovannibajo at libero dot it @ 2004-01-30 17:58 UTC (permalink / raw)
  To: gcc-bugs


------- Additional Comments From giovannibajo at libero dot it  2004-01-30 17:58 -------
Well, when I say:

friend class B;

I'm saying that ::B is a friend of MainClass<> (and ::B is thus predeclared). 
Then, I'm defining MainClass<>::B<>, which is a totally unrelated type. I don't 
see how this could be illegal.

I think the crucial point is about this:
template < class TP2 > friend class B;

Does this refer to ::B or to MainClass<>::B<>? How is the lookup performed, 
exactly? There are a couple of DR in TC1 about name lookup issues of friend 
templates, I'll give them a deeper look.


-- 


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


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug c++/13935] [3.4/3.5 Regression] Template friend lookup bug
  2004-01-30 16:50 [Bug c++/13935] New: [3.4/3.5 Regression] Template friend lookup bug giovannibajo at libero dot it
                   ` (3 preceding siblings ...)
  2004-01-30 17:58 ` giovannibajo at libero dot it
@ 2004-01-30 19:23 ` gdr at integrable-solutions dot net
  2004-02-02  2:16 ` giovannibajo at libero dot it
                   ` (3 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: gdr at integrable-solutions dot net @ 2004-01-30 19:23 UTC (permalink / raw)
  To: gcc-bugs


------- Additional Comments From gdr at integrable-solutions dot net  2004-01-30 19:23 -------
Subject: Re:  [3.4/3.5 Regression] Template friend lookup bug

"giovannibajo at libero dot it" <gcc-bugzilla@gcc.gnu.org> writes:

| ------- Additional Comments From giovannibajo at libero dot it  2004-01-30 17:58 -------
| Well, when I say:
| 
| friend class B;
| 
| I'm saying that ::B is a friend of MainClass<> (and ::B is thus predeclared). 
| Then, I'm defining MainClass<>::B<>, which is a totally unrelated
| type. I don't  see how this could be illegal.

That is the same thing as for

   struct foo { };

   struct bar {
      foo foo;
   };  

The first 'foo' refers to the outer foo, and the second changes the
meaning of the first.  That is ill-formed even though a diagnostic is
not required.  If you want to make that valid construct, then you need
to qualify explicitly

   struct bar {
      ::foo foo;
   };

See 3.3.6/1
   [...]
   2) A name N used in a class S shall refer to the same declaration
      in its context and when reevaluated in the completed scope of
      S. No diagnostic is required for a violation of this rule.

| I think the crucial point is about this:
| template < class TP2 > friend class B;
| 
| Does this refer to ::B or to MainClass<>::B<>?

That refers to the second, but then the meaning of the use of the
unqualified name 'B' changes after the class is completed.

| How is the lookup performed, exactly? 

On the first friend declaration, one looks into the current class
scope, finds nothing, then looks into the enclosing namespace scope.
One finds ::B.  But when MainClass<> is completed, you see that the
meaning of B (as en unqualified name in the scope of MainClass<>) has
changed. So, your program is in error.

-- Gaby


-- 


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


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug c++/13935] [3.4/3.5 Regression] Template friend lookup bug
  2004-01-30 16:50 [Bug c++/13935] New: [3.4/3.5 Regression] Template friend lookup bug giovannibajo at libero dot it
                   ` (4 preceding siblings ...)
  2004-01-30 19:23 ` gdr at integrable-solutions dot net
@ 2004-02-02  2:16 ` giovannibajo at libero dot it
  2004-02-02  2:27 ` gdr at integrable-solutions dot net
                   ` (2 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: giovannibajo at libero dot it @ 2004-02-02  2:16 UTC (permalink / raw)
  To: gcc-bugs


------- Additional Comments From giovannibajo at libero dot it  2004-02-02 02:16 -------
(In reply to comment #5)

> That is the same thing as for
>    struct foo { };
>    struct bar {
>       foo foo;
>    };  

I disagree. [class.friend]/1: "The name of a friend is not in the scope of the 
class."

> See 3.3.6/1
>    [...]
>    2) A name N used in a class S shall refer to the same declaration
>       in its context and when reevaluated in the completed scope of
>       S. No diagnostic is required for a violation of this rule.

3.3.6 is [basic.class.scope] and 3.3.6/1 begins with: "The following rules 
describe the scope of names declared in classes". Given [class.friend]/1, I 
don't see how this could apply.


-- 


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


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug c++/13935] [3.4/3.5 Regression] Template friend lookup bug
  2004-01-30 16:50 [Bug c++/13935] New: [3.4/3.5 Regression] Template friend lookup bug giovannibajo at libero dot it
                   ` (5 preceding siblings ...)
  2004-02-02  2:16 ` giovannibajo at libero dot it
@ 2004-02-02  2:27 ` gdr at integrable-solutions dot net
  2004-02-02  2:35 ` giovannibajo at libero dot it
  2004-02-03  9:22 ` mmitchel at gcc dot gnu dot org
  8 siblings, 0 replies; 10+ messages in thread
From: gdr at integrable-solutions dot net @ 2004-02-02  2:27 UTC (permalink / raw)
  To: gcc-bugs


------- Additional Comments From gdr at integrable-solutions dot net  2004-02-02 02:26 -------
Subject: Re:  [3.4/3.5 Regression] Template friend lookup bug

"giovannibajo at libero dot it" <gcc-bugzilla@gcc.gnu.org> writes:

| ------- Additional Comments From giovannibajo at libero dot it  2004-02-02 02:16 -------
| (In reply to comment #5)
| 
| > That is the same thing as for
| >    struct foo { };
| >    struct bar {
| >       foo foo;
| >    };  
| 
| I disagree. [class.friend]/1: "The name of a friend is not in the
| scope of the class."

You're confused:  There is a difference between being in the scope of
the class  and being used in the class definition.   The quote I gave
does not speak of being in the scope of the class, so the paragraph
you quote is irrelevant. 


| > See 3.3.6/1
| >    [...]
| >    2) A name N used in a class S shall refer to the same declaration
| >       in its context and when reevaluated in the completed scope of
| >       S. No diagnostic is required for a violation of this rule.
| 
| 3.3.6 is [basic.class.scope] and 3.3.6/1 begins with: "The following rules 
| describe the scope of names declared in classes". Given [class.friend]/1, I 
| don't see how this could apply.

Note that the paragraph speaks of "name *used*" not name declared, so
your qoute about named declared is irrelevant.  What matters is the
*use* of the names.  Here, in the friend-declaration, the name is used
to grant friendship -- it is not declared; it is *used*.  If
re-evaluation after the completed class-scope gives something different
then bad things can happen.

-- Gaby


-- 


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


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug c++/13935] [3.4/3.5 Regression] Template friend lookup bug
  2004-01-30 16:50 [Bug c++/13935] New: [3.4/3.5 Regression] Template friend lookup bug giovannibajo at libero dot it
                   ` (6 preceding siblings ...)
  2004-02-02  2:27 ` gdr at integrable-solutions dot net
@ 2004-02-02  2:35 ` giovannibajo at libero dot it
  2004-02-03  9:22 ` mmitchel at gcc dot gnu dot org
  8 siblings, 0 replies; 10+ messages in thread
From: giovannibajo at libero dot it @ 2004-02-02  2:35 UTC (permalink / raw)
  To: gcc-bugs


------- Additional Comments From giovannibajo at libero dot it  2004-02-02 02:35 -------
Subject: Re:  [3.4/3.5 Regression] Template friend lookup bug

gdr at integrable-solutions dot net wrote:

> Note that the paragraph speaks of "name *used*" not name declared, so
> your qoute about named declared is irrelevant.  What matters is the
> *use* of the names.  Here, in the friend-declaration, the name is used
> to grant friendship -- it is not declared; it is *used*.  If
> re-evaluation after the completed class-scope gives something
> different
> then bad things can happen.

So is this ill-formed:

-----------------------------
class N;
struct S
{
    void f(N* );
    class N;
};
-----------------------------

or, given the following bullet, "If reordering member declarations in a class
yields an alternate valid program under (1) and (2), the program is illformed,
no diagnostic is required.", is this ill-formed:

-----------------------------
class N;
struct S
{
    class N;
    void f(N* );
};
-----------------------------

?

Giovanni Bajo




-- 


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


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug c++/13935] [3.4/3.5 Regression] Template friend lookup bug
  2004-01-30 16:50 [Bug c++/13935] New: [3.4/3.5 Regression] Template friend lookup bug giovannibajo at libero dot it
                   ` (7 preceding siblings ...)
  2004-02-02  2:35 ` giovannibajo at libero dot it
@ 2004-02-03  9:22 ` mmitchel at gcc dot gnu dot org
  8 siblings, 0 replies; 10+ messages in thread
From: mmitchel at gcc dot gnu dot org @ 2004-02-03  9:22 UTC (permalink / raw)
  To: gcc-bugs


------- Additional Comments From mmitchel at gcc dot gnu dot org  2004-02-03 09:22 -------
Yes, both of your examples are ill-formed, and so is the original code.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


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


^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2004-02-03  9:22 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-01-30 16:50 [Bug c++/13935] New: [3.4/3.5 Regression] Template friend lookup bug giovannibajo at libero dot it
2004-01-30 16:50 ` [Bug c++/13935] " giovannibajo at libero dot it
2004-01-30 17:10 ` bangerth at dealii dot org
2004-01-30 17:45 ` gdr at integrable-solutions dot net
2004-01-30 17:58 ` giovannibajo at libero dot it
2004-01-30 19:23 ` gdr at integrable-solutions dot net
2004-02-02  2:16 ` giovannibajo at libero dot it
2004-02-02  2:27 ` gdr at integrable-solutions dot net
2004-02-02  2:35 ` giovannibajo at libero dot it
2004-02-03  9:22 ` mmitchel at gcc dot gnu dot org

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).