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

[Nathan Sidwell <nathan at codesourcery dot com>]

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