Re: c++/9476: lookup of member in base class template fails

Re: c++/9476: lookup of member in base class template fails

[Nathan Sidwell]

The following reply was made to PR c++/9476; it has been noted by GNATS.

From: Nathan Sidwell <nathan@codesourcery.com>
To: jan@etpmod.phys.tue.nl
Cc: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org,
   gcc-prs@gcc.gnu.org
Subject: Re: c++/9476: lookup of member in base class template  fails
Date: Tue, 28 Jan 2003 15:51:52 +0000

 Jan Van Dijk wrote:
 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9476
 > 
 > You (Nathan) said that `the usual' lookup rules apply here. In these words I 
 > read that within D<X> the data member i could be found in the base class 
 > B<X>, according to 3.4.1/7.
 Nope. you do not look in dependent bases.
 
 
 > In fact, I believed that the requirement that `specializations of templates 
 > are known before first use of the template' was exactly to make code like 
 > this have a clear meaning, independent of the presence of specialisations of 
 > the base class. (Otherwise, a specialisation B<double> could re-define the 
 > type of i.)
 A specialization could indeed do that. That's why dependent bases are ignored
 in parse lookup. The specialization rule is so the compiler knows not to
 implicitly instantiate B<double>, where the definition of such a class would
 be needed.
 
 > In your mail you also say that `the koenig lookup should be resolved at parse 
 > time. (see example in 14.6/9)'.
 yup, and it would fail, giving an error. g++ is incorrectly waiting until
 instantaition time.
 
  > Well, in the code in my report a definition
 > of `int i' is present in the base class which is seen at parse time, so what 
 > is the problem? The example in 14.6.9 is different: there the line `d++' 
 > refers to a d that is not there (yet). It is declared a few lines lower.
 that first call 'f (1)' calls '::f (char)' and is resolved at parse time.
 Note that the later declaration of '::f (int)' is not considered. The second
 call of 'f (T (1))' is delayed until instantiation time, and resolves to ':: f (int)'
 
 > As a sidenote: earlier today a similar report has been posted (9447). It may 
 > be taken into acount in this discusssion. In the audit trail of that PR, 
 > Paolo Carlini expresses his belief that these _are_ parser bugs, BTW. Also 
 > Gabriel Dos Reis seems to be certain that the present behaviour is not 
 > correct (mailing list, today). 
 I took gaby's email to be agreeing with me (it can be read either way).
 there is a parser bug, I believe it to be that 'f ()' is not rejected
 
 Please refer to Mark Mitchell's email of a few days ago about two stage
 lookup.
 
 nathan
 -- 
 Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
           The voices in my head said this was stupid too
 nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org
 
 

Re: c++/9476: lookup of member in base class template fails

[Jan Van Dijk]

The following reply was made to PR c++/9476; it has been noted by GNATS.

From: Jan Van Dijk <janvandijkinjapan@yahoo.co.jp>
To: gcc-gnats@gcc.gnu.org,
 gcc-bugs@gcc.gnu.org,
 nobody@gcc.gnu.org,
 gcc-prs@gcc.gnu.org,
 jan@etpmod.phys.tue.nl
Cc:  
Subject: Re: c++/9476: lookup of member in base class template  fails
Date: Wed, 29 Jan 2003 00:12:43 +0000

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=3Dview%20audit-trail&database=3D=
 gcc&pr=3D9476
 
 You (Nathan) said that `the usual' lookup rules apply here. In these word=
 s I=20
 read that within D<X> the data member i could be found in the base class=20
 B<X>, according to 3.4.1/7.
 
 In fact, I believed that the requirement that `specializations of templat=
 es=20
 are known before first use of the template' was exactly to make code like=
 =20
 this have a clear meaning, independent of the presence of specialisations=
  of=20
 the base class. (Otherwise, a specialisation B<double> could re-define th=
 e=20
 type of i.)
 
 In your mail you also say that `the koenig lookup should be resolved at p=
 arse=20
 time. (see example in 14.6/9)'. Well, in the code in my report a definiti=
 on=20
 of `int i' is present in the base class which is seen at parse time, so w=
 hat=20
 is the problem? The example in 14.6.9 is different: there the line `d++'=20
 refers to a d that is not there (yet). It is declared a few lines lower.
 
 As a sidenote: earlier today a similar report has been posted (9447). It =
 may=20
 be taken into acount in this discusssion. In the audit trail of that PR,=20
 Paolo Carlini expresses his belief that these _are_ parser bugs, BTW. Als=
 o=20
 Gabriel Dos Reis seems to be certain that the present behaviour is not=20
 correct (mailing list, today).=20
 
 Hmmm. Clash of the Titans. I'm going to watch and be curious about the ou=
 tcome=20
 of the discussion.
 
 =09Regards, Jan.
 
 --=20
 Keio-Tsuushin Residence
 Jan van Dijk, Room 210
 2 Chome 19-30, Mita Minato-ku
 108 Tokyo, Japan
 
 jan@etpmod.phys.tue.nl
 tel: +81 3 5476 9461 (home)
 __________________________________________________
 Do You Yahoo!?
 Yahoo! BB is Broadband by Yahoo!  http://bb.yahoo.co.jp/
 

Re: c++/9476: lookup of member in base class template fails

[nathan]

Synopsis: lookup of member in base class template  fails

State-Changed-From-To: open->analyzed
State-Changed-By: nathan
State-Changed-When: Tue Jan 28 13:14:13 2003
State-Changed-Why:
    just to be clear, the bug is that plain f () is accepted
    at parse time without error. The code is ill-formed.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9476

c++/9476: lookup of member in base class template fails

[jan]

>Number:         9476
>Category:       c++
>Synopsis:       lookup of member in base class template  fails
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          rejects-legal
>Submitter-Id:   net
>Arrival-Date:   Tue Jan 28 13:06:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     Jan van Dijk
>Release:        gcc version 3.4 20030128 (experimental)
>Organization:
>Environment:
Linux 2.5.59, glibc-2.2.5
>Description:
gcc-head fails to compile he accompanying code:

gcctest.cpp: In member function `void D<T>::bad()':
gcctest.cpp:12: error: `i' has not been declared

Qualifying i as B<T>::i (thus making i a dependent name explicitly) fixes the problem, see ugly(). To my surprise, look up of member variables is now different from that of member functions: f() does not need to be qualified (see good()).

Comments from Nathan Sidwell on the mailing list:

refer to 14.6/8 in your example both i and f are non-dependent names so the usual lookup rules apply. 3.4.1, 3.4.2. 3.4.1 deals with non-function call unqualified name lookup (i), and 3.4.2 deals with
unqualified names used for function calls. That uncludes koenig lookup. In this case there are no template-dependent arguments, so the koenig lookup should be resolved at parse time. (see example in 14.6/9)
<snip>
void good(){ f(); } // no B<T>:: required
If you said &f;, you'd get the same error. I think this is a bug,
please file a bug report.


>How-To-Repeat:
template <class T>
struct B 
{
        int i;
        int f();
};

template <class T>
struct D : public B<T> 
{
        void good(){ f(); }        // no B<T>:: required
        void bad(){ i=0            // does not compile
        void ugly(){ B<T>::i=0; }  // ... this does.
};
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: