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

Argiris Kirtzidis akyrtzi at gmail.com
Fri Aug 1 23:55:59 PDT 2008

Hi Eli,

Eli Friedman wrote:
> Hmm, I don't have any low-level comments, but I'm wondering about a few things.
> First off, and I guess the most important bit, is how you're planning
> to deal with the C++ cast/declaration ambiguity.  This ambiguity
> affects a lot of the places which are testing ahead for a type, so
> adding code that's looking ahead only as far as the end of the type
> seems like a temporary step at best.  I'm not saying that this patch
> is necessarily the wrong way to go (I really have no clue how I'd go
> about implementing the ambiguity resolution performantly), but I want
> to make sure you have the next step planned so that you don't end up
> making extra work for yourself.

The parser needs a way to know whether it's standing in front of a type 
or not. The "look ahead" code that I added is 
Parser::isTokenStreamTypeName() which only parses ahead of scope 
specifiers, so that calling isTokenStreamTypeName() can check either "x" 
or "foo::bar::x". This is useful in general and no matter how exactly 
the C++ cast/declaration ambiguity gets resolved, I expect 
isTokenStreamTypeName to still be needed.

> This is a more of a side-issue, but would it be worthwhile to make the
> parser keep track of enough information to implement  isTypeName
> itself?  It's a relatively large burden on anyone who wants to write
> an Action implementation to be required to keep track of enough
> information to figure out the answer to this question, especially for
> C++, and having the parser use different implementations of identifier
> resolution depending on whether we're using Sema or not seems bad.
> The obvious arguments against this are that it's sort of duplicating
> code from Sema, and it might affect performance for the normal case of
> using Sema.  That said, it seems worth considering anyway if we really
> expect people to be writing their own Action implementations.

It's a large burden indeed but I'm not sure it's a good idea to move the 
burden to the parser (as you said, it's going to overlap with Sema).
I think that a reasonable compromise is MinimalAction which only 
contains the type checking functionality; other Action implementers can 
copy from/extend it.


More information about the cfe-dev mailing list