[cfe-dev] [PATCH] C++ nested-names (Parser) and annotation tokens

[Doug Gregor]

Hi Argiris,

On Fri, Oct 31, 2008 at 7:56 PM, Argiris Kirtzidis <akyrtzi at gmail.com> wrote:
> Doug Gregor wrote:
>> I'm pretty certain that I don't understand the role of these
>> functions. It looks like they want Sema to keep some additional state
>> regarding the scope in which name lookup should occur that's somehow
>> different from the current scope of parsing, but I don't know when
>> that happens... when we're parsing a direct-declarator, say, when
>> declaring a member function out-of-line:
>>
>>  void Sema::MemberFunction(TypeFromInSema Arg) { }
>>
>> Once we've parse Sema::MemberFunction, we seem to be calling
>> ActOnCXXEnterDeclaratorScope. I assume that's so that the lookup of
>> TypeFromInSema will look into 'Sema' first?
>>
>
> Yes, and here's another example:
>
> class C {
>  static const int num=5;
>  static int arr[num];
>  void m();
> };
>
> int C::arr[num]; // lookup 'num' in 'class C' scope

Okay, good.

>> Could we instead have a different kind of Scope that handles this case
>> of being inside "Sema" without
>>
>
> This is a "enter into an arbitrary already existing scope" kind of scope,
> and doesn't have much in common with the "enter a new parent-nested scope"
> kind that the scope mechanism of Parser uses.

Well, they have in common that name lookup needs to start from
whatever scope we most recently entered, which is one of the most
important parts of the Parser-Sema interaction. While there's
certainly a difference between "enter a new child scope" and "enter an
arbitrary scope", I think the ideas are close enough that it's just a
boolean flag on the enter/exit routines.

> Also, name lookup in Sema currently relies on 'CurContext' so the
> ActOnCXXEnterDeclaratorScope is useful to let it know that the current decl
> context should change.
>
> Do you have an alternative suggestion in mind ?
> Like, eliminating Sema's CurContext and putting that kind of information
> into Parser's Scope ?

I was about to say "yes", and then I thought about template
instantiation. With template instantiation, you typically want to
enter into the scope of the template you'll be instantiating so that
name lookup and access checking can be done from the appropriate
place. That means that it is a good thing for Sema to have CurContext
(since the parser need not exist when template instantiation occurs),
and therefore probably shouldn't be completely tied to the Parser's
Scope.

I didn't actually get to see what Sema's ActOnCXXEnterDeclaratorScope
looked like, so I'm not sure if I have a better suggestion. Does it
use a second kind of "current context" beyond CurContext?

>> +  void AnnotateToken();
>>
>> I think the name of this routine could be better, for two reasons.
>> First, it doesn't say what the annotations are doing---resolving
>> qualified-ids and such. Second, I'd like there to be a "Maybe" or a
>> "Try" at the beginning, to say that it might change the token stream
>> (or it might not).
>>
>
> TryAnnotateTypeOrScopeToken ?

Sure.

  - Doug