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

[Chris Lattner]

On Aug 1, 2008, at 12:39 PM, Argiris Kirtzidis wrote:

> Hi,
>
> For the next chapter of the C++ support saga, I've implemented  
> nested-name-specifier support ("foo::bar::").

Nice!

> The attached 'pp-caching' patch, modifies Preprocessor::LookAhead  
> (making it efficient enough to replace LookNext) and adds  
> 'rewinding' functionality.
> That is, one can call Preprocessor::EnableRewindAtThisPos, lex and  
> consume any number of tokens, and later call Preprocessor::Rewind to  
> make the preprocessor re-lex the tokens that were previsouly lexed  
> since EnableRewindAtThisPos was called.

I think we will need this functionality (aka 'tentative parsing' or  
'backtracking') at some point, but I'm not sure why we need it for  
this.  As a prolog, I haven't dug into the part of the spec, so if I'm  
missing something obvious, please be gentle on me :)

My basic understanding (again, based on intuition, not reading of the  
spec) of scope resolution was that it could actually be implemented  
without lookahead.  My thought was that if you see ::A::B or A::B that  
you start by looking up the ::A /A part and decide what it  
references.  when looking up A, consider if it resolves to a  
namespace.  My though would be that the parser invokes an action to  
look up the decl corresponding to A.

Options are that it could either be:
1) typedef name
2) variable/ivar/etc
3) namespace
4) struct
...

One ::A is looked up, based on what the action returns, my assumption  
is that the parser would see the next :: and do a subscope lookup.   
Basically it would parse "::B" and then invoke an action to look  
up ::B in the decl returned by the ::A lookup.  At some point  
presumably, you end up with a type or a variable etc, which we'd need  
to treat as the start of a declspec etc.  One nice thing about this is  
that it would not require the parser to build up an explicit  
'CXXScopeSpec' object, Sema could build it if it wanted, but it  
wouldn't be required.

Is this approach achievable?  I'd prefer to avoid parsing and  
rewinding unless absolutely necessary.

-Chris