[cfe-commits] r58913 - in /cfe/trunk: Driver/PrintParserCallbacks.cpp include/clang/Basic/DiagnosticKinds.def include/clang/Parse/Action.h include/clang/Parse/DeclSpec.h include/clang/Parse/Parser.h lib/Parse/MinimalAction.cpp lib/Parse/ParseDecl.cpp lib/Parse/ParseDeclCXX.cpp lib/Parse/ParseExpr.cpp lib/Parse/ParseExprCXX.cpp lib/Parse/ParseTentative.cpp lib/Parse/Parser.cpp lib/Sema/Sema.h lib/Sema/SemaDecl.cpp lib/Sema/SemaDeclCXX.cpp lib/Sema/SemaExpr.cpp test/Lexer/cxx0x_keyword.cpp

[Douglas Gregor]

On Nov 8, 2008, at 11:45 AM, Argiris Kirtzidis wrote:

> Author: akirtzidis
> Date: Sat Nov  8 10:45:02 2008
> New Revision: 58913
>
> URL: http://llvm.org/viewvc/llvm-project?rev=58913&view=rev
> Log:
> Implement support for C++ nested-name-specifiers ('foo::bar::x') in  
> the Parser side.
> No Sema functionality change, just the signatures of the Action/Sema  
> methods.

Great!

> +  /// isTokenUnqualifiedId - True if token is the start of C++  
> unqualified-id
> +  /// or an identifier in C.
> +  ///
> +  ///       unqualified-id:
> +  ///         identifier
> +  /// [C++]   operator-function-id
> +  /// [C++]   conversion-function-id
> +  /// [C++]   '~' class-name
> +  /// [C++]   template-id      [TODO]
> +  ///
> +  bool isTokenUnqualifiedId() const {
> +    return Tok.is(tok::identifier)  ||   // identifier or template-id
> +           Tok.is(tok::kw_operator) ||   // operator/conversion- 
> function-id or
> +                                         // template-id
> +           (Tok.is(tok::tilde) && getLang().CPlusPlus); // '~'  
> class-name
> +  }

This works because a qualified-id will already have been annotated, so  
the token we see would be a annot_cxxscope or annot_qualtype, right?

> +      // If the next token is the name of the class type that the C+ 
> + scope
> +      // denotes, followed by a '(', then this is a constructor  
> declaration.
> +      // We're done with the decl-specifiers.
> +      if  
> (Actions.isCurrentClassName(*NextToken().getIdentifierInfo(),
> +                                     CurScope, &SS) &&
> +          GetLookAheadToken(2).is(tok::l_paren))
> +        goto DoneWithDeclSpec;
>

This won't parse constructors like

	((C::C))(int, float) {
	}

properly, right? I think the '&&  
GetLookAheadToken(2).is(tok::l_paren)' needs to be removed.

> -bool Parser::isTypeSpecifierQualifier() const {
> +bool Parser::isTypeSpecifierQualifier() {
> +  // Annotate typenames and C++ scope specifiers.
> +  TryAnnotateTypeOrScopeToken();
> +
>   switch (Tok.getKind()) {
>   default: return false;
>     // GNU attributes support.
> @@ -1092,21 +1153,23 @@
>   case tok::kw_const:
>   case tok::kw_volatile:
>   case tok::kw_restrict:
> +
> +    // typedef-name
> +  case tok::annot_qualtypename:
>     return true;
>
>     // GNU ObjC bizarre protocol extension: <proto1,proto2> with  
> implicit 'id'.
>   case tok::less:
>     return getLang().ObjC1;
> -
> -    // typedef-name
> -  case tok::identifier:
> -    return Actions.isTypeName(*Tok.getIdentifierInfo(), CurScope) ! 
> = 0;
>   }
> }

Interesting. So we'll no longer see identifiers for typedef-names,  
because they'll all be resolved to annot_qualtypename tokens?

In this case, should we be concerned that  
TryAnnotateTypeOrScopeToken() will turn an identifier into a type,  
when that identifier was actually meant to, e.g., introduce a new  
name? I see that you avoided this issue within the declarator parsing  
code (with TryAnnotateScopeToken), so I guess we'll just do that same  
thing wherever there might be an issue.

>
> +///         conversion-function-id                [TODO]

And we don't handle this because... ah, because even though we can  
parse a conversion-function-id with ParseConversionFunctionId, we  
don't have a way to do name lookup on it yet. Looks like that's my  
problem to deal with :)

> +///         '~' class-name                        [TODO]

Same issue here; this ball's in my court.

Thanks! Moving on to the Sema bits now...

   - Doug