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

[Chris Lattner]

On Aug 1, 2008, at 3:43 PM, Eli Friedman wrote:

> On Fri, Aug 1, 2008 at 12:39 PM, Argiris Kirtzidis  
> <akyrtzi at gmail.com> wrote:
>> Hi,
>>
>> For the next chapter of the C++ support saga, I've implemented
>> nested-name-specifier support ("foo::bar::").
>
> 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.

You mean the "most vexing parse" issue?  I think that we will have to  
do tentative parsing + backtracking for the general case.  With luck,  
there will be common cases that we can disambiguate early to avoid the  
cost of backtracking, but I don't know enough about that area to know  
if that will actually be possible in practice.

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

I don't think this is practical unfortunately.  In the full generality  
of C++, you have to do a ton of semantic analysis to be able to handle  
this.  For example:

T<int>::y

If T is some template, you need to know all about members of T to know  
if Y is a variable or type.  Also, T could be partially specialized on  
int, so you need to handle partial specialization and a bunch of other  
stuff to handle this.  Pragmatically, I don't think we should worry  
about -parse-noop for C++.

Following up with my previous email to Argiris about scoped lookup, my  
(again, based on intuition, not the spec) idea of how this would work  
is that the parser would call:

   ActOnIdentifier("T")

... which returns a decl for the template.  It would then see the less  
than, call an action to determine if the decl is a template or not (if  
not, '<' is "operator<").  Assuming it is a template, it would parse  
the template args, calling "act on template args" with them.  This  
would produce a new decl, one for T<int> which Sema would lazily  
create if needed and handle partial specialization.  The parser would  
then see ::Y and then call the "lookup 'y' in decl" action, which  
returns yet-another-decl, which is either a type or variable etc.

This doesn't require backtracking or anything crazy in the parser, but  
it *does* rely on the actions module to keep a large subset of  
information held in the AST just to be able to parse.  I don't see a  
way around this though.

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

Yes it is.  In practice, I don't think -parse-noop will work very well  
(if at all) for C++.  I expect that most clients parsing C++ will end  
up using the AST.

-Chris