Re: PATCH RFA: Possible fix for PR c++/11987

[Mark Mitchell <mark at codesourcery dot com>]

Ian Lance Taylor wrote:
> Mark Mitchell <mark@codesourcery.com> writes:
> 
> 
>>IIRC, it's specifically the situation where the typedef is nested in
>>another class.  Now, it would sure be useful if I had the standardese to
>>justify that, wouldn't it? :-)  I'll see if I can find it.

I looked into this.

The language I was thinking of is [dcl.meaning] which says:

"When the declarator-id is qualified, the declaration shall refer to a
previously declared member of the class or namespace to which the
qualifier refers."

and [class.mfct], which says:

"[t]he member function name shall be qualified by its class name using
the :: operator"

However, I'm not sure how to read that.  The phrase "its class name" is
somewhat ambiguous in that a typedef for a class-name creates a new
class-name, so there can be multiple class-names for the same class.
So, I'm not convinced that the interpretation I gave you before is accurate.

Also, I see that EDG accepts:

struct X {
  struct I { I(); };
};

struct Y : X {
  typedef X::I I;
};

Y::I::I () {}

even though it rejects the original test case, with the somewhat cryptic:

"test2.cpp", line 11: error: "Y<dim>::I" is not a class template

So, that suggests that the issue is really to do with template dependency.

And, indeed, in:

template <int dim>
Y<dim>::I::I () {}

I think the key issue is whether Y<dim>::I is known to be X<dim>::I or not.

In terms of implementation, we call resolve_typename_type for Y<dim>::I
from cp_parser_direct_declarator.  We get a TYPENAME_TYPE there whether
this is written Y<dim>::I or X<dim>::I.

I'm going to discuss this with EDG.

Your patch, technically, seems good; the only recommendation I would
have is that we might consider taking those four fields in cp_parser and
putting them into a struct, so that saving/restoring them was just a
single copy.

I really apologize for leading you down the primrose path here; I did
try to hedge my bets about the standard, but I should have checked
sooner so as not to waste your time implementing stuff before we were
sure it was necessary.

I'm going to add a link to this message to the PR.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304