aboutsummaryrefslogtreecommitdiff
path: root/lib/Parse/ParseDecl.cpp
diff options
context:
space:
mode:
authorDouglas Gregor <dgregor@apple.com>2009-02-25 19:37:18 +0000
committerDouglas Gregor <dgregor@apple.com>2009-02-25 19:37:18 +0000
commit39a8de10c18365bde7062d8959b7ed525449c561 (patch)
tree0de42dd5a33f1dce18647222a5802e6f14fce250 /lib/Parse/ParseDecl.cpp
parent0096acf421c4609ce7f43e8b05f8c5ca866d4611 (diff)
Implement parsing of nested-name-specifiers that involve template-ids, e.g.,
std::vector<int>::allocator_type When we parse a template-id that names a type, it will become either a template-id annotation (which is a parsed representation of a template-id that has not yet been through semantic analysis) or a typename annotation (where semantic analysis has resolved the template-id to an actual type), depending on the context. We only produce a type in contexts where we know that we only need type information, e.g., in a type specifier. Otherwise, we create a template-id annotation that can later be "upgraded" by transforming it into a typename annotation when the parser needs a type. This occurs, for example, when we've parsed "std::vector<int>" above and then see the '::' after it. However, it means that when writing something like this: template<> class Outer::Inner<int> { ... }; We have two tokens to represent Outer::Inner<int>: one token for the nested name specifier Outer::, and one template-id annotation token for Inner<int>, which will be passed to semantic analysis to define the class template specialization. Most of the churn in the template tests in this patch come from an improvement in our error recovery from ill-formed template-ids. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65467 91177308-0d34-0410-b5e6-96231b3b80d8
Diffstat (limited to 'lib/Parse/ParseDecl.cpp')
-rw-r--r--lib/Parse/ParseDecl.cpp63
1 files changed, 36 insertions, 27 deletions
diff --git a/lib/Parse/ParseDecl.cpp b/lib/Parse/ParseDecl.cpp
index 6e68b20fa5..bdd352f341 100644
--- a/lib/Parse/ParseDecl.cpp
+++ b/lib/Parse/ParseDecl.cpp
@@ -558,21 +558,8 @@ void Parser::ParseDeclarationSpecifiers(DeclSpec &DS,
TypeTy *TypeRep = Actions.getTypeName(*Tok.getIdentifierInfo(),
Tok.getLocation(), CurScope);
- if (TypeRep == 0 && getLang().CPlusPlus && NextToken().is(tok::less)) {
- // If we have a template name, annotate the token and try again.
- DeclTy *Template = 0;
- if (TemplateNameKind TNK =
- Actions.isTemplateName(*Tok.getIdentifierInfo(), CurScope,
- Template)) {
- AnnotateTemplateIdToken(Template, TNK, 0);
- continue;
- }
- }
-
if (TypeRep == 0)
goto DoneWithDeclSpec;
-
-
// C++: If the identifier is actually the name of the class type
// being defined and the next token is a '(', then this is a
@@ -610,6 +597,25 @@ void Parser::ParseDeclarationSpecifiers(DeclSpec &DS,
// If a type specifier follows, it will be diagnosed elsewhere.
continue;
}
+
+ // type-name
+ case tok::annot_template_id: {
+ TemplateIdAnnotation *TemplateId
+ = static_cast<TemplateIdAnnotation *>(Tok.getAnnotationValue());
+ if (TemplateId->Kind != TNK_Class_template) {
+ // This template-id does not refer to a type name, so we're
+ // done with the type-specifiers.
+ goto DoneWithDeclSpec;
+ }
+
+ // Turn the template-id annotation token into a type annotation
+ // token, then try again to parse it as a type-specifier.
+ if (AnnotateTemplateIdTokenAsType())
+ DS.SetTypeSpecError();
+
+ continue;
+ }
+
// GNU attributes support.
case tok::kw___attribute:
DS.AddAttributes(ParseAttributes());
@@ -1749,7 +1755,7 @@ void Parser::ParseDeclaratorInternal(Declarator &D,
/// operator-function-id
/// conversion-function-id [TODO]
/// '~' class-name
-/// template-id [TODO]
+/// template-id
///
void Parser::ParseDirectDeclarator(Declarator &D) {
DeclaratorScopeObj DeclScopeObj(*this, D.getCXXScopeSpec());
@@ -1768,21 +1774,9 @@ void Parser::ParseDirectDeclarator(Declarator &D) {
if (Tok.is(tok::identifier)) {
assert(Tok.getIdentifierInfo() && "Not an identifier?");
- // If this identifier is followed by a '<', we may have a template-id.
- DeclTy *Template;
- Action::TemplateNameKind TNK;
- if (getLang().CPlusPlus && NextToken().is(tok::less) &&
- (TNK = Actions.isTemplateName(*Tok.getIdentifierInfo(),
- CurScope, Template))) {
- IdentifierInfo *II = Tok.getIdentifierInfo();
- AnnotateTemplateIdToken(Template, TNK, 0);
- // FIXME: Set the declarator to a template-id. How? I don't
- // know... for now, just use the identifier.
- D.SetIdentifier(II, Tok.getLocation());
- }
// If this identifier is the name of the current class, it's a
// constructor name.
- else if (Actions.isCurrentClassName(*Tok.getIdentifierInfo(),CurScope)){
+ if (Actions.isCurrentClassName(*Tok.getIdentifierInfo(),CurScope)){
D.setConstructor(Actions.getTypeName(*Tok.getIdentifierInfo(),
Tok.getLocation(), CurScope),
Tok.getLocation());
@@ -1791,6 +1785,21 @@ void Parser::ParseDirectDeclarator(Declarator &D) {
D.SetIdentifier(Tok.getIdentifierInfo(), Tok.getLocation());
ConsumeToken();
goto PastIdentifier;
+ } else if (Tok.is(tok::annot_template_id)) {
+ TemplateIdAnnotation *TemplateId
+ = static_cast<TemplateIdAnnotation *>(Tok.getAnnotationValue());
+
+ // FIXME: Could this template-id name a constructor?
+
+ // FIXME: This is an egregious hack, where we silently ignore
+ // the specialization (which should be a function template
+ // specialization name) and use the name instead. This hack
+ // will go away when we have support for function
+ // specializations.
+ D.SetIdentifier(TemplateId->Name, Tok.getLocation());
+ TemplateId->Destroy();
+ ConsumeToken();
+ goto PastIdentifier;
} else if (Tok.is(tok::kw_operator)) {
SourceLocation OperatorLoc = Tok.getLocation();
SourceLocation EndLoc;