[cfe-dev] [PATCH] C++ nested-name-specifier (Parser)

[Chris Lattner]

On Aug 9, 2008, at 10:01 PM, Argiris Kirtzidis wrote:

> Chris Lattner wrote:
>>
>>> Sema actions like isTypeName and ActOnIdentifier, check the scope- 
>>> spec to see whether it needs to lookup a name inside the scope- 
>>> spec decl, or do a normal lookup.
>>
>> This is interesting: doesn't this mean that everything else will  
>> have to check to make sure that this hasn't happened, in order to  
>> reject invalid code?
>
> I didn't quite understand what you mean here, can you elaborate ?

My understanding is that your implementation will build up an instance  
variable of Sema with the current "scope"  If you get something like  
"X::Y" you set the scope to the looked up version of "X::" and when  
you parse Y, you use that to qualify it.  If you say "X:: 4" then I  
assume that sema for "4" would have to see that there is qualification  
happening and reject it.  Is this what you meant?

>> That is possible.  I'm more concerned with the fact that Sema for  
>> ';' will have to check to make sure there is no current scope-spec  
>> that is active.  This approach seems to make it so that *all* sema  
>> actions would have to check for an empty scope-spec :(
>
> This is why I think that having Sema keep the scope-spec state is  
> awkward and a hassle. The parser knows when parsing errors occured,  
> or when it needed to backtrack, etc., so the parser can do a far  
> better job of keeping track of the scope-spec state (when to clear  
> it, etc.).
>
> Sema actions can receive the scope-spec as parameter, which brings  
> me to my next point, that a [scope specifier + identifier] is  
> considered one syntactic construct by the spec, like a qualified-id,  
> or an elaborated-type-specifier, thus it makes sense to pass it  
> along to an action that handles a construct that it may be a part of.
> For example, we can consider that ActOnIdentifier receives a  
> qualified-id, and that ActOnTag receives a elaborated-type-specifier  
> ("class A::B {};").

Ah... so you're saying that Sema *resolves* the scope specifier, but  
that it returns a cookie *back to the parser*, which then passes it  
into the next action.  If so, this makes a lot of sense to me, I think  
this can work.  This means that only actions that take the scope  
specifier would have to handle it, and the parser would know how to  
handle other parser errors.


>> Sure, but this can apparently happen in the 'friend' case and some  
>> others, according to the Elsa doc.  I confess to not being an  
>> expert on these matters though.
>
> The Elsa doc also says:
>> every C++ compiler I've experimented with regards "::" as binding
>> very tightly, such that any occurrence of an identifier followed
>> by "::" is always interpreted as an attempt to use the binary "::",
>>
>
> I think Clang can be one those pesky compilers too, at least for  
> compatibility's sake  ;-)

If you really don't think this will be an issue, I will happily  
believe you :), you know far more about this than I do.  I just want  
efficiency :)

-Chris