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

[Argiris Kirtzidis]

Doug Gregor wrote:
>   
>>> 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.
>   

Currently the assumptions for the Scope is that it contains a set of 
declarations that were declared in it and has a parent Scope that 
contains it.
I'm concerned about the Parser passing to Sema a Scope that has an empty 
declaration set and no real parent.
But it may turn out not a big deal if it doesn't actually matter much.

>   
>> 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.
>   

If I understand correctly, you mean when instantiating a template that 
contains
   SomeClass<T>::x    // 'T' is a template parameter
the DeclContext for "SomeClass<T>::" will be resolved at instatiation 
time, not parsing time, so we need to have the 'CurContext' around.
Is this correct ?

> 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?
>   

No, ActOnCXXEnterDeclaratorScope will just set 'CurContext' to the 
context of the nested-name defined in the declarator.
The difference is in how contexts are 'popped' in Sema. Currently, when 
'CurContext' is popped we switch to its parent, but this won't work for 
contexts caused by nested names (when they are popped, 'CurContext' 
should switch to the declaration context before the nested-name was 
introduced).


-Argiris