2008-12-02 07:54:00 +08:00
|
|
|
//===--- ParseTemplate.cpp - Template Parsing -----------------------------===//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This file implements parsing of C++ templates.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "clang/Parse/Parser.h"
|
2009-01-29 13:15:15 +08:00
|
|
|
#include "clang/Parse/ParseDiagnostic.h"
|
2008-12-02 07:54:00 +08:00
|
|
|
#include "clang/Parse/DeclSpec.h"
|
|
|
|
#include "clang/Parse/Scope.h"
|
2009-02-10 02:46:07 +08:00
|
|
|
#include "AstGuard.h"
|
2008-12-02 07:54:00 +08:00
|
|
|
using namespace clang;
|
|
|
|
|
2009-02-18 07:15:12 +08:00
|
|
|
/// \brief Parse a template declaration or an explicit specialization.
|
|
|
|
///
|
|
|
|
/// Template declarations include one or more template parameter lists
|
|
|
|
/// and either the function or class template declaration. Explicit
|
|
|
|
/// specializations contain one or more 'template < >' prefixes
|
|
|
|
/// followed by a (possibly templated) declaration. Since the
|
|
|
|
/// syntactic form of both features is nearly identical, we parse all
|
|
|
|
/// of the template headers together and let semantic analysis sort
|
|
|
|
/// the declarations from the explicit specializations.
|
2008-12-02 07:54:00 +08:00
|
|
|
///
|
|
|
|
/// template-declaration: [C++ temp]
|
|
|
|
/// 'export'[opt] 'template' '<' template-parameter-list '>' declaration
|
2009-02-18 07:15:12 +08:00
|
|
|
///
|
|
|
|
/// explicit-specialization: [ C++ temp.expl.spec]
|
|
|
|
/// 'template' '<' '>' declaration
|
2009-03-29 03:18:32 +08:00
|
|
|
Parser::DeclPtrTy
|
2009-03-26 08:52:18 +08:00
|
|
|
Parser::ParseTemplateDeclarationOrSpecialization(unsigned Context,
|
|
|
|
AccessSpecifier AS) {
|
2008-12-02 07:54:00 +08:00
|
|
|
assert((Tok.is(tok::kw_export) || Tok.is(tok::kw_template)) &&
|
|
|
|
"Token does not start a template declaration.");
|
|
|
|
|
2008-12-24 10:52:09 +08:00
|
|
|
// Enter template-parameter scope.
|
|
|
|
ParseScope TemplateParmScope(this, Scope::TemplateParamScope);
|
|
|
|
|
|
|
|
// Parse multiple levels of template headers within this template
|
|
|
|
// parameter scope, e.g.,
|
|
|
|
//
|
|
|
|
// template<typename T>
|
|
|
|
// template<typename U>
|
|
|
|
// class A<T>::B { ... };
|
|
|
|
//
|
|
|
|
// We parse multiple levels non-recursively so that we can build a
|
|
|
|
// single data structure containing all of the template parameter
|
2009-02-18 07:15:12 +08:00
|
|
|
// lists to easily differentiate between the case above and:
|
2008-12-24 10:52:09 +08:00
|
|
|
//
|
|
|
|
// template<typename T>
|
|
|
|
// class A {
|
|
|
|
// template<typename U> class B;
|
|
|
|
// };
|
|
|
|
//
|
|
|
|
// In the first case, the action for declaring A<T>::B receives
|
|
|
|
// both template parameter lists. In the second case, the action for
|
|
|
|
// defining A<T>::B receives just the inner template parameter list
|
|
|
|
// (and retrieves the outer template parameter list from its
|
|
|
|
// context).
|
|
|
|
TemplateParameterLists ParamLists;
|
|
|
|
do {
|
|
|
|
// Consume the 'export', if any.
|
|
|
|
SourceLocation ExportLoc;
|
|
|
|
if (Tok.is(tok::kw_export)) {
|
|
|
|
ExportLoc = ConsumeToken();
|
|
|
|
}
|
|
|
|
|
|
|
|
// Consume the 'template', which should be here.
|
|
|
|
SourceLocation TemplateLoc;
|
|
|
|
if (Tok.is(tok::kw_template)) {
|
|
|
|
TemplateLoc = ConsumeToken();
|
|
|
|
} else {
|
2008-12-02 07:54:00 +08:00
|
|
|
Diag(Tok.getLocation(), diag::err_expected_template);
|
2009-03-29 03:18:32 +08:00
|
|
|
return DeclPtrTy();
|
2008-12-02 07:54:00 +08:00
|
|
|
}
|
|
|
|
|
2008-12-24 10:52:09 +08:00
|
|
|
// Parse the '<' template-parameter-list '>'
|
|
|
|
SourceLocation LAngleLoc, RAngleLoc;
|
|
|
|
TemplateParameterList TemplateParams;
|
|
|
|
ParseTemplateParameters(ParamLists.size(), TemplateParams, LAngleLoc,
|
|
|
|
RAngleLoc);
|
2008-12-02 08:41:28 +08:00
|
|
|
|
2008-12-24 10:52:09 +08:00
|
|
|
ParamLists.push_back(
|
|
|
|
Actions.ActOnTemplateParameterList(ParamLists.size(), ExportLoc,
|
|
|
|
TemplateLoc, LAngleLoc,
|
|
|
|
&TemplateParams[0],
|
|
|
|
TemplateParams.size(), RAngleLoc));
|
|
|
|
} while (Tok.is(tok::kw_export) || Tok.is(tok::kw_template));
|
|
|
|
|
|
|
|
// Parse the actual template declaration.
|
2009-03-30 00:50:03 +08:00
|
|
|
|
|
|
|
// FIXME: This accepts template<typename x> int y;
|
|
|
|
// FIXME: Converting DeclGroupPtr to DeclPtr like this is an insanely gruesome
|
|
|
|
// hack, will bring up on cfe-dev.
|
|
|
|
DeclGroupPtrTy DG = ParseDeclarationOrFunctionDefinition(&ParamLists, AS);
|
|
|
|
return DeclPtrTy::make(DG.get());
|
2008-12-02 07:54:00 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/// ParseTemplateParameters - Parses a template-parameter-list enclosed in
|
2009-02-05 03:02:06 +08:00
|
|
|
/// angle brackets. Depth is the depth of this template-parameter-list, which
|
|
|
|
/// is the number of template headers directly enclosing this template header.
|
|
|
|
/// TemplateParams is the current list of template parameters we're building.
|
|
|
|
/// The template parameter we parse will be added to this list. LAngleLoc and
|
|
|
|
/// RAngleLoc will receive the positions of the '<' and '>', respectively,
|
|
|
|
/// that enclose this template parameter list.
|
2008-12-24 10:52:09 +08:00
|
|
|
bool Parser::ParseTemplateParameters(unsigned Depth,
|
|
|
|
TemplateParameterList &TemplateParams,
|
|
|
|
SourceLocation &LAngleLoc,
|
|
|
|
SourceLocation &RAngleLoc) {
|
2008-12-02 07:54:00 +08:00
|
|
|
// Get the template parameter list.
|
|
|
|
if(!Tok.is(tok::less)) {
|
|
|
|
Diag(Tok.getLocation(), diag::err_expected_less_after) << "template";
|
|
|
|
return false;
|
|
|
|
}
|
2008-12-24 10:52:09 +08:00
|
|
|
LAngleLoc = ConsumeToken();
|
2008-12-02 07:54:00 +08:00
|
|
|
|
|
|
|
// Try to parse the template parameter list.
|
2008-12-24 10:52:09 +08:00
|
|
|
if (Tok.is(tok::greater))
|
|
|
|
RAngleLoc = ConsumeToken();
|
|
|
|
else if(ParseTemplateParameterList(Depth, TemplateParams)) {
|
2008-12-02 07:54:00 +08:00
|
|
|
if(!Tok.is(tok::greater)) {
|
|
|
|
Diag(Tok.getLocation(), diag::err_expected_greater);
|
|
|
|
return false;
|
|
|
|
}
|
2008-12-24 10:52:09 +08:00
|
|
|
RAngleLoc = ConsumeToken();
|
2008-12-02 07:54:00 +08:00
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// ParseTemplateParameterList - Parse a template parameter list. If
|
|
|
|
/// the parsing fails badly (i.e., closing bracket was left out), this
|
|
|
|
/// will try to put the token stream in a reasonable position (closing
|
|
|
|
/// a statement, etc.) and return false.
|
|
|
|
///
|
|
|
|
/// template-parameter-list: [C++ temp]
|
|
|
|
/// template-parameter
|
|
|
|
/// template-parameter-list ',' template-parameter
|
2008-12-24 10:52:09 +08:00
|
|
|
bool
|
|
|
|
Parser::ParseTemplateParameterList(unsigned Depth,
|
|
|
|
TemplateParameterList &TemplateParams) {
|
2008-12-02 07:54:00 +08:00
|
|
|
while(1) {
|
2009-03-29 03:18:32 +08:00
|
|
|
if (DeclPtrTy TmpParam
|
2008-12-24 10:52:09 +08:00
|
|
|
= ParseTemplateParameter(Depth, TemplateParams.size())) {
|
|
|
|
TemplateParams.push_back(TmpParam);
|
|
|
|
} else {
|
2008-12-02 07:54:00 +08:00
|
|
|
// If we failed to parse a template parameter, skip until we find
|
|
|
|
// a comma or closing brace.
|
|
|
|
SkipUntil(tok::comma, tok::greater, true, true);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Did we find a comma or the end of the template parmeter list?
|
|
|
|
if(Tok.is(tok::comma)) {
|
|
|
|
ConsumeToken();
|
|
|
|
} else if(Tok.is(tok::greater)) {
|
|
|
|
// Don't consume this... that's done by template parser.
|
|
|
|
break;
|
|
|
|
} else {
|
|
|
|
// Somebody probably forgot to close the template. Skip ahead and
|
|
|
|
// try to get out of the expression. This error is currently
|
|
|
|
// subsumed by whatever goes on in ParseTemplateParameter.
|
|
|
|
// TODO: This could match >>, and it would be nice to avoid those
|
|
|
|
// silly errors with template <vec<T>>.
|
|
|
|
// Diag(Tok.getLocation(), diag::err_expected_comma_greater);
|
|
|
|
SkipUntil(tok::greater, true, true);
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// ParseTemplateParameter - Parse a template-parameter (C++ [temp.param]).
|
|
|
|
///
|
|
|
|
/// template-parameter: [C++ temp.param]
|
|
|
|
/// type-parameter
|
|
|
|
/// parameter-declaration
|
|
|
|
///
|
|
|
|
/// type-parameter: (see below)
|
|
|
|
/// 'class' identifier[opt]
|
|
|
|
/// 'class' identifier[opt] '=' type-id
|
|
|
|
/// 'typename' identifier[opt]
|
|
|
|
/// 'typename' identifier[opt] '=' type-id
|
|
|
|
/// 'template' '<' template-parameter-list '>' 'class' identifier[opt]
|
|
|
|
/// 'template' '<' template-parameter-list '>' 'class' identifier[opt] = id-expression
|
2009-03-29 03:18:32 +08:00
|
|
|
Parser::DeclPtrTy
|
2008-12-24 10:52:09 +08:00
|
|
|
Parser::ParseTemplateParameter(unsigned Depth, unsigned Position) {
|
2009-01-05 07:51:17 +08:00
|
|
|
if(Tok.is(tok::kw_class) ||
|
|
|
|
(Tok.is(tok::kw_typename) &&
|
|
|
|
// FIXME: Next token has not been annotated!
|
2009-01-06 13:06:21 +08:00
|
|
|
NextToken().isNot(tok::annot_typename))) {
|
2008-12-24 10:52:09 +08:00
|
|
|
return ParseTypeParameter(Depth, Position);
|
2008-12-02 07:54:00 +08:00
|
|
|
}
|
2009-01-05 07:51:17 +08:00
|
|
|
|
|
|
|
if(Tok.is(tok::kw_template))
|
|
|
|
return ParseTemplateTemplateParameter(Depth, Position);
|
|
|
|
|
|
|
|
// If it's none of the above, then it must be a parameter declaration.
|
|
|
|
// NOTE: This will pick up errors in the closure of the template parameter
|
|
|
|
// list (e.g., template < ; Check here to implement >> style closures.
|
|
|
|
return ParseNonTypeTemplateParameter(Depth, Position);
|
2008-12-02 07:54:00 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/// ParseTypeParameter - Parse a template type parameter (C++ [temp.param]).
|
|
|
|
/// Other kinds of template parameters are parsed in
|
|
|
|
/// ParseTemplateTemplateParameter and ParseNonTypeTemplateParameter.
|
|
|
|
///
|
|
|
|
/// type-parameter: [C++ temp.param]
|
|
|
|
/// 'class' identifier[opt]
|
|
|
|
/// 'class' identifier[opt] '=' type-id
|
|
|
|
/// 'typename' identifier[opt]
|
|
|
|
/// 'typename' identifier[opt] '=' type-id
|
2009-03-29 03:18:32 +08:00
|
|
|
Parser::DeclPtrTy Parser::ParseTypeParameter(unsigned Depth, unsigned Position){
|
2008-12-02 08:41:28 +08:00
|
|
|
assert((Tok.is(tok::kw_class) || Tok.is(tok::kw_typename)) &&
|
|
|
|
"A type-parameter starts with 'class' or 'typename'");
|
|
|
|
|
|
|
|
// Consume the 'class' or 'typename' keyword.
|
|
|
|
bool TypenameKeyword = Tok.is(tok::kw_typename);
|
|
|
|
SourceLocation KeyLoc = ConsumeToken();
|
2008-12-02 07:54:00 +08:00
|
|
|
|
|
|
|
// Grab the template parameter name (if given)
|
2008-12-02 08:41:28 +08:00
|
|
|
SourceLocation NameLoc;
|
|
|
|
IdentifierInfo* ParamName = 0;
|
2008-12-02 07:54:00 +08:00
|
|
|
if(Tok.is(tok::identifier)) {
|
2008-12-02 08:41:28 +08:00
|
|
|
ParamName = Tok.getIdentifierInfo();
|
|
|
|
NameLoc = ConsumeToken();
|
2008-12-02 07:54:00 +08:00
|
|
|
} else if(Tok.is(tok::equal) || Tok.is(tok::comma) ||
|
|
|
|
Tok.is(tok::greater)) {
|
|
|
|
// Unnamed template parameter. Don't have to do anything here, just
|
|
|
|
// don't consume this token.
|
|
|
|
} else {
|
|
|
|
Diag(Tok.getLocation(), diag::err_expected_ident);
|
2009-03-29 03:18:32 +08:00
|
|
|
return DeclPtrTy();
|
2008-12-02 07:54:00 +08:00
|
|
|
}
|
|
|
|
|
2009-03-29 03:18:32 +08:00
|
|
|
DeclPtrTy TypeParam = Actions.ActOnTypeParameter(CurScope, TypenameKeyword,
|
|
|
|
KeyLoc, ParamName, NameLoc,
|
|
|
|
Depth, Position);
|
2008-12-02 08:41:28 +08:00
|
|
|
|
2008-12-02 07:54:00 +08:00
|
|
|
// Grab a default type id (if given).
|
|
|
|
if(Tok.is(tok::equal)) {
|
2008-12-02 08:41:28 +08:00
|
|
|
SourceLocation EqualLoc = ConsumeToken();
|
2009-02-11 03:49:53 +08:00
|
|
|
SourceLocation DefaultLoc = Tok.getLocation();
|
2009-02-19 01:45:20 +08:00
|
|
|
TypeResult DefaultType = ParseTypeName();
|
|
|
|
if (!DefaultType.isInvalid())
|
2009-02-11 03:49:53 +08:00
|
|
|
Actions.ActOnTypeParameterDefault(TypeParam, EqualLoc, DefaultLoc,
|
2009-02-19 01:45:20 +08:00
|
|
|
DefaultType.get());
|
2008-12-02 07:54:00 +08:00
|
|
|
}
|
|
|
|
|
2008-12-02 08:41:28 +08:00
|
|
|
return TypeParam;
|
2008-12-02 07:54:00 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/// ParseTemplateTemplateParameter - Handle the parsing of template
|
|
|
|
/// template parameters.
|
|
|
|
///
|
|
|
|
/// type-parameter: [C++ temp.param]
|
|
|
|
/// 'template' '<' template-parameter-list '>' 'class' identifier[opt]
|
|
|
|
/// 'template' '<' template-parameter-list '>' 'class' identifier[opt] = id-expression
|
2009-03-29 03:18:32 +08:00
|
|
|
Parser::DeclPtrTy
|
2008-12-24 10:52:09 +08:00
|
|
|
Parser::ParseTemplateTemplateParameter(unsigned Depth, unsigned Position) {
|
2008-12-02 07:54:00 +08:00
|
|
|
assert(Tok.is(tok::kw_template) && "Expected 'template' keyword");
|
|
|
|
|
|
|
|
// Handle the template <...> part.
|
|
|
|
SourceLocation TemplateLoc = ConsumeToken();
|
2008-12-24 10:52:09 +08:00
|
|
|
TemplateParameterList TemplateParams;
|
2009-02-07 06:42:48 +08:00
|
|
|
SourceLocation LAngleLoc, RAngleLoc;
|
2009-02-11 03:52:54 +08:00
|
|
|
{
|
|
|
|
ParseScope TemplateParmScope(this, Scope::TemplateParamScope);
|
|
|
|
if(!ParseTemplateParameters(Depth + 1, TemplateParams, LAngleLoc,
|
|
|
|
RAngleLoc)) {
|
2009-03-29 03:18:32 +08:00
|
|
|
return DeclPtrTy();
|
2009-02-11 03:52:54 +08:00
|
|
|
}
|
2008-12-02 07:54:00 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// Generate a meaningful error if the user forgot to put class before the
|
|
|
|
// identifier, comma, or greater.
|
|
|
|
if(!Tok.is(tok::kw_class)) {
|
|
|
|
Diag(Tok.getLocation(), diag::err_expected_class_before)
|
|
|
|
<< PP.getSpelling(Tok);
|
2009-03-29 03:18:32 +08:00
|
|
|
return DeclPtrTy();
|
2008-12-02 07:54:00 +08:00
|
|
|
}
|
|
|
|
SourceLocation ClassLoc = ConsumeToken();
|
|
|
|
|
|
|
|
// Get the identifier, if given.
|
2009-02-05 03:02:06 +08:00
|
|
|
SourceLocation NameLoc;
|
|
|
|
IdentifierInfo* ParamName = 0;
|
2008-12-02 07:54:00 +08:00
|
|
|
if(Tok.is(tok::identifier)) {
|
2009-02-05 03:02:06 +08:00
|
|
|
ParamName = Tok.getIdentifierInfo();
|
|
|
|
NameLoc = ConsumeToken();
|
2008-12-02 07:54:00 +08:00
|
|
|
} else if(Tok.is(tok::equal) || Tok.is(tok::comma) || Tok.is(tok::greater)) {
|
|
|
|
// Unnamed template parameter. Don't have to do anything here, just
|
|
|
|
// don't consume this token.
|
|
|
|
} else {
|
|
|
|
Diag(Tok.getLocation(), diag::err_expected_ident);
|
2009-03-29 03:18:32 +08:00
|
|
|
return DeclPtrTy();
|
2008-12-02 07:54:00 +08:00
|
|
|
}
|
|
|
|
|
2009-02-07 06:42:48 +08:00
|
|
|
TemplateParamsTy *ParamList =
|
|
|
|
Actions.ActOnTemplateParameterList(Depth, SourceLocation(),
|
|
|
|
TemplateLoc, LAngleLoc,
|
|
|
|
&TemplateParams[0],
|
|
|
|
TemplateParams.size(),
|
|
|
|
RAngleLoc);
|
|
|
|
|
2009-03-29 03:18:32 +08:00
|
|
|
Parser::DeclPtrTy Param
|
2009-02-11 03:49:53 +08:00
|
|
|
= Actions.ActOnTemplateTemplateParameter(CurScope, TemplateLoc,
|
|
|
|
ParamList, ParamName,
|
|
|
|
NameLoc, Depth, Position);
|
|
|
|
|
|
|
|
// Get the a default value, if given.
|
|
|
|
if (Tok.is(tok::equal)) {
|
|
|
|
SourceLocation EqualLoc = ConsumeToken();
|
|
|
|
OwningExprResult DefaultExpr = ParseCXXIdExpression();
|
|
|
|
if (DefaultExpr.isInvalid())
|
|
|
|
return Param;
|
|
|
|
else if (Param)
|
|
|
|
Actions.ActOnTemplateTemplateParameterDefault(Param, EqualLoc,
|
|
|
|
move(DefaultExpr));
|
|
|
|
}
|
|
|
|
|
|
|
|
return Param;
|
2008-12-02 07:54:00 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/// ParseNonTypeTemplateParameter - Handle the parsing of non-type
|
|
|
|
/// template parameters (e.g., in "template<int Size> class array;").
|
2008-12-19 03:37:40 +08:00
|
|
|
///
|
2008-12-02 07:54:00 +08:00
|
|
|
/// template-parameter:
|
|
|
|
/// ...
|
|
|
|
/// parameter-declaration
|
|
|
|
///
|
|
|
|
/// NOTE: It would be ideal to simply call out to ParseParameterDeclaration(),
|
|
|
|
/// but that didn't work out to well. Instead, this tries to recrate the basic
|
|
|
|
/// parsing of parameter declarations, but tries to constrain it for template
|
|
|
|
/// parameters.
|
2008-12-02 08:41:28 +08:00
|
|
|
/// FIXME: We need to make a ParseParameterDeclaration that works for
|
|
|
|
/// non-type template parameters and normal function parameters.
|
2009-03-29 03:18:32 +08:00
|
|
|
Parser::DeclPtrTy
|
2008-12-24 10:52:09 +08:00
|
|
|
Parser::ParseNonTypeTemplateParameter(unsigned Depth, unsigned Position) {
|
2008-12-02 08:41:28 +08:00
|
|
|
SourceLocation StartLoc = Tok.getLocation();
|
2008-12-02 07:54:00 +08:00
|
|
|
|
|
|
|
// Parse the declaration-specifiers (i.e., the type).
|
2008-12-02 08:41:28 +08:00
|
|
|
// FIXME: The type should probably be restricted in some way... Not all
|
2008-12-02 07:54:00 +08:00
|
|
|
// declarators (parts of declarators?) are accepted for parameters.
|
2008-12-02 08:41:28 +08:00
|
|
|
DeclSpec DS;
|
|
|
|
ParseDeclarationSpecifiers(DS);
|
2008-12-02 07:54:00 +08:00
|
|
|
|
|
|
|
// Parse this as a typename.
|
2008-12-02 08:41:28 +08:00
|
|
|
Declarator ParamDecl(DS, Declarator::TemplateParamContext);
|
|
|
|
ParseDeclarator(ParamDecl);
|
2009-01-05 09:24:05 +08:00
|
|
|
if (DS.getTypeSpecType() == DeclSpec::TST_unspecified && !DS.getTypeRep()) {
|
2008-12-02 07:54:00 +08:00
|
|
|
// This probably shouldn't happen - and it's more of a Sema thing, but
|
|
|
|
// basically we didn't parse the type name because we couldn't associate
|
|
|
|
// it with an AST node. we should just skip to the comma or greater.
|
|
|
|
// TODO: This is currently a placeholder for some kind of Sema Error.
|
|
|
|
Diag(Tok.getLocation(), diag::err_parse_error);
|
|
|
|
SkipUntil(tok::comma, tok::greater, true, true);
|
2009-03-29 03:18:32 +08:00
|
|
|
return DeclPtrTy();
|
2008-12-02 07:54:00 +08:00
|
|
|
}
|
|
|
|
|
2008-12-02 08:41:28 +08:00
|
|
|
// Create the parameter.
|
2009-03-29 03:18:32 +08:00
|
|
|
DeclPtrTy Param = Actions.ActOnNonTypeTemplateParameter(CurScope, ParamDecl,
|
|
|
|
Depth, Position);
|
2008-12-02 07:54:00 +08:00
|
|
|
|
2009-02-11 03:49:53 +08:00
|
|
|
// If there is a default value, parse it.
|
2009-01-05 09:24:05 +08:00
|
|
|
if (Tok.is(tok::equal)) {
|
2009-02-11 03:49:53 +08:00
|
|
|
SourceLocation EqualLoc = ConsumeToken();
|
|
|
|
|
|
|
|
// C++ [temp.param]p15:
|
|
|
|
// When parsing a default template-argument for a non-type
|
|
|
|
// template-parameter, the first non-nested > is taken as the
|
|
|
|
// end of the template-parameter-list rather than a greater-than
|
|
|
|
// operator.
|
|
|
|
GreaterThanIsOperatorScope G(GreaterThanIsOperator, false);
|
|
|
|
|
|
|
|
OwningExprResult DefaultArg = ParseAssignmentExpression();
|
|
|
|
if (DefaultArg.isInvalid())
|
|
|
|
SkipUntil(tok::comma, tok::greater, true, true);
|
|
|
|
else if (Param)
|
|
|
|
Actions.ActOnNonTypeTemplateParameterDefault(Param, EqualLoc,
|
|
|
|
move(DefaultArg));
|
2008-12-02 07:54:00 +08:00
|
|
|
}
|
|
|
|
|
2008-12-02 08:41:28 +08:00
|
|
|
return Param;
|
2008-12-02 07:54:00 +08:00
|
|
|
}
|
2008-12-19 03:37:40 +08:00
|
|
|
|
2009-02-18 07:15:12 +08:00
|
|
|
/// \brief Parses a template-id that after the template name has
|
|
|
|
/// already been parsed.
|
|
|
|
///
|
|
|
|
/// This routine takes care of parsing the enclosed template argument
|
|
|
|
/// list ('<' template-parameter-list [opt] '>') and placing the
|
|
|
|
/// results into a form that can be transferred to semantic analysis.
|
|
|
|
///
|
|
|
|
/// \param Template the template declaration produced by isTemplateName
|
|
|
|
///
|
|
|
|
/// \param TemplateNameLoc the source location of the template name
|
|
|
|
///
|
|
|
|
/// \param SS if non-NULL, the nested-name-specifier preceding the
|
|
|
|
/// template name.
|
|
|
|
///
|
|
|
|
/// \param ConsumeLastToken if true, then we will consume the last
|
|
|
|
/// token that forms the template-id. Otherwise, we will leave the
|
|
|
|
/// last token in the stream (e.g., so that it can be replaced with an
|
|
|
|
/// annotation token).
|
|
|
|
bool
|
2009-03-29 03:18:32 +08:00
|
|
|
Parser::ParseTemplateIdAfterTemplateName(DeclPtrTy Template,
|
2009-02-18 07:15:12 +08:00
|
|
|
SourceLocation TemplateNameLoc,
|
|
|
|
const CXXScopeSpec *SS,
|
|
|
|
bool ConsumeLastToken,
|
|
|
|
SourceLocation &LAngleLoc,
|
|
|
|
TemplateArgList &TemplateArgs,
|
|
|
|
TemplateArgIsTypeList &TemplateArgIsType,
|
|
|
|
TemplateArgLocationList &TemplateArgLocations,
|
|
|
|
SourceLocation &RAngleLoc) {
|
|
|
|
assert(Tok.is(tok::less) && "Must have already parsed the template-name");
|
|
|
|
|
|
|
|
// Consume the '<'.
|
|
|
|
LAngleLoc = ConsumeToken();
|
|
|
|
|
|
|
|
// Parse the optional template-argument-list.
|
|
|
|
bool Invalid = false;
|
|
|
|
{
|
|
|
|
GreaterThanIsOperatorScope G(GreaterThanIsOperator, false);
|
|
|
|
if (Tok.isNot(tok::greater))
|
|
|
|
Invalid = ParseTemplateArgumentList(TemplateArgs, TemplateArgIsType,
|
|
|
|
TemplateArgLocations);
|
|
|
|
|
|
|
|
if (Invalid) {
|
|
|
|
// Try to find the closing '>'.
|
|
|
|
SkipUntil(tok::greater, true, !ConsumeLastToken);
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-02-26 07:02:36 +08:00
|
|
|
if (Tok.isNot(tok::greater) && Tok.isNot(tok::greatergreater))
|
2009-02-18 07:15:12 +08:00
|
|
|
return true;
|
|
|
|
|
2009-02-26 07:02:36 +08:00
|
|
|
// Determine the location of the '>' or '>>'. Only consume this
|
|
|
|
// token if the caller asked us to.
|
2009-02-18 07:15:12 +08:00
|
|
|
RAngleLoc = Tok.getLocation();
|
|
|
|
|
2009-02-26 07:02:36 +08:00
|
|
|
if (Tok.is(tok::greatergreater)) {
|
Introduce code modification hints into the diagnostics system. When we
know how to recover from an error, we can attach a hint to the
diagnostic that states how to modify the code, which can be one of:
- Insert some new code (a text string) at a particular source
location
- Remove the code within a given range
- Replace the code within a given range with some new code (a text
string)
Right now, we use these hints to annotate diagnostic information. For
example, if one uses the '>>' in a template argument in C++98, as in
this code:
template<int I> class B { };
B<1000 >> 2> *b1;
we'll warn that the behavior will change in C++0x. The fix is to
insert parenthese, so we use code insertion annotations to illustrate
where the parentheses go:
test.cpp:10:10: warning: use of right-shift operator ('>>') in template
argument will require parentheses in C++0x
B<1000 >> 2> *b1;
^
( )
Use of these annotations is partially implemented for HTML
diagnostics, but it's not (yet) producing valid HTML, which may be
related to PR2386, so it has been #if 0'd out.
In this future, we could consider hooking this mechanism up to the
rewriter to actually try to fix these problems during compilation (or,
after a compilation whose only errors have fixes). For now, however, I
suggest that we use these code modification hints whenever we can, so
that we get better diagnostics now and will have better coverage when
we find better ways to use this information.
This also fixes PR3410 by placing the complaint about missing tokens
just after the previous token (rather than at the location of the next
token).
llvm-svn: 65570
2009-02-27 05:00:50 +08:00
|
|
|
if (!getLang().CPlusPlus0x) {
|
|
|
|
const char *ReplaceStr = "> >";
|
|
|
|
if (NextToken().is(tok::greater) || NextToken().is(tok::greatergreater))
|
|
|
|
ReplaceStr = "> > ";
|
|
|
|
|
|
|
|
Diag(Tok.getLocation(), diag::err_two_right_angle_brackets_need_space)
|
2009-02-28 01:53:17 +08:00
|
|
|
<< CodeModificationHint::CreateReplacement(
|
|
|
|
SourceRange(Tok.getLocation()), ReplaceStr);
|
Introduce code modification hints into the diagnostics system. When we
know how to recover from an error, we can attach a hint to the
diagnostic that states how to modify the code, which can be one of:
- Insert some new code (a text string) at a particular source
location
- Remove the code within a given range
- Replace the code within a given range with some new code (a text
string)
Right now, we use these hints to annotate diagnostic information. For
example, if one uses the '>>' in a template argument in C++98, as in
this code:
template<int I> class B { };
B<1000 >> 2> *b1;
we'll warn that the behavior will change in C++0x. The fix is to
insert parenthese, so we use code insertion annotations to illustrate
where the parentheses go:
test.cpp:10:10: warning: use of right-shift operator ('>>') in template
argument will require parentheses in C++0x
B<1000 >> 2> *b1;
^
( )
Use of these annotations is partially implemented for HTML
diagnostics, but it's not (yet) producing valid HTML, which may be
related to PR2386, so it has been #if 0'd out.
In this future, we could consider hooking this mechanism up to the
rewriter to actually try to fix these problems during compilation (or,
after a compilation whose only errors have fixes). For now, however, I
suggest that we use these code modification hints whenever we can, so
that we get better diagnostics now and will have better coverage when
we find better ways to use this information.
This also fixes PR3410 by placing the complaint about missing tokens
just after the previous token (rather than at the location of the next
token).
llvm-svn: 65570
2009-02-27 05:00:50 +08:00
|
|
|
}
|
2009-02-26 07:02:36 +08:00
|
|
|
|
|
|
|
Tok.setKind(tok::greater);
|
|
|
|
if (!ConsumeLastToken) {
|
|
|
|
// Since we're not supposed to consume the '>>' token, we need
|
|
|
|
// to insert a second '>' token after the first.
|
|
|
|
PP.EnterToken(Tok);
|
|
|
|
}
|
|
|
|
} else if (ConsumeLastToken)
|
2009-02-18 07:15:12 +08:00
|
|
|
ConsumeToken();
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
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.
llvm-svn: 65467
2009-02-26 03:37:18 +08:00
|
|
|
/// \brief Replace the tokens that form a simple-template-id with an
|
|
|
|
/// annotation token containing the complete template-id.
|
|
|
|
///
|
|
|
|
/// The first token in the stream must be the name of a template that
|
|
|
|
/// is followed by a '<'. This routine will parse the complete
|
|
|
|
/// simple-template-id and replace the tokens with a single annotation
|
|
|
|
/// token with one of two different kinds: if the template-id names a
|
|
|
|
/// type (and \p AllowTypeAnnotation is true), the annotation token is
|
|
|
|
/// a type annotation that includes the optional nested-name-specifier
|
|
|
|
/// (\p SS). Otherwise, the annotation token is a template-id
|
|
|
|
/// annotation that does not include the optional
|
|
|
|
/// nested-name-specifier.
|
|
|
|
///
|
|
|
|
/// \param Template the declaration of the template named by the first
|
|
|
|
/// token (an identifier), as returned from \c Action::isTemplateName().
|
|
|
|
///
|
|
|
|
/// \param TemplateNameKind the kind of template that \p Template
|
|
|
|
/// refers to, as returned from \c Action::isTemplateName().
|
|
|
|
///
|
|
|
|
/// \param SS if non-NULL, the nested-name-specifier that precedes
|
|
|
|
/// this template name.
|
|
|
|
///
|
|
|
|
/// \param TemplateKWLoc if valid, specifies that this template-id
|
|
|
|
/// annotation was preceded by the 'template' keyword and gives the
|
|
|
|
/// location of that keyword. If invalid (the default), then this
|
|
|
|
/// template-id was not preceded by a 'template' keyword.
|
|
|
|
///
|
|
|
|
/// \param AllowTypeAnnotation if true (the default), then a
|
|
|
|
/// simple-template-id that refers to a class template, template
|
|
|
|
/// template parameter, or other template that produces a type will be
|
|
|
|
/// replaced with a type annotation token. Otherwise, the
|
|
|
|
/// simple-template-id is always replaced with a template-id
|
|
|
|
/// annotation token.
|
2009-03-29 03:18:32 +08:00
|
|
|
void Parser::AnnotateTemplateIdToken(DeclPtrTy Template, TemplateNameKind TNK,
|
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.
llvm-svn: 65467
2009-02-26 03:37:18 +08:00
|
|
|
const CXXScopeSpec *SS,
|
|
|
|
SourceLocation TemplateKWLoc,
|
|
|
|
bool AllowTypeAnnotation) {
|
2008-12-19 03:37:40 +08:00
|
|
|
assert(getLang().CPlusPlus && "Can only annotate template-ids in C++");
|
|
|
|
assert(Template && Tok.is(tok::identifier) && NextToken().is(tok::less) &&
|
|
|
|
"Parser isn't at the beginning of a template-id");
|
|
|
|
|
|
|
|
// Consume the template-name.
|
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.
llvm-svn: 65467
2009-02-26 03:37:18 +08:00
|
|
|
IdentifierInfo *Name = Tok.getIdentifierInfo();
|
2008-12-19 03:37:40 +08:00
|
|
|
SourceLocation TemplateNameLoc = ConsumeToken();
|
|
|
|
|
2009-02-18 07:15:12 +08:00
|
|
|
// Parse the enclosed template argument list.
|
|
|
|
SourceLocation LAngleLoc, RAngleLoc;
|
2009-02-10 03:34:22 +08:00
|
|
|
TemplateArgList TemplateArgs;
|
|
|
|
TemplateArgIsTypeList TemplateArgIsType;
|
2009-02-10 07:23:08 +08:00
|
|
|
TemplateArgLocationList TemplateArgLocations;
|
2009-02-18 07:15:12 +08:00
|
|
|
bool Invalid = ParseTemplateIdAfterTemplateName(Template, TemplateNameLoc,
|
|
|
|
SS, false, LAngleLoc,
|
|
|
|
TemplateArgs,
|
|
|
|
TemplateArgIsType,
|
|
|
|
TemplateArgLocations,
|
|
|
|
RAngleLoc);
|
2009-02-10 07:23:08 +08:00
|
|
|
|
2009-02-18 07:15:12 +08:00
|
|
|
ASTTemplateArgsPtr TemplateArgsPtr(Actions, &TemplateArgs[0],
|
|
|
|
&TemplateArgIsType[0],
|
|
|
|
TemplateArgs.size());
|
2008-12-19 03:37:40 +08:00
|
|
|
|
2009-02-18 07:15:12 +08:00
|
|
|
if (Invalid) // FIXME: How to recover from a broken template-id?
|
|
|
|
return;
|
2008-12-19 03:37:40 +08:00
|
|
|
|
2009-02-10 02:46:07 +08:00
|
|
|
// Build the annotation token.
|
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.
llvm-svn: 65467
2009-02-26 03:37:18 +08:00
|
|
|
if (TNK == TNK_Class_template && AllowTypeAnnotation) {
|
2009-02-18 07:15:12 +08:00
|
|
|
Action::TypeResult Type
|
|
|
|
= Actions.ActOnClassTemplateId(Template, TemplateNameLoc,
|
|
|
|
LAngleLoc, TemplateArgsPtr,
|
|
|
|
&TemplateArgLocations[0],
|
|
|
|
RAngleLoc, SS);
|
|
|
|
if (Type.isInvalid()) // FIXME: better recovery?
|
|
|
|
return;
|
|
|
|
|
|
|
|
Tok.setKind(tok::annot_typename);
|
|
|
|
Tok.setAnnotationValue(Type.get());
|
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.
llvm-svn: 65467
2009-02-26 03:37:18 +08:00
|
|
|
if (SS && SS->isNotEmpty())
|
|
|
|
Tok.setLocation(SS->getBeginLoc());
|
|
|
|
else if (TemplateKWLoc.isValid())
|
|
|
|
Tok.setLocation(TemplateKWLoc);
|
|
|
|
else
|
|
|
|
Tok.setLocation(TemplateNameLoc);
|
2009-02-18 07:15:12 +08:00
|
|
|
} else {
|
2009-02-10 02:46:07 +08:00
|
|
|
// This is a function template. We'll be building a template-id
|
|
|
|
// annotation token.
|
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.
llvm-svn: 65467
2009-02-26 03:37:18 +08:00
|
|
|
Tok.setKind(tok::annot_template_id);
|
2009-02-10 02:46:07 +08:00
|
|
|
TemplateIdAnnotation *TemplateId
|
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.
llvm-svn: 65467
2009-02-26 03:37:18 +08:00
|
|
|
= TemplateIdAnnotation::Allocate(TemplateArgs.size());
|
2009-02-10 02:46:07 +08:00
|
|
|
TemplateId->TemplateNameLoc = TemplateNameLoc;
|
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.
llvm-svn: 65467
2009-02-26 03:37:18 +08:00
|
|
|
TemplateId->Name = Name;
|
2009-03-29 03:18:32 +08:00
|
|
|
TemplateId->Template = Template.getAs<void*>();
|
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.
llvm-svn: 65467
2009-02-26 03:37:18 +08:00
|
|
|
TemplateId->Kind = TNK;
|
2009-02-10 02:46:07 +08:00
|
|
|
TemplateId->LAngleLoc = LAngleLoc;
|
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.
llvm-svn: 65467
2009-02-26 03:37:18 +08:00
|
|
|
TemplateId->RAngleLoc = RAngleLoc;
|
|
|
|
void **Args = TemplateId->getTemplateArgs();
|
|
|
|
bool *ArgIsType = TemplateId->getTemplateArgIsType();
|
|
|
|
SourceLocation *ArgLocs = TemplateId->getTemplateArgLocations();
|
|
|
|
for (unsigned Arg = 0, ArgEnd = TemplateArgs.size(); Arg != ArgEnd; ++Arg) {
|
2009-02-10 02:46:07 +08:00
|
|
|
Args[Arg] = TemplateArgs[Arg];
|
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.
llvm-svn: 65467
2009-02-26 03:37:18 +08:00
|
|
|
ArgIsType[Arg] = TemplateArgIsType[Arg];
|
|
|
|
ArgLocs[Arg] = TemplateArgLocations[Arg];
|
|
|
|
}
|
2009-02-10 02:46:07 +08:00
|
|
|
Tok.setAnnotationValue(TemplateId);
|
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.
llvm-svn: 65467
2009-02-26 03:37:18 +08:00
|
|
|
if (TemplateKWLoc.isValid())
|
|
|
|
Tok.setLocation(TemplateKWLoc);
|
|
|
|
else
|
|
|
|
Tok.setLocation(TemplateNameLoc);
|
|
|
|
|
|
|
|
TemplateArgsPtr.release();
|
2009-02-10 02:46:07 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// Common fields for the annotation token
|
2008-12-19 03:37:40 +08:00
|
|
|
Tok.setAnnotationEndLoc(RAngleLoc);
|
|
|
|
|
|
|
|
// In case the tokens were cached, have Preprocessor replace them with the
|
|
|
|
// annotation token.
|
|
|
|
PP.AnnotateCachedTokens(Tok);
|
|
|
|
}
|
|
|
|
|
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.
llvm-svn: 65467
2009-02-26 03:37:18 +08:00
|
|
|
/// \brief Replaces a template-id annotation token with a type
|
|
|
|
/// annotation token.
|
|
|
|
///
|
|
|
|
/// \returns true if there was an error, false otherwise.
|
|
|
|
bool Parser::AnnotateTemplateIdTokenAsType(const CXXScopeSpec *SS) {
|
|
|
|
assert(Tok.is(tok::annot_template_id) && "Requires template-id tokens");
|
|
|
|
|
|
|
|
TemplateIdAnnotation *TemplateId
|
|
|
|
= static_cast<TemplateIdAnnotation *>(Tok.getAnnotationValue());
|
|
|
|
assert(TemplateId->Kind == TNK_Class_template &&
|
|
|
|
"Only works for class templates");
|
|
|
|
|
|
|
|
ASTTemplateArgsPtr TemplateArgsPtr(Actions,
|
|
|
|
TemplateId->getTemplateArgs(),
|
|
|
|
TemplateId->getTemplateArgIsType(),
|
|
|
|
TemplateId->NumArgs);
|
|
|
|
|
|
|
|
Action::TypeResult Type
|
2009-03-29 03:18:32 +08:00
|
|
|
= Actions.ActOnClassTemplateId(DeclPtrTy::make(TemplateId->Template),
|
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.
llvm-svn: 65467
2009-02-26 03:37:18 +08:00
|
|
|
TemplateId->TemplateNameLoc,
|
|
|
|
TemplateId->LAngleLoc,
|
|
|
|
TemplateArgsPtr,
|
|
|
|
TemplateId->getTemplateArgLocations(),
|
|
|
|
TemplateId->RAngleLoc, SS);
|
|
|
|
if (Type.isInvalid()) {
|
|
|
|
// FIXME: better recovery?
|
|
|
|
ConsumeToken();
|
|
|
|
TemplateId->Destroy();
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Create the new "type" annotation token.
|
|
|
|
Tok.setKind(tok::annot_typename);
|
|
|
|
Tok.setAnnotationValue(Type.get());
|
|
|
|
if (SS && SS->isNotEmpty()) // it was a C++ qualified type name.
|
|
|
|
Tok.setLocation(SS->getBeginLoc());
|
|
|
|
|
|
|
|
// We might be backtracking, in which case we need to replace the
|
|
|
|
// template-id annotation token with the type annotation within the
|
|
|
|
// set of cached tokens. That way, we won't try to form the same
|
|
|
|
// class template specialization again.
|
|
|
|
PP.ReplaceLastTokenWithAnnotation(Tok);
|
|
|
|
TemplateId->Destroy();
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2008-12-19 03:37:40 +08:00
|
|
|
/// ParseTemplateArgument - Parse a C++ template argument (C++ [temp.names]).
|
|
|
|
///
|
|
|
|
/// template-argument: [C++ 14.2]
|
|
|
|
/// assignment-expression
|
|
|
|
/// type-id
|
|
|
|
/// id-expression
|
2009-02-10 03:34:22 +08:00
|
|
|
void *Parser::ParseTemplateArgument(bool &ArgIsType) {
|
2009-02-10 02:46:07 +08:00
|
|
|
// C++ [temp.arg]p2:
|
|
|
|
// In a template-argument, an ambiguity between a type-id and an
|
|
|
|
// expression is resolved to a type-id, regardless of the form of
|
|
|
|
// the corresponding template-parameter.
|
|
|
|
//
|
|
|
|
// Therefore, we initially try to parse a type-id.
|
2009-02-10 08:53:15 +08:00
|
|
|
if (isCXXTypeId(TypeIdAsTemplateArgument)) {
|
2009-02-10 03:34:22 +08:00
|
|
|
ArgIsType = true;
|
2009-02-19 01:45:20 +08:00
|
|
|
TypeResult TypeArg = ParseTypeName();
|
|
|
|
if (TypeArg.isInvalid())
|
|
|
|
return 0;
|
|
|
|
return TypeArg.get();
|
2009-02-10 02:46:07 +08:00
|
|
|
}
|
|
|
|
|
2009-02-10 07:23:08 +08:00
|
|
|
OwningExprResult ExprArg = ParseAssignmentExpression();
|
|
|
|
if (ExprArg.isInvalid() || !ExprArg.get())
|
2009-02-10 03:34:22 +08:00
|
|
|
return 0;
|
2009-02-10 02:46:07 +08:00
|
|
|
|
2009-02-10 03:34:22 +08:00
|
|
|
ArgIsType = false;
|
|
|
|
return ExprArg.release();
|
2008-12-19 03:37:40 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/// ParseTemplateArgumentList - Parse a C++ template-argument-list
|
|
|
|
/// (C++ [temp.names]). Returns true if there was an error.
|
|
|
|
///
|
|
|
|
/// template-argument-list: [C++ 14.2]
|
|
|
|
/// template-argument
|
|
|
|
/// template-argument-list ',' template-argument
|
2009-02-10 03:34:22 +08:00
|
|
|
bool
|
|
|
|
Parser::ParseTemplateArgumentList(TemplateArgList &TemplateArgs,
|
2009-02-10 07:23:08 +08:00
|
|
|
TemplateArgIsTypeList &TemplateArgIsType,
|
|
|
|
TemplateArgLocationList &TemplateArgLocations) {
|
2008-12-19 03:37:40 +08:00
|
|
|
while (true) {
|
2009-02-10 03:34:22 +08:00
|
|
|
bool IsType = false;
|
2009-02-10 07:23:08 +08:00
|
|
|
SourceLocation Loc = Tok.getLocation();
|
2009-02-10 03:34:22 +08:00
|
|
|
void *Arg = ParseTemplateArgument(IsType);
|
|
|
|
if (Arg) {
|
|
|
|
TemplateArgs.push_back(Arg);
|
|
|
|
TemplateArgIsType.push_back(IsType);
|
2009-02-10 07:23:08 +08:00
|
|
|
TemplateArgLocations.push_back(Loc);
|
2009-02-10 03:34:22 +08:00
|
|
|
} else {
|
2008-12-19 03:37:40 +08:00
|
|
|
SkipUntil(tok::comma, tok::greater, true, true);
|
|
|
|
return true;
|
|
|
|
}
|
2009-02-10 03:34:22 +08:00
|
|
|
|
2008-12-19 03:37:40 +08:00
|
|
|
// If the next token is a comma, consume it and keep reading
|
|
|
|
// arguments.
|
|
|
|
if (Tok.isNot(tok::comma)) break;
|
|
|
|
|
|
|
|
// Consume the comma.
|
|
|
|
ConsumeToken();
|
|
|
|
}
|
|
|
|
|
2009-02-26 07:02:36 +08:00
|
|
|
return Tok.isNot(tok::greater) && Tok.isNot(tok::greatergreater);
|
2008-12-19 03:37:40 +08:00
|
|
|
}
|
|
|
|
|