[cfe-dev] [PATCH] C++ nested-name-specifier (Parser)
akyrtzi at gmail.com
Fri Aug 1 23:55:59 PDT 2008
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