[cfe-commits] [PATCH] Don't diagnose missing typename at point of definition in case when injected-class-name type has dependant bases.

[schaub-johannes at web.de]

Eli Friedman eli.friedman at gmail.com wrote:
> On Sun, Dec 27, 2009 at 7:35 PM, Piotr Rak <piotr.rak at gmail.com> wrote:
> > Hi,
> >
> > I've not followed changes in clang recently, thus not I am not sure if
> > it is quite correct.
> > This one allows compile <tr1/unordered_map> header from gcc-4.1.2.
>
> I think the code is invalid.  In the given testcase, "typename
> B::type" isn't a dependent name because "B" refers to the current
> instantiation (in the sense of [temp.dep.type]).  Therefore, it must
> be resolved immediately.  That said, the standard could be clearer...
>

I was in the impression that "dependent name" means any name whose semantics 
may differ between instantiations [temp.dep]. For "B::type", this is certainly 
true. That is, a construct (such as a name) can be dependent even if 
it's/denotes not a dependent type (by the explicit list of what is and what is 
not a dependent type), and as a result is looked up in the instantiation 
context. 

However it seems to me too that since B refers to the current instantiation, 
B::type will not be/denote a dependent type - however i think that does not 
limit lookup to the definition context.

The Standard (draft n3000) says [temp.res]/2 "A name used in a template 
declaration or definition and that is dependent on a template-parameter is 
assumed not to name a type unless the applicable name lookup finds a type name 
or the name is qualified by the keyword typename.". That means, "B::type" is 
dependent and "applicable name lookup" (assuming it means "name lookup in the 
definition context") does not find a type, and so "typename" is needed to mark 
it as a type. 

Not sure whether this is the right analysis though, i find too that the 
Standard could be clearer about that. I recently had a discussion with William 
M. Miller from EDG, who taught me how "dependent name" does not only mean 
"denotes a dependent type", though, but has a much wider range where it 
applies :)