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

[Argiris Kirtzidis]

Chris Lattner wrote:
>
> 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?

No, I think it's the parser's job to reject "X:: 4". It should emit a 
parsing error when it encounters '4'.

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

Yes! Sema will return a CXXScopeTy* (alias for void*) and the parser 
will keep track of it and pass it along to other actions.

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

I'm glad that you agree. I'll post an updated patch later on.


-Argiris

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