maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/lib/Sema/SemaTemplateInstantiateDecl...

5208 lines
204 KiB
C++
Raw Normal View History

Refactor instantiation of declarations within a template into a much cleaner visitor framework. Added a visitor for declarations, which is quite similar to the visitor for statatements. llvm-svn: 67104
2009-03-18 05:15:40 +08:00
//===--- SemaTemplateInstantiateDecl.cpp - C++ Template Decl Instantiation ===/
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//===----------------------------------------------------------------------===/
//
// This file implements C++ template instantiation for declarations.
//
//===----------------------------------------------------------------------===/
Split out a header to hold APIs meant for the Sema implementation from Sema.h. Clients of Sema don't need to know (for example) the list of diagnostics we support. llvm-svn: 112093
2010-08-26 06:03:47 +08:00
#include "clang/Sema/SemaInternal.h"
Make sure that CodeGen sees template instantiations. llvm-svn: 72433
2009-05-27 04:50:29 +08:00
#include "clang/AST/ASTConsumer.h"
Refactor instantiation of declarations within a template into a much cleaner visitor framework. Added a visitor for declarations, which is quite similar to the visitor for statatements. llvm-svn: 67104
2009-03-18 05:15:40 +08:00
#include "clang/AST/ASTContext.h"
Emit an update record if we instantiate the definition of a function template specialization from a module. (This can also happen for function template specializations in PCHs if they're instantiated eagerly, because they're constexpr or have a deduced return type.) llvm-svn: 204547
2014-03-23 07:33:22 +08:00
#include "clang/AST/ASTMutationListener.h"
Refactor instantiation of declarations within a template into a much cleaner visitor framework. Added a visitor for declarations, which is quite similar to the visitor for statatements. llvm-svn: 67104
2009-03-18 05:15:40 +08:00
#include "clang/AST/DeclTemplate.h"
#include "clang/AST/DeclVisitor.h"
Implement a framework for the delay of arbitrary diagnostics within templates. So delay access-control diagnostics when (for example) the target of a friend declaration is a specific specialization of a template. I was surprised to find that this was required for an access-controlled selfhost. llvm-svn: 99383
2010-03-24 13:22:00 +08:00
#include "clang/AST/DependentDiagnostic.h"
Refactor instantiation of declarations within a template into a much cleaner visitor framework. Added a visitor for declarations, which is quite similar to the visitor for statatements. llvm-svn: 67104
2009-03-18 05:15:40 +08:00
#include "clang/AST/Expr.h"
Rework the way we handle template instantiation for implicitly-generated AST nodes. We previously built instantiated nodes for each of these AST nodes, then passed them on to Sema, which was not prepared to see already-type-checked nodes (see PR5755). In some places, we had ugly workarounds to try to avoid re-type-checking (e.g., in VarDecl initializer instantiation). Now, we skip implicitly-generated nodes when performing instantiation, preferring instead to build just the AST nodes that directly reflect what was written in the source code. This has several advantages: - We don't need to instantiate anything that doesn't have a direct correlation to the source code, so we can have better location information. - Semantic analysis sees the same thing at template instantiation time that it would see for a non-template. - At least one ugly hack (VarDecl initializers) goes away. Fixes PR5755. llvm-svn: 91218
2009-12-13 02:16:41 +08:00
#include "clang/AST/ExprCXX.h"
Maintain type source information for functions through template instantiation. Based on a patch by Enea Zaffanella! I found a way to reduce some of the redundancy between TreeTransform's "standard" FunctionProtoType transformation and TemplateInstantiator's override, and I killed off the old SubstFunctionType by adding type source info for the last cases where we were creating FunctionDecls without TSI (at least that get passed through template instantiation). llvm-svn: 98252
2010-03-11 17:03:00 +08:00
#include "clang/AST/TypeLoc.h"
P0217R3: template instantiation support for decomposition declarations. llvm-svn: 278458
2016-08-12 09:55:21 +08:00
#include "clang/Sema/Initialization.h"
Sort all of Clang's files under 'lib', and fix up the broken headers uncovered. This required manually correcting all of the incorrect main-module headers I could find, and running the new llvm/utils/sort_includes.py script over the files. I also manually added quite a few missing headers that were uncovered by shuffling the order or moving headers up to be main-module-headers. llvm-svn: 169237
2012-12-04 17:13:33 +08:00
#include "clang/Sema/Lookup.h"
#include "clang/Sema/PrettyDeclStackTrace.h"
#include "clang/Sema/Template.h"
Refactor instantiation of declarations within a template into a much cleaner visitor framework. Added a visitor for declarations, which is quite similar to the visitor for statatements. llvm-svn: 67104
2009-03-18 05:15:40 +08:00
using namespace clang;
Sema: Instantiate local class and their members appropriately We would fail to instantiate them when the surrounding function was instantiated. Instantiate the class and add it's members to the list of pending instantiations, they should be resolved when we are finished with the function's body. This fixes PR9685. llvm-svn: 195827
2013-11-27 16:20:38 +08:00
static bool isDeclWithinFunction(const Decl *D) {
const DeclContext *DC = D->getDeclContext();
if (DC->isFunctionOrMethod())
return true;
if (DC->isRecord())
return cast<CXXRecordDecl>(DC)->isLocalClass();
return false;
}
Don't forget to substitute into the qualifier when instantiating the definition of a member function of a class template that is defined outside the template. This substitution can actually fail in some weird cases. llvm-svn: 220085
2014-10-18 04:37:29 +08:00
template<typename DeclT>
static bool SubstQualifier(Sema &SemaRef, const DeclT *OldDecl, DeclT *NewDecl,
const MultiLevelTemplateArgumentList &TemplateArgs) {
Use NestedNameSpecifierLoc within out-of-line variables, function, and tag definitions. Also, add support for template instantiation of NestedNameSpecifierLocs. llvm-svn: 126470
2011-02-25 10:25:35 +08:00
if (!OldDecl->getQualifierLoc())
return false;
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Don't forget to substitute into the qualifier when instantiating the definition of a member function of a class template that is defined outside the template. This substitution can actually fail in some weird cases. llvm-svn: 220085
2014-10-18 04:37:29 +08:00
assert((NewDecl->getFriendObjectKind() ||
!OldDecl->getLexicalDeclContext()->isDependentContext()) &&
"non-friend with qualified name defined in dependent context");
Sema::ContextRAII SavedContext(
SemaRef,
const_cast<DeclContext *>(NewDecl->getFriendObjectKind()
? NewDecl->getLexicalDeclContext()
: OldDecl->getLexicalDeclContext()));
Use NestedNameSpecifierLoc within out-of-line variables, function, and tag definitions. Also, add support for template instantiation of NestedNameSpecifierLocs. llvm-svn: 126470
2011-02-25 10:25:35 +08:00
NestedNameSpecifierLoc NewQualifierLoc
Don't forget to substitute into the qualifier when instantiating the definition of a member function of a class template that is defined outside the template. This substitution can actually fail in some weird cases. llvm-svn: 220085
2014-10-18 04:37:29 +08:00
= SemaRef.SubstNestedNameSpecifierLoc(OldDecl->getQualifierLoc(),
TemplateArgs);
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Use NestedNameSpecifierLoc within out-of-line variables, function, and tag definitions. Also, add support for template instantiation of NestedNameSpecifierLocs. llvm-svn: 126470
2011-02-25 10:25:35 +08:00
if (!NewQualifierLoc)
Remember declaration scope qualifiers in the AST. Imposes no memory overhead on unqualified declarations. Patch by Enea Zaffanella! Minimal adjustments: allocate the ExtInfo nodes with the ASTContext and delete them during Destroy(). I audited a bunch of Destroy methods at the same time, to ensure that the correct teardown was being done. llvm-svn: 98540
2010-03-15 18:12:16 +08:00
return true;
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Use NestedNameSpecifierLoc within out-of-line variables, function, and tag definitions. Also, add support for template instantiation of NestedNameSpecifierLocs. llvm-svn: 126470
2011-02-25 10:25:35 +08:00
NewDecl->setQualifierInfo(NewQualifierLoc);
Remember declaration scope qualifiers in the AST. Imposes no memory overhead on unqualified declarations. Patch by Enea Zaffanella! Minimal adjustments: allocate the ExtInfo nodes with the ASTContext and delete them during Destroy(). I audited a bunch of Destroy methods at the same time, to ensure that the correct teardown was being done. llvm-svn: 98540
2010-03-15 18:12:16 +08:00
return false;
}
Don't forget to substitute into the qualifier when instantiating the definition of a member function of a class template that is defined outside the template. This substitution can actually fail in some weird cases. llvm-svn: 220085
2014-10-18 04:37:29 +08:00
bool TemplateDeclInstantiator::SubstQualifier(const DeclaratorDecl *OldDecl,
DeclaratorDecl *NewDecl) {
return ::SubstQualifier(SemaRef, OldDecl, NewDecl, TemplateArgs);
}
Remember declaration scope qualifiers in the AST. Imposes no memory overhead on unqualified declarations. Patch by Enea Zaffanella! Minimal adjustments: allocate the ExtInfo nodes with the ASTContext and delete them during Destroy(). I audited a bunch of Destroy methods at the same time, to ensure that the correct teardown was being done. llvm-svn: 98540
2010-03-15 18:12:16 +08:00
bool TemplateDeclInstantiator::SubstQualifier(const TagDecl *OldDecl,
TagDecl *NewDecl) {
Don't forget to substitute into the qualifier when instantiating the definition of a member function of a class template that is defined outside the template. This substitution can actually fail in some weird cases. llvm-svn: 220085
2014-10-18 04:37:29 +08:00
return ::SubstQualifier(SemaRef, OldDecl, NewDecl, TemplateArgs);
Remember declaration scope qualifiers in the AST. Imposes no memory overhead on unqualified declarations. Patch by Enea Zaffanella! Minimal adjustments: allocate the ExtInfo nodes with the ASTContext and delete them during Destroy(). I audited a bunch of Destroy methods at the same time, to ensure that the correct teardown was being done. llvm-svn: 98540
2010-03-15 18:12:16 +08:00
}
Instantiate dependent attributes when instantiating templates. llvm-svn: 148592
2012-01-21 06:37:06 +08:00
// Include attribute instantiation code.
#include "clang/Sema/AttrTemplateInstantiate.inc"
Handle alignas(foo...) pack expansions. llvm-svn: 175875
2013-02-22 16:32:16 +08:00
static void instantiateDependentAlignedAttr(
Sema &S, const MultiLevelTemplateArgumentList &TemplateArgs,
const AlignedAttr *Aligned, Decl *New, bool IsPackExpansion) {
if (Aligned->isAlignmentExpr()) {
// The alignment expression is a constant expression.
[NFC, Scoped Enum] Convert Sema::ExpressionEvaluationContext into a scoped Enum - also replace direct equality checks against the ConstantEvaluated enumerator with isConstantEvaluted(), in anticipation of adding finer granularity to the various ConstantEvaluated contexts and reinstating certain restrictions on where lambda expressions can occur in C++17. - update the clang tablegen backend that uses these Enumerators, and add the relevant scope where needed. llvm-svn: 299316
2017-04-02 05:30:49 +08:00
EnterExpressionEvaluationContext Unevaluated(
S, Sema::ExpressionEvaluationContext::ConstantEvaluated);
Handle alignas(foo...) pack expansions. llvm-svn: 175875
2013-02-22 16:32:16 +08:00
ExprResult Result = S.SubstExpr(Aligned->getAlignmentExpr(), TemplateArgs);
if (!Result.isInvalid())
Refactoring. Remove release and take methods from ActionResult. Rename takeAs to getAs. llvm-svn: 209800
2014-05-29 18:55:11 +08:00
S.AddAlignedAttr(Aligned->getLocation(), New, Result.getAs<Expr>(),
Handle alignas(foo...) pack expansions. llvm-svn: 175875
2013-02-22 16:32:16 +08:00
Aligned->getSpellingListIndex(), IsPackExpansion);
} else {
TypeSourceInfo *Result = S.SubstType(Aligned->getAlignmentType(),
TemplateArgs, Aligned->getLocation(),
DeclarationName());
if (Result)
S.AddAlignedAttr(Aligned->getLocation(), New, Result,
Aligned->getSpellingListIndex(), IsPackExpansion);
}
}
static void instantiateDependentAlignedAttr(
Sema &S, const MultiLevelTemplateArgumentList &TemplateArgs,
const AlignedAttr *Aligned, Decl *New) {
if (!Aligned->isPackExpansion()) {
instantiateDependentAlignedAttr(S, TemplateArgs, Aligned, New, false);
return;
}
SmallVector<UnexpandedParameterPack, 2> Unexpanded;
if (Aligned->isAlignmentExpr())
S.collectUnexpandedParameterPacks(Aligned->getAlignmentExpr(),
Unexpanded);
else
S.collectUnexpandedParameterPacks(Aligned->getAlignmentType()->getTypeLoc(),
Unexpanded);
assert(!Unexpanded.empty() && "Pack expansion without parameter packs?");
// Determine whether we can expand this attribute pack yet.
bool Expand = true, RetainExpansion = false;
Optional<unsigned> NumExpansions;
// FIXME: Use the actual location of the ellipsis.
SourceLocation EllipsisLoc = Aligned->getLocation();
if (S.CheckParameterPacksForExpansion(EllipsisLoc, Aligned->getRange(),
Unexpanded, TemplateArgs, Expand,
RetainExpansion, NumExpansions))
return;
if (!Expand) {
Sema::ArgumentPackSubstitutionIndexRAII SubstIndex(S, -1);
instantiateDependentAlignedAttr(S, TemplateArgs, Aligned, New, true);
} else {
for (unsigned I = 0; I != *NumExpansions; ++I) {
Sema::ArgumentPackSubstitutionIndexRAII SubstIndex(S, I);
instantiateDependentAlignedAttr(S, TemplateArgs, Aligned, New, false);
}
}
}
Support the assume_aligned function attribute In addition to __builtin_assume_aligned, GCC also supports an assume_aligned attribute which specifies the alignment (and optional offset) of a function's return value. Here we implement support for the assume_aligned attribute by making use of the @llvm.assume intrinsic. llvm-svn: 218500
2014-09-26 13:04:30 +08:00
static void instantiateDependentAssumeAlignedAttr(
Sema &S, const MultiLevelTemplateArgumentList &TemplateArgs,
const AssumeAlignedAttr *Aligned, Decl *New) {
// The alignment expression is a constant expression.
[NFC, Scoped Enum] Convert Sema::ExpressionEvaluationContext into a scoped Enum - also replace direct equality checks against the ConstantEvaluated enumerator with isConstantEvaluted(), in anticipation of adding finer granularity to the various ConstantEvaluated contexts and reinstating certain restrictions on where lambda expressions can occur in C++17. - update the clang tablegen backend that uses these Enumerators, and add the relevant scope where needed. llvm-svn: 299316
2017-04-02 05:30:49 +08:00
EnterExpressionEvaluationContext Unevaluated(
S, Sema::ExpressionEvaluationContext::ConstantEvaluated);
Support the assume_aligned function attribute In addition to __builtin_assume_aligned, GCC also supports an assume_aligned attribute which specifies the alignment (and optional offset) of a function's return value. Here we implement support for the assume_aligned attribute by making use of the @llvm.assume intrinsic. llvm-svn: 218500
2014-09-26 13:04:30 +08:00
Expr *E, *OE = nullptr;
ExprResult Result = S.SubstExpr(Aligned->getAlignment(), TemplateArgs);
if (Result.isInvalid())
return;
E = Result.getAs<Expr>();
if (Aligned->getOffset()) {
Result = S.SubstExpr(Aligned->getOffset(), TemplateArgs);
if (Result.isInvalid())
return;
OE = Result.getAs<Expr>();
}
S.AddAssumeAlignedAttr(Aligned->getLocation(), New, E, OE,
Aligned->getSpellingListIndex());
}
Initial support for the align_value attribute This adds support for the align_value attribute. This attribute is supported by Intel's compiler (versions 14.0+), and several of my HPC users have requested support in Clang. It specifies an alignment assumption on the values to which a pointer points, and is used by numerical libraries to encourage efficient generation of vector code. Of course, we already have an aligned attribute that can specify enhanced alignment for a type, so why is this additional attribute important? The problem is that if you want to specify that an input array of T is, say, 64-byte aligned, you could try this: typedef double aligned_double attribute((aligned(64))); void foo(aligned_double *P) { double x = P[0]; // This is fine. double y = P[1]; // What alignment did those doubles have again? } the access here to P[1] causes problems. P was specified as a pointer to type aligned_double, and any object of type aligned_double must be 64-byte aligned. But if P[0] is 64-byte aligned, then P[1] cannot be, and this access causes undefined behavior. Getting round this problem requires a lot of awkward casting and hand-unrolling of loops, all of which is bad. With the align_value attribute, we can accomplish what we'd like in a well defined way: typedef double *aligned_double_ptr attribute((align_value(64))); void foo(aligned_double_ptr P) { double x = P[0]; // This is fine. double y = P[1]; // This is fine too. } This attribute does not create a new type (and so it not part of the type system), and so will only "propagate" through templates, auto, etc. by optimizer deduction after inlining. This seems consistent with Intel's implementation (thanks to Alexey for confirming the various Intel-compiler behaviors). As a final note, I would have chosen to call this aligned_value, not align_value, for better naming consistency with the aligned attribute, but I think it would be more useful to users to adopt Intel's name. llvm-svn: 218910
2014-10-03 05:21:25 +08:00
static void instantiateDependentAlignValueAttr(
Sema &S, const MultiLevelTemplateArgumentList &TemplateArgs,
const AlignValueAttr *Aligned, Decl *New) {
// The alignment expression is a constant expression.
[NFC, Scoped Enum] Convert Sema::ExpressionEvaluationContext into a scoped Enum - also replace direct equality checks against the ConstantEvaluated enumerator with isConstantEvaluted(), in anticipation of adding finer granularity to the various ConstantEvaluated contexts and reinstating certain restrictions on where lambda expressions can occur in C++17. - update the clang tablegen backend that uses these Enumerators, and add the relevant scope where needed. llvm-svn: 299316
2017-04-02 05:30:49 +08:00
EnterExpressionEvaluationContext Unevaluated(
S, Sema::ExpressionEvaluationContext::ConstantEvaluated);
Initial support for the align_value attribute This adds support for the align_value attribute. This attribute is supported by Intel's compiler (versions 14.0+), and several of my HPC users have requested support in Clang. It specifies an alignment assumption on the values to which a pointer points, and is used by numerical libraries to encourage efficient generation of vector code. Of course, we already have an aligned attribute that can specify enhanced alignment for a type, so why is this additional attribute important? The problem is that if you want to specify that an input array of T is, say, 64-byte aligned, you could try this: typedef double aligned_double attribute((aligned(64))); void foo(aligned_double *P) { double x = P[0]; // This is fine. double y = P[1]; // What alignment did those doubles have again? } the access here to P[1] causes problems. P was specified as a pointer to type aligned_double, and any object of type aligned_double must be 64-byte aligned. But if P[0] is 64-byte aligned, then P[1] cannot be, and this access causes undefined behavior. Getting round this problem requires a lot of awkward casting and hand-unrolling of loops, all of which is bad. With the align_value attribute, we can accomplish what we'd like in a well defined way: typedef double *aligned_double_ptr attribute((align_value(64))); void foo(aligned_double_ptr P) { double x = P[0]; // This is fine. double y = P[1]; // This is fine too. } This attribute does not create a new type (and so it not part of the type system), and so will only "propagate" through templates, auto, etc. by optimizer deduction after inlining. This seems consistent with Intel's implementation (thanks to Alexey for confirming the various Intel-compiler behaviors). As a final note, I would have chosen to call this aligned_value, not align_value, for better naming consistency with the aligned attribute, but I think it would be more useful to users to adopt Intel's name. llvm-svn: 218910
2014-10-03 05:21:25 +08:00
ExprResult Result = S.SubstExpr(Aligned->getAlignment(), TemplateArgs);
if (!Result.isInvalid())
S.AddAlignValueAttr(Aligned->getLocation(), New, Result.getAs<Expr>(),
Aligned->getSpellingListIndex());
}
Clang changes for alloc_align attribute GCC has the alloc_align attribute, which is similar to assume_aligned, except the attribute's parameter is the index of the integer parameter that needs aligning to. Differential Revision: https://reviews.llvm.org/D29599 llvm-svn: 299117
2017-03-31 05:48:55 +08:00
static void instantiateDependentAllocAlignAttr(
Sema &S, const MultiLevelTemplateArgumentList &TemplateArgs,
const AllocAlignAttr *Align, Decl *New) {
Expr *Param = IntegerLiteral::Create(
S.getASTContext(), llvm::APInt(64, Align->getParamIndex()),
S.getASTContext().UnsignedLongLongTy, Align->getLocation());
S.AddAllocAlignAttr(Align->getLocation(), New, Param,
Align->getSpellingListIndex());
}
Add the diagnose_if attribute to clang. `diagnose_if` can be used to have clang emit either warnings or errors for function calls that meet user-specified conditions. For example: ``` constexpr int foo(int a) __attribute__((diagnose_if(a > 10, "configurations with a > 10 are " "expensive.", "warning"))); int f1 = foo(9); int f2 = foo(10); // warning: configuration with a > 10 are expensive. int f3 = foo(f2); ``` It currently only emits diagnostics in cases where the condition is guaranteed to always be true. So, the following code will emit no warnings: ``` constexpr int bar(int a) { foo(a); return 0; } constexpr int i = bar(10); ``` We hope to support optionally emitting diagnostics for cases like that (and emitting runtime checks) in the future. Release notes will appear shortly. :) Differential Revision: https://reviews.llvm.org/D27424 llvm-svn: 291418
2017-01-09 12:12:14 +08:00
static Expr *instantiateDependentFunctionAttrCondition(
Add a new attribute 'enable_if' which can be used to control overload resolution based on the values of the function arguments at the call site. llvm-svn: 198996
2014-01-11 10:50:57 +08:00
Sema &S, const MultiLevelTemplateArgumentList &TemplateArgs,
Add the diagnose_if attribute to clang. `diagnose_if` can be used to have clang emit either warnings or errors for function calls that meet user-specified conditions. For example: ``` constexpr int foo(int a) __attribute__((diagnose_if(a > 10, "configurations with a > 10 are " "expensive.", "warning"))); int f1 = foo(9); int f2 = foo(10); // warning: configuration with a > 10 are expensive. int f3 = foo(f2); ``` It currently only emits diagnostics in cases where the condition is guaranteed to always be true. So, the following code will emit no warnings: ``` constexpr int bar(int a) { foo(a); return 0; } constexpr int i = bar(10); ``` We hope to support optionally emitting diagnostics for cases like that (and emitting runtime checks) in the future. Release notes will appear shortly. :) Differential Revision: https://reviews.llvm.org/D27424 llvm-svn: 291418
2017-01-09 12:12:14 +08:00
const Attr *A, Expr *OldCond, const Decl *Tmpl, FunctionDecl *New) {
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
Expr *Cond = nullptr;
Add a new attribute 'enable_if' which can be used to control overload resolution based on the values of the function arguments at the call site. llvm-svn: 198996
2014-01-11 10:50:57 +08:00
{
Add the diagnose_if attribute to clang. `diagnose_if` can be used to have clang emit either warnings or errors for function calls that meet user-specified conditions. For example: ``` constexpr int foo(int a) __attribute__((diagnose_if(a > 10, "configurations with a > 10 are " "expensive.", "warning"))); int f1 = foo(9); int f2 = foo(10); // warning: configuration with a > 10 are expensive. int f3 = foo(f2); ``` It currently only emits diagnostics in cases where the condition is guaranteed to always be true. So, the following code will emit no warnings: ``` constexpr int bar(int a) { foo(a); return 0; } constexpr int i = bar(10); ``` We hope to support optionally emitting diagnostics for cases like that (and emitting runtime checks) in the future. Release notes will appear shortly. :) Differential Revision: https://reviews.llvm.org/D27424 llvm-svn: 291418
2017-01-09 12:12:14 +08:00
Sema::ContextRAII SwitchContext(S, New);
[NFC, Scoped Enum] Convert Sema::ExpressionEvaluationContext into a scoped Enum - also replace direct equality checks against the ConstantEvaluated enumerator with isConstantEvaluted(), in anticipation of adding finer granularity to the various ConstantEvaluated contexts and reinstating certain restrictions on where lambda expressions can occur in C++17. - update the clang tablegen backend that uses these Enumerators, and add the relevant scope where needed. llvm-svn: 299316
2017-04-02 05:30:49 +08:00
EnterExpressionEvaluationContext Unevaluated(
S, Sema::ExpressionEvaluationContext::ConstantEvaluated);
Add the diagnose_if attribute to clang. `diagnose_if` can be used to have clang emit either warnings or errors for function calls that meet user-specified conditions. For example: ``` constexpr int foo(int a) __attribute__((diagnose_if(a > 10, "configurations with a > 10 are " "expensive.", "warning"))); int f1 = foo(9); int f2 = foo(10); // warning: configuration with a > 10 are expensive. int f3 = foo(f2); ``` It currently only emits diagnostics in cases where the condition is guaranteed to always be true. So, the following code will emit no warnings: ``` constexpr int bar(int a) { foo(a); return 0; } constexpr int i = bar(10); ``` We hope to support optionally emitting diagnostics for cases like that (and emitting runtime checks) in the future. Release notes will appear shortly. :) Differential Revision: https://reviews.llvm.org/D27424 llvm-svn: 291418
2017-01-09 12:12:14 +08:00
ExprResult Result = S.SubstExpr(OldCond, TemplateArgs);
Add a new attribute 'enable_if' which can be used to control overload resolution based on the values of the function arguments at the call site. llvm-svn: 198996
2014-01-11 10:50:57 +08:00
if (Result.isInvalid())
Add the diagnose_if attribute to clang. `diagnose_if` can be used to have clang emit either warnings or errors for function calls that meet user-specified conditions. For example: ``` constexpr int foo(int a) __attribute__((diagnose_if(a > 10, "configurations with a > 10 are " "expensive.", "warning"))); int f1 = foo(9); int f2 = foo(10); // warning: configuration with a > 10 are expensive. int f3 = foo(f2); ``` It currently only emits diagnostics in cases where the condition is guaranteed to always be true. So, the following code will emit no warnings: ``` constexpr int bar(int a) { foo(a); return 0; } constexpr int i = bar(10); ``` We hope to support optionally emitting diagnostics for cases like that (and emitting runtime checks) in the future. Release notes will appear shortly. :) Differential Revision: https://reviews.llvm.org/D27424 llvm-svn: 291418
2017-01-09 12:12:14 +08:00
return nullptr;
Refactoring. Remove release and take methods from ActionResult. Rename takeAs to getAs. llvm-svn: 209800
2014-05-29 18:55:11 +08:00
Cond = Result.getAs<Expr>();
Add a new attribute 'enable_if' which can be used to control overload resolution based on the values of the function arguments at the call site. llvm-svn: 198996
2014-01-11 10:50:57 +08:00
}
[Sema] Fix a bug in enable_if condition instantiation. During template instantiation, we currently fall back to just calling Sema::SubstExpr for enable_if attributes that aren't value-dependent or type-dependent. Since Sema::SubstExpr strips off any implicit casts we've added to an expression, it's possible that this behavior will leave us with an enable_if condition that's just a DeclRefExpr. Conditions like that deeply confuse Sema::CheckEnableIf. llvm-svn: 287187
2016-11-17 09:33:54 +08:00
if (!Cond->isTypeDependent()) {
Add a new attribute 'enable_if' which can be used to control overload resolution based on the values of the function arguments at the call site. llvm-svn: 198996
2014-01-11 10:50:57 +08:00
ExprResult Converted = S.PerformContextuallyConvertToBool(Cond);
if (Converted.isInvalid())
Add the diagnose_if attribute to clang. `diagnose_if` can be used to have clang emit either warnings or errors for function calls that meet user-specified conditions. For example: ``` constexpr int foo(int a) __attribute__((diagnose_if(a > 10, "configurations with a > 10 are " "expensive.", "warning"))); int f1 = foo(9); int f2 = foo(10); // warning: configuration with a > 10 are expensive. int f3 = foo(f2); ``` It currently only emits diagnostics in cases where the condition is guaranteed to always be true. So, the following code will emit no warnings: ``` constexpr int bar(int a) { foo(a); return 0; } constexpr int i = bar(10); ``` We hope to support optionally emitting diagnostics for cases like that (and emitting runtime checks) in the future. Release notes will appear shortly. :) Differential Revision: https://reviews.llvm.org/D27424 llvm-svn: 291418
2017-01-09 12:12:14 +08:00
return nullptr;
Refactoring. Remove release and take methods from ActionResult. Rename takeAs to getAs. llvm-svn: 209800
2014-05-29 18:55:11 +08:00
Cond = Converted.get();
Add a new attribute 'enable_if' which can be used to control overload resolution based on the values of the function arguments at the call site. llvm-svn: 198996
2014-01-11 10:50:57 +08:00
}
SmallVector<PartialDiagnosticAt, 8> Diags;
Add the diagnose_if attribute to clang. `diagnose_if` can be used to have clang emit either warnings or errors for function calls that meet user-specified conditions. For example: ``` constexpr int foo(int a) __attribute__((diagnose_if(a > 10, "configurations with a > 10 are " "expensive.", "warning"))); int f1 = foo(9); int f2 = foo(10); // warning: configuration with a > 10 are expensive. int f3 = foo(f2); ``` It currently only emits diagnostics in cases where the condition is guaranteed to always be true. So, the following code will emit no warnings: ``` constexpr int bar(int a) { foo(a); return 0; } constexpr int i = bar(10); ``` We hope to support optionally emitting diagnostics for cases like that (and emitting runtime checks) in the future. Release notes will appear shortly. :) Differential Revision: https://reviews.llvm.org/D27424 llvm-svn: 291418
2017-01-09 12:12:14 +08:00
if (OldCond->isValueDependent() && !Cond->isValueDependent() &&
!Expr::isPotentialConstantExprUnevaluated(Cond, New, Diags)) {
S.Diag(A->getLocation(), diag::err_attr_cond_never_constant_expr) << A;
for (const auto &P : Diags)
S.Diag(P.first, P.second);
return nullptr;
Add a new attribute 'enable_if' which can be used to control overload resolution based on the values of the function arguments at the call site. llvm-svn: 198996
2014-01-11 10:50:57 +08:00
}
Add the diagnose_if attribute to clang. `diagnose_if` can be used to have clang emit either warnings or errors for function calls that meet user-specified conditions. For example: ``` constexpr int foo(int a) __attribute__((diagnose_if(a > 10, "configurations with a > 10 are " "expensive.", "warning"))); int f1 = foo(9); int f2 = foo(10); // warning: configuration with a > 10 are expensive. int f3 = foo(f2); ``` It currently only emits diagnostics in cases where the condition is guaranteed to always be true. So, the following code will emit no warnings: ``` constexpr int bar(int a) { foo(a); return 0; } constexpr int i = bar(10); ``` We hope to support optionally emitting diagnostics for cases like that (and emitting runtime checks) in the future. Release notes will appear shortly. :) Differential Revision: https://reviews.llvm.org/D27424 llvm-svn: 291418
2017-01-09 12:12:14 +08:00
return Cond;
}
Add a new attribute 'enable_if' which can be used to control overload resolution based on the values of the function arguments at the call site. llvm-svn: 198996
2014-01-11 10:50:57 +08:00
Add the diagnose_if attribute to clang. `diagnose_if` can be used to have clang emit either warnings or errors for function calls that meet user-specified conditions. For example: ``` constexpr int foo(int a) __attribute__((diagnose_if(a > 10, "configurations with a > 10 are " "expensive.", "warning"))); int f1 = foo(9); int f2 = foo(10); // warning: configuration with a > 10 are expensive. int f3 = foo(f2); ``` It currently only emits diagnostics in cases where the condition is guaranteed to always be true. So, the following code will emit no warnings: ``` constexpr int bar(int a) { foo(a); return 0; } constexpr int i = bar(10); ``` We hope to support optionally emitting diagnostics for cases like that (and emitting runtime checks) in the future. Release notes will appear shortly. :) Differential Revision: https://reviews.llvm.org/D27424 llvm-svn: 291418
2017-01-09 12:12:14 +08:00
static void instantiateDependentEnableIfAttr(
Sema &S, const MultiLevelTemplateArgumentList &TemplateArgs,
const EnableIfAttr *EIA, const Decl *Tmpl, FunctionDecl *New) {
Expr *Cond = instantiateDependentFunctionAttrCondition(
S, TemplateArgs, EIA, EIA->getCond(), Tmpl, New);
if (Cond)
New->addAttr(new (S.getASTContext()) EnableIfAttr(
EIA->getLocation(), S.getASTContext(), Cond, EIA->getMessage(),
EIA->getSpellingListIndex()));
}
static void instantiateDependentDiagnoseIfAttr(
Sema &S, const MultiLevelTemplateArgumentList &TemplateArgs,
const DiagnoseIfAttr *DIA, const Decl *Tmpl, FunctionDecl *New) {
Expr *Cond = instantiateDependentFunctionAttrCondition(
S, TemplateArgs, DIA, DIA->getCond(), Tmpl, New);
if (Cond)
New->addAttr(new (S.getASTContext()) DiagnoseIfAttr(
DIA->getLocation(), S.getASTContext(), Cond, DIA->getMessage(),
DIA->getDiagnosticType(), DIA->getArgDependent(), New,
DIA->getSpellingListIndex()));
Add a new attribute 'enable_if' which can be used to control overload resolution based on the values of the function arguments at the call site. llvm-svn: 198996
2014-01-11 10:50:57 +08:00
}
[cuda] Allow using integral non-type template parameters as launch_bounds attribute arguments. - Changed CUDALaunchBounds arguments from integers to Expr* so they can be saved in AST for instantiation. - Added support for template instantiation of launch_bounds attrubute. - Moved evaluation of launch_bounds arguments to NVPTXTargetCodeGenInfo:: SetTargetAttributes() where it can be done after template instantiation. - Added a warning on negative launch_bounds arguments. - Amended test cases. Differential Revision: http://reviews.llvm.org/D8985 llvm-svn: 235452
2015-04-22 06:55:54 +08:00
// Constructs and adds to New a new instance of CUDALaunchBoundsAttr using
// template A as the base and arguments from TemplateArgs.
static void instantiateDependentCUDALaunchBoundsAttr(
Sema &S, const MultiLevelTemplateArgumentList &TemplateArgs,
const CUDALaunchBoundsAttr &Attr, Decl *New) {
// The alignment expression is a constant expression.
[NFC, Scoped Enum] Convert Sema::ExpressionEvaluationContext into a scoped Enum - also replace direct equality checks against the ConstantEvaluated enumerator with isConstantEvaluted(), in anticipation of adding finer granularity to the various ConstantEvaluated contexts and reinstating certain restrictions on where lambda expressions can occur in C++17. - update the clang tablegen backend that uses these Enumerators, and add the relevant scope where needed. llvm-svn: 299316
2017-04-02 05:30:49 +08:00
EnterExpressionEvaluationContext Unevaluated(
S, Sema::ExpressionEvaluationContext::ConstantEvaluated);
[cuda] Allow using integral non-type template parameters as launch_bounds attribute arguments. - Changed CUDALaunchBounds arguments from integers to Expr* so they can be saved in AST for instantiation. - Added support for template instantiation of launch_bounds attrubute. - Moved evaluation of launch_bounds arguments to NVPTXTargetCodeGenInfo:: SetTargetAttributes() where it can be done after template instantiation. - Added a warning on negative launch_bounds arguments. - Amended test cases. Differential Revision: http://reviews.llvm.org/D8985 llvm-svn: 235452
2015-04-22 06:55:54 +08:00
ExprResult Result = S.SubstExpr(Attr.getMaxThreads(), TemplateArgs);
if (Result.isInvalid())
return;
Expr *MaxThreads = Result.getAs<Expr>();
Expr *MinBlocks = nullptr;
if (Attr.getMinBlocks()) {
Result = S.SubstExpr(Attr.getMinBlocks(), TemplateArgs);
if (Result.isInvalid())
return;
MinBlocks = Result.getAs<Expr>();
}
S.AddLaunchBoundsAttr(Attr.getLocation(), New, MaxThreads, MinBlocks,
Attr.getSpellingListIndex());
}
Fix for PR8901: attribute "mode" rejected for enums and dependent types. Allow "mode" attribute for enum types, except for vector modes, for compatibility with GCC. Support "mode" attribute with dependent types. Differential Revision: http://reviews.llvm.org/D16219 llvm-svn: 259497
2016-02-02 21:50:39 +08:00
static void
instantiateDependentModeAttr(Sema &S,
const MultiLevelTemplateArgumentList &TemplateArgs,
const ModeAttr &Attr, Decl *New) {
S.AddModeAttr(Attr.getRange(), New, Attr.getMode(),
Attr.getSpellingListIndex(), /*InInstantiation=*/true);
}
[OPENMP 4.0] Parsing/sema analysis for 'simdlen' clause in 'declare simd' construct. OpenMP 4.0 defines '#pragma omp declare simd' construct that may have associated 'simdlen' clause with constant positive expression as an argument: simdlen(<const_expr>) Patch adds parsin and semantic analysis for simdlen clause. llvm-svn: 265668
2016-04-07 20:45:37 +08:00
/// Instantiation of 'declare simd' attribute and its arguments.
static void instantiateOMPDeclareSimdDeclAttr(
Sema &S, const MultiLevelTemplateArgumentList &TemplateArgs,
const OMPDeclareSimdDeclAttr &Attr, Decl *New) {
[OPENMP 4.0] Support for 'uniform' clause in 'declare simd' directive. OpenMP 4.0 defines clause 'uniform' in 'declare simd' directive: 'uniform' '(' <argument-list> ')' The uniform clause declares one or more arguments to have an invariant value for all concurrent invocations of the function in the execution of a single SIMD loop. The special this pointer can be used as if was one of the arguments to the function in any of the linear, aligned, or uniform clauses. llvm-svn: 266041
2016-04-12 13:28:34 +08:00
// Allow 'this' in clauses with varlists.
if (auto *FTD = dyn_cast<FunctionTemplateDecl>(New))
New = FTD->getTemplatedDecl();
auto *FD = cast<FunctionDecl>(New);
auto *ThisContext = dyn_cast_or_null<CXXRecordDecl>(FD->getDeclContext());
[OPENMP 4.0] Support for 'linear' clause in 'declare simd' directive. The linear clause declares one or more list items to be private to a SIMD lane and to have a linear relationship with respect to the iteration space of a loop. 'linear' '(' <linear-list> [ ':' <linear-step> ] ')' When a linear-step expression is specified in a linear clause it must be either a constant integer expression or an integer-typed parameter that is specified in a uniform clause on the directive. The special this pointer can be used as if was one of the arguments to the function in any of the linear, aligned, or uniform clauses. llvm-svn: 266056
2016-04-12 19:02:11 +08:00
SmallVector<Expr *, 4> Uniforms, Aligneds, Alignments, Linears, Steps;
SmallVector<unsigned, 4> LinModifiers;
[OPENMP 4.0] Support for 'uniform' clause in 'declare simd' directive. OpenMP 4.0 defines clause 'uniform' in 'declare simd' directive: 'uniform' '(' <argument-list> ')' The uniform clause declares one or more arguments to have an invariant value for all concurrent invocations of the function in the execution of a single SIMD loop. The special this pointer can be used as if was one of the arguments to the function in any of the linear, aligned, or uniform clauses. llvm-svn: 266041
2016-04-12 13:28:34 +08:00
auto &&Subst = [&](Expr *E) -> ExprResult {
if (auto *DRE = dyn_cast<DeclRefExpr>(E->IgnoreParenImpCasts()))
if (auto *PVD = dyn_cast<ParmVarDecl>(DRE->getDecl())) {
Sema::ContextRAII SavedContext(S, FD);
LocalInstantiationScope Local(S);
if (FD->getNumParams() > PVD->getFunctionScopeIndex())
Local.InstantiatedLocal(
PVD, FD->getParamDecl(PVD->getFunctionScopeIndex()));
return S.SubstExpr(E, TemplateArgs);
}
Sema::CXXThisScopeRAII ThisScope(S, ThisContext, /*TypeQuals=*/0,
FD->isCXXInstanceMember());
return S.SubstExpr(E, TemplateArgs);
};
[OPENMP 4.0] Support for 'linear' clause in 'declare simd' directive. The linear clause declares one or more list items to be private to a SIMD lane and to have a linear relationship with respect to the iteration space of a loop. 'linear' '(' <linear-list> [ ':' <linear-step> ] ')' When a linear-step expression is specified in a linear clause it must be either a constant integer expression or an integer-typed parameter that is specified in a uniform clause on the directive. The special this pointer can be used as if was one of the arguments to the function in any of the linear, aligned, or uniform clauses. llvm-svn: 266056
2016-04-12 19:02:11 +08:00
ExprResult Simdlen;
if (auto *E = Attr.getSimdlen())
Simdlen = Subst(E);
[OPENMP 4.0] Support for 'uniform' clause in 'declare simd' directive. OpenMP 4.0 defines clause 'uniform' in 'declare simd' directive: 'uniform' '(' <argument-list> ')' The uniform clause declares one or more arguments to have an invariant value for all concurrent invocations of the function in the execution of a single SIMD loop. The special this pointer can be used as if was one of the arguments to the function in any of the linear, aligned, or uniform clauses. llvm-svn: 266041
2016-04-12 13:28:34 +08:00
if (Attr.uniforms_size() > 0) {
for(auto *E : Attr.uniforms()) {
ExprResult Inst = Subst(E);
if (Inst.isInvalid())
continue;
Uniforms.push_back(Inst.get());
}
[OPENMP 4.0] Parsing/sema analysis for 'simdlen' clause in 'declare simd' construct. OpenMP 4.0 defines '#pragma omp declare simd' construct that may have associated 'simdlen' clause with constant positive expression as an argument: simdlen(<const_expr>) Patch adds parsin and semantic analysis for simdlen clause. llvm-svn: 265668
2016-04-07 20:45:37 +08:00
}
[OPENMP 4.0] Support for 'aligned' clause in 'declare simd' directive. The aligned clause declares that the object to which each list item points is aligned to the number of bytes expressed in the optional parameter of the aligned clause. 'aligned' '(' <argument-list> [ ':' <alignment> ] ')' The optional parameter of the aligned clause, alignment, must be a constant positive integer expression. If no optional parameter is specified, implementation-defined default alignments for SIMD instructions on the target platforms are assumed. The special this pointer can be used as if was one of the arguments to the function in any of the linear, aligned, or uniform clauses. llvm-svn: 266052
2016-04-12 17:35:56 +08:00
auto AI = Attr.alignments_begin();
for (auto *E : Attr.aligneds()) {
ExprResult Inst = Subst(E);
if (Inst.isInvalid())
continue;
Aligneds.push_back(Inst.get());
Inst = ExprEmpty();
if (*AI)
Inst = S.SubstExpr(*AI, TemplateArgs);
Alignments.push_back(Inst.get());
++AI;
}
[OPENMP 4.0] Support for 'linear' clause in 'declare simd' directive. The linear clause declares one or more list items to be private to a SIMD lane and to have a linear relationship with respect to the iteration space of a loop. 'linear' '(' <linear-list> [ ':' <linear-step> ] ')' When a linear-step expression is specified in a linear clause it must be either a constant integer expression or an integer-typed parameter that is specified in a uniform clause on the directive. The special this pointer can be used as if was one of the arguments to the function in any of the linear, aligned, or uniform clauses. llvm-svn: 266056
2016-04-12 19:02:11 +08:00
auto SI = Attr.steps_begin();
for (auto *E : Attr.linears()) {
ExprResult Inst = Subst(E);
if (Inst.isInvalid())
continue;
Linears.push_back(Inst.get());
Inst = ExprEmpty();
if (*SI)
Inst = S.SubstExpr(*SI, TemplateArgs);
Steps.push_back(Inst.get());
++SI;
}
LinModifiers.append(Attr.modifiers_begin(), Attr.modifiers_end());
[OPENMP 4.0] Support for 'aligned' clause in 'declare simd' directive. The aligned clause declares that the object to which each list item points is aligned to the number of bytes expressed in the optional parameter of the aligned clause. 'aligned' '(' <argument-list> [ ':' <alignment> ] ')' The optional parameter of the aligned clause, alignment, must be a constant positive integer expression. If no optional parameter is specified, implementation-defined default alignments for SIMD instructions on the target platforms are assumed. The special this pointer can be used as if was one of the arguments to the function in any of the linear, aligned, or uniform clauses. llvm-svn: 266052
2016-04-12 17:35:56 +08:00
(void)S.ActOnOpenMPDeclareSimdDirective(
S.ConvertDeclToDeclGroup(New), Attr.getBranchState(), Simdlen.get(),
[OPENMP 4.0] Support for 'linear' clause in 'declare simd' directive. The linear clause declares one or more list items to be private to a SIMD lane and to have a linear relationship with respect to the iteration space of a loop. 'linear' '(' <linear-list> [ ':' <linear-step> ] ')' When a linear-step expression is specified in a linear clause it must be either a constant integer expression or an integer-typed parameter that is specified in a uniform clause on the directive. The special this pointer can be used as if was one of the arguments to the function in any of the linear, aligned, or uniform clauses. llvm-svn: 266056
2016-04-12 19:02:11 +08:00
Uniforms, Aligneds, Alignments, Linears, LinModifiers, Steps,
Attr.getRange());
[OPENMP 4.0] Parsing/sema analysis for 'simdlen' clause in 'declare simd' construct. OpenMP 4.0 defines '#pragma omp declare simd' construct that may have associated 'simdlen' clause with constant positive expression as an argument: simdlen(<const_expr>) Patch adds parsin and semantic analysis for simdlen clause. llvm-svn: 265668
2016-04-07 20:45:37 +08:00
}
Correct class-template deprecation behavior-REDUX Correct class-template deprecation behavior Based on the comment in the test, and my reading of the standard, a deprecated warning should be issued in the following case: template<typename T> [[deprecated]] class Foo{}; Foo<int> f; This was not the case, because the ClassTemplateSpecializationDecl creation did not also copy the deprecated attribute. Note: I did NOT audit the complete set of attributes to see WHICH ones should be copied, so instead I simply copy ONLY the deprecated attribute. Previous DiffRev: https://reviews.llvm.org/D27486, was reverted. This patch fixes the issues brought up here by the reverter: https://reviews.llvm.org/rL298410 Differential Revision: https://reviews.llvm.org/D31245 llvm-svn: 298634
2017-03-24 02:51:54 +08:00
static bool DeclContainsAttr(const Decl *D, const Attr *NewAttr) {
if (!D->hasAttrs() || NewAttr->duplicatesAllowed())
return false;
return llvm::find_if(D->getAttrs(), [NewAttr](const Attr *Attr) {
return Attr->getKind() == NewAttr->getKind();
}) != D->getAttrs().end();
}
void Sema::InstantiateAttrsForDecl(
const MultiLevelTemplateArgumentList &TemplateArgs, const Decl *Tmpl,
Decl *New, LateInstantiatedAttrVec *LateAttrs,
LocalInstantiationScope *OuterMostScope) {
if (NamedDecl *ND = dyn_cast<NamedDecl>(New)) {
for (const auto *TmplAttr : Tmpl->attrs()) {
// FIXME: If any of the special case versions from InstantiateAttrs become
// applicable to template declaration, we'll need to add them here.
CXXThisScopeRAII ThisScope(
*this, dyn_cast_or_null<CXXRecordDecl>(ND->getDeclContext()),
/*TypeQuals*/ 0, ND->isCXXInstanceMember());
Attr *NewAttr = sema::instantiateTemplateAttributeForDecl(
TmplAttr, Context, *this, TemplateArgs);
if (NewAttr && !DeclContainsAttr(New, NewAttr))
New->addAttr(NewAttr);
}
}
}
Instantiate attributes from the pattern record when instantiating a class template. Fixes rdar://problem/8243419. llvm-svn: 109967
2010-08-01 10:01:53 +08:00
void Sema::InstantiateAttrs(const MultiLevelTemplateArgumentList &TemplateArgs,
Delayed template instantiation of late-parsed attributes. llvm-svn: 148595
2012-01-21 06:50:54 +08:00
const Decl *Tmpl, Decl *New,
LateInstantiatedAttrVec *LateAttrs,
LocalInstantiationScope *OuterMostScope) {
[C++11] Replacing Decl iterators attr_begin() and attr_end() with iterator_range attrs(). Updating all of the usages of the iterators with range-based for loops. This is a reapplication of r203236 with modifications to the definition of attrs() and following the new style guidelines on auto usage. llvm-svn: 203362
2014-03-09 06:19:01 +08:00
for (const auto *TmplAttr : Tmpl->attrs()) {
Implement dependent alignment attribute support. This is a bit gross given the current attribute system, but it is enough to handle class templates which specify parts of their alignment in terms of their template parameters. This also replaces the attributes test in SemaTemplate with one that actually tests working attributes instead of broken ones. I plan to add more tests here for non-dependent attributes in a subsequent patch. Thanks to John for walking me through some of this. =D llvm-svn: 106818
2010-06-25 11:22:07 +08:00
// FIXME: This should be generalized to more than just the AlignedAttr.
Handle alignas(foo...) pack expansions. llvm-svn: 175875
2013-02-22 16:32:16 +08:00
const AlignedAttr *Aligned = dyn_cast<AlignedAttr>(TmplAttr);
if (Aligned && Aligned->isAlignmentDependent()) {
instantiateDependentAlignedAttr(*this, TemplateArgs, Aligned, New);
continue;
Implement dependent alignment attribute support. This is a bit gross given the current attribute system, but it is enough to handle class templates which specify parts of their alignment in terms of their template parameters. This also replaces the attributes test in SemaTemplate with one that actually tests working attributes instead of broken ones. I plan to add more tests here for non-dependent attributes in a subsequent patch. Thanks to John for walking me through some of this. =D llvm-svn: 106818
2010-06-25 11:22:07 +08:00
}
Support the assume_aligned function attribute In addition to __builtin_assume_aligned, GCC also supports an assume_aligned attribute which specifies the alignment (and optional offset) of a function's return value. Here we implement support for the assume_aligned attribute by making use of the @llvm.assume intrinsic. llvm-svn: 218500
2014-09-26 13:04:30 +08:00
const AssumeAlignedAttr *AssumeAligned = dyn_cast<AssumeAlignedAttr>(TmplAttr);
if (AssumeAligned) {
instantiateDependentAssumeAlignedAttr(*this, TemplateArgs, AssumeAligned, New);
continue;
}
Initial support for the align_value attribute This adds support for the align_value attribute. This attribute is supported by Intel's compiler (versions 14.0+), and several of my HPC users have requested support in Clang. It specifies an alignment assumption on the values to which a pointer points, and is used by numerical libraries to encourage efficient generation of vector code. Of course, we already have an aligned attribute that can specify enhanced alignment for a type, so why is this additional attribute important? The problem is that if you want to specify that an input array of T is, say, 64-byte aligned, you could try this: typedef double aligned_double attribute((aligned(64))); void foo(aligned_double *P) { double x = P[0]; // This is fine. double y = P[1]; // What alignment did those doubles have again? } the access here to P[1] causes problems. P was specified as a pointer to type aligned_double, and any object of type aligned_double must be 64-byte aligned. But if P[0] is 64-byte aligned, then P[1] cannot be, and this access causes undefined behavior. Getting round this problem requires a lot of awkward casting and hand-unrolling of loops, all of which is bad. With the align_value attribute, we can accomplish what we'd like in a well defined way: typedef double *aligned_double_ptr attribute((align_value(64))); void foo(aligned_double_ptr P) { double x = P[0]; // This is fine. double y = P[1]; // This is fine too. } This attribute does not create a new type (and so it not part of the type system), and so will only "propagate" through templates, auto, etc. by optimizer deduction after inlining. This seems consistent with Intel's implementation (thanks to Alexey for confirming the various Intel-compiler behaviors). As a final note, I would have chosen to call this aligned_value, not align_value, for better naming consistency with the aligned attribute, but I think it would be more useful to users to adopt Intel's name. llvm-svn: 218910
2014-10-03 05:21:25 +08:00
const AlignValueAttr *AlignValue = dyn_cast<AlignValueAttr>(TmplAttr);
if (AlignValue) {
instantiateDependentAlignValueAttr(*this, TemplateArgs, AlignValue, New);
continue;
}
Clang changes for alloc_align attribute GCC has the alloc_align attribute, which is similar to assume_aligned, except the attribute's parameter is the index of the integer parameter that needs aligning to. Differential Revision: https://reviews.llvm.org/D29599 llvm-svn: 299117
2017-03-31 05:48:55 +08:00
if (const auto *AllocAlign = dyn_cast<AllocAlignAttr>(TmplAttr)) {
instantiateDependentAllocAlignAttr(*this, TemplateArgs, AllocAlign, New);
continue;
}
[Sema] Fix a bug in enable_if condition instantiation. During template instantiation, we currently fall back to just calling Sema::SubstExpr for enable_if attributes that aren't value-dependent or type-dependent. Since Sema::SubstExpr strips off any implicit casts we've added to an expression, it's possible that this behavior will leave us with an enable_if condition that's just a DeclRefExpr. Conditions like that deeply confuse Sema::CheckEnableIf. llvm-svn: 287187
2016-11-17 09:33:54 +08:00
if (const auto *EnableIf = dyn_cast<EnableIfAttr>(TmplAttr)) {
Add a new attribute 'enable_if' which can be used to control overload resolution based on the values of the function arguments at the call site. llvm-svn: 198996
2014-01-11 10:50:57 +08:00
instantiateDependentEnableIfAttr(*this, TemplateArgs, EnableIf, Tmpl,
Add the diagnose_if attribute to clang. `diagnose_if` can be used to have clang emit either warnings or errors for function calls that meet user-specified conditions. For example: ``` constexpr int foo(int a) __attribute__((diagnose_if(a > 10, "configurations with a > 10 are " "expensive.", "warning"))); int f1 = foo(9); int f2 = foo(10); // warning: configuration with a > 10 are expensive. int f3 = foo(f2); ``` It currently only emits diagnostics in cases where the condition is guaranteed to always be true. So, the following code will emit no warnings: ``` constexpr int bar(int a) { foo(a); return 0; } constexpr int i = bar(10); ``` We hope to support optionally emitting diagnostics for cases like that (and emitting runtime checks) in the future. Release notes will appear shortly. :) Differential Revision: https://reviews.llvm.org/D27424 llvm-svn: 291418
2017-01-09 12:12:14 +08:00
cast<FunctionDecl>(New));
continue;
}
if (const auto *DiagnoseIf = dyn_cast<DiagnoseIfAttr>(TmplAttr)) {
instantiateDependentDiagnoseIfAttr(*this, TemplateArgs, DiagnoseIf, Tmpl,
cast<FunctionDecl>(New));
Add a new attribute 'enable_if' which can be used to control overload resolution based on the values of the function arguments at the call site. llvm-svn: 198996
2014-01-11 10:50:57 +08:00
continue;
}
[cuda] Allow using integral non-type template parameters as launch_bounds attribute arguments. - Changed CUDALaunchBounds arguments from integers to Expr* so they can be saved in AST for instantiation. - Added support for template instantiation of launch_bounds attrubute. - Moved evaluation of launch_bounds arguments to NVPTXTargetCodeGenInfo:: SetTargetAttributes() where it can be done after template instantiation. - Added a warning on negative launch_bounds arguments. - Amended test cases. Differential Revision: http://reviews.llvm.org/D8985 llvm-svn: 235452
2015-04-22 06:55:54 +08:00
if (const CUDALaunchBoundsAttr *CUDALaunchBounds =
dyn_cast<CUDALaunchBoundsAttr>(TmplAttr)) {
instantiateDependentCUDALaunchBoundsAttr(*this, TemplateArgs,
*CUDALaunchBounds, New);
continue;
}
Fix for PR8901: attribute "mode" rejected for enums and dependent types. Allow "mode" attribute for enum types, except for vector modes, for compatibility with GCC. Support "mode" attribute with dependent types. Differential Revision: http://reviews.llvm.org/D16219 llvm-svn: 259497
2016-02-02 21:50:39 +08:00
if (const ModeAttr *Mode = dyn_cast<ModeAttr>(TmplAttr)) {
instantiateDependentModeAttr(*this, TemplateArgs, *Mode, New);
continue;
}
[OPENMP 4.0] Parsing/sema analysis for 'simdlen' clause in 'declare simd' construct. OpenMP 4.0 defines '#pragma omp declare simd' construct that may have associated 'simdlen' clause with constant positive expression as an argument: simdlen(<const_expr>) Patch adds parsin and semantic analysis for simdlen clause. llvm-svn: 265668
2016-04-07 20:45:37 +08:00
if (const auto *OMPAttr = dyn_cast<OMPDeclareSimdDeclAttr>(TmplAttr)) {
instantiateOMPDeclareSimdDeclAttr(*this, TemplateArgs, *OMPAttr, New);
continue;
}
Don't assert on different DLL attributes in template and explicit instantiation (PR20137) We would previously assert (a decl cannot have two DLL attributes) on this code: template <typename T> struct __declspec(dllimport) S { T f() { return T(); } }; template struct __declspec(dllexport) S<int>; The problem was that when instantiating, we would take the attribute from the template even if the instantiation itself already had an attribute. Also, don't inherit DLL attributes from the template to its members before instantiation, as the attribute may change. I couldn't figure out what MinGW does here, so I'm leaving that open. At least we're not asserting anymore. llvm-svn: 216340
2014-08-24 08:12:36 +08:00
// Existing DLL attribute on the instantiation takes precedence.
if (TmplAttr->getKind() == attr::DLLExport ||
TmplAttr->getKind() == attr::DLLImport) {
if (New->hasAttr<DLLExportAttr>() || New->hasAttr<DLLImportAttr>()) {
continue;
}
}
Semantic analysis for the swiftcall calling convention. I've tried to keep the infrastructure behind parameter ABI treatments fairly general. llvm-svn: 262587
2016-03-03 14:39:32 +08:00
if (auto ABIAttr = dyn_cast<ParameterABIAttr>(TmplAttr)) {
AddParameterABIAttr(ABIAttr->getRange(), New, ABIAttr->getABI(),
ABIAttr->getSpellingListIndex());
continue;
}
Improve some infrastructure for extended parameter infos and fix a bug with the instantiation of ns_consumed parameter attributes in ARC. llvm-svn: 262551
2016-03-03 08:10:03 +08:00
if (isa<NSConsumedAttr>(TmplAttr) || isa<CFConsumedAttr>(TmplAttr)) {
AddNSConsumedAttr(TmplAttr->getRange(), New,
TmplAttr->getSpellingListIndex(),
isa<NSConsumedAttr>(TmplAttr),
/*template instantiation*/ true);
continue;
}
Handle alignas(foo...) pack expansions. llvm-svn: 175875
2013-02-22 16:32:16 +08:00
assert(!TmplAttr->isPackExpansion());
Delayed template instantiation of late-parsed attributes. llvm-svn: 148595
2012-01-21 06:50:54 +08:00
if (TmplAttr->isLateParsed() && LateAttrs) {
// Late parsed attributes must be instantiated and attached after the
// enclosing class has been instantiated. See Sema::InstantiateClass.
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
LocalInstantiationScope *Saved = nullptr;
Delayed template instantiation of late-parsed attributes. llvm-svn: 148595
2012-01-21 06:50:54 +08:00
if (CurrentInstantiationScope)
Saved = CurrentInstantiationScope->cloneScopes(OuterMostScope);
LateAttrs->push_back(LateInstantiatedAttribute(TmplAttr, Saved, New));
} else {
PR16243: Use CXXThisOverride during template instantiation, and fix up the places which weren't setting it up properly. This allows us to get the right cv-qualifiers for 'this' when it appears outside a method body in a class template. llvm-svn: 183483
2013-06-07 10:33:37 +08:00
// Allow 'this' within late-parsed attributes.
NamedDecl *ND = dyn_cast<NamedDecl>(New);
CXXRecordDecl *ThisContext =
dyn_cast_or_null<CXXRecordDecl>(ND->getDeclContext());
CXXThisScopeRAII ThisScope(*this, ThisContext, /*TypeQuals*/0,
ND && ND->isCXXInstanceMember());
Move instantiateTemplateAttribute into the sema namespace, make helpers static. llvm-svn: 149864
2012-02-06 19:13:08 +08:00
Attr *NewAttr = sema::instantiateTemplateAttribute(TmplAttr, Context,
*this, TemplateArgs);
Correct class-template deprecation behavior-REDUX Correct class-template deprecation behavior Based on the comment in the test, and my reading of the standard, a deprecated warning should be issued in the following case: template<typename T> [[deprecated]] class Foo{}; Foo<int> f; This was not the case, because the ClassTemplateSpecializationDecl creation did not also copy the deprecated attribute. Note: I did NOT audit the complete set of attributes to see WHICH ones should be copied, so instead I simply copy ONLY the deprecated attribute. Previous DiffRev: https://reviews.llvm.org/D27486, was reverted. This patch fixes the issues brought up here by the reverter: https://reviews.llvm.org/rL298410 Differential Revision: https://reviews.llvm.org/D31245 llvm-svn: 298634
2017-03-24 02:51:54 +08:00
if (NewAttr && !DeclContainsAttr(New, NewAttr))
Fix our handling of visibility in explicit template instantiations. * Don't copy the visibility attribute during instantiations. We have to be able to distinguish struct HIDDEN foo {}; template<class T> DEFAULT void bar() {} template DEFAULT void bar<foo>(); from struct HIDDEN foo {}; template<class T> DEFAULT void bar() {} template void bar<foo>(); * If an instantiation has an attribute, it takes precedence over an attribute in the template. * With instantiation attributes handled with the above logic, we can now select the minimum visibility when looking at template arguments. llvm-svn: 156821
2012-05-15 22:09:55 +08:00
New->addAttr(NewAttr);
Delayed template instantiation of late-parsed attributes. llvm-svn: 148595
2012-01-21 06:50:54 +08:00
}
When instantiating a field decl, make sure to clone its attributes. With this change FileCheck no longer crashes when it's run without any arguments. llvm-svn: 86344
2009-11-07 14:07:58 +08:00
}
}
[modules] When instantiating a class member, don't expect to find the previous declaration in the instantiation if the previous declaration came from another definition of the class template that got merged into the pattern definition. llvm-svn: 219552
2014-10-11 08:37:16 +08:00
/// Get the previous declaration of a declaration for the purposes of template
/// instantiation. If this finds a previous declaration, then the previous
/// declaration of the instantiation of D should be an instantiation of the
/// result of this function.
template<typename DeclT>
static DeclT *getPreviousDeclForInstantiation(DeclT *D) {
DeclT *Result = D->getPreviousDecl();
// If the declaration is within a class, and the previous declaration was
// merged from a different definition of that class, then we don't have a
// previous declaration for the purpose of template instantiation.
if (Result && isa<CXXRecordDecl>(D->getDeclContext()) &&
D->getLexicalDeclContext() != Result->getLexicalDeclContext())
return nullptr;
return Result;
}
Stub out some declaration kinds that cannot ever be instantiated llvm-svn: 67686
2009-03-25 23:45:12 +08:00
Decl *
TemplateDeclInstantiator::VisitTranslationUnitDecl(TranslationUnitDecl *D) {
Switch assert(0/false) llvm_unreachable. llvm-svn: 140367
2011-09-23 13:06:16 +08:00
llvm_unreachable("Translation units cannot be instantiated");
Stub out some declaration kinds that cannot ever be instantiated llvm-svn: 67686
2009-03-25 23:45:12 +08:00
}
Serialize `#pragma comment`. `#pragma comment` was handled by Sema calling a function on ASTConsumer, and CodeGen then implementing this function and writing things to its output. Instead, introduce a PragmaCommentDecl AST node and hang one off the TranslationUnitDecl for every `#pragma comment` line, and then use the regular serialization machinery. (Since PragmaCommentDecl has codegen relevance, it's eagerly deserialized.) http://reviews.llvm.org/D17799 llvm-svn: 262493
2016-03-03 01:28:48 +08:00
Decl *
TemplateDeclInstantiator::VisitPragmaCommentDecl(PragmaCommentDecl *D) {
llvm_unreachable("pragma comment cannot be instantiated");
}
Serialize `#pragma detect_mismatch`. This is like r262493, but for pragma detect_mismatch instead of pragma comment. The two pragmas have similar behavior, so use the same approach for both. llvm-svn: 262506
2016-03-03 03:28:54 +08:00
Decl *TemplateDeclInstantiator::VisitPragmaDetectMismatchDecl(
PragmaDetectMismatchDecl *D) {
llvm_unreachable("pragma comment cannot be instantiated");
}
Replace Sema's map of locally-scoped extern "C" declarations with a DeclContext of extern "C" declarations. This is simpler and vastly more efficient for modules builds (we no longer need to load *all* extern "C" declarations to determine if we have a redeclaration). No functionality change intended. llvm-svn: 231538
2015-03-07 08:04:49 +08:00
Decl *
TemplateDeclInstantiator::VisitExternCContextDecl(ExternCContextDecl *D) {
llvm_unreachable("extern \"C\" context cannot be instantiated");
}
Step #2/N of __label__ support: keep pushing LabelDecl forward, making them be template instantiated in a more normal way and make them handle attributes like other decls. This fixes the used/unused label handling stuff, making it use the same infrastructure as other decls. llvm-svn: 125771
2011-02-18 04:34:02 +08:00
Decl *
TemplateDeclInstantiator::VisitLabelDecl(LabelDecl *D) {
LabelDecl *Inst = LabelDecl::Create(SemaRef.Context, Owner, D->getLocation(),
D->getIdentifier());
Owner->addDecl(Inst);
return Inst;
}
Stub out some declaration kinds that cannot ever be instantiated llvm-svn: 67686
2009-03-25 23:45:12 +08:00
Decl *
TemplateDeclInstantiator::VisitNamespaceDecl(NamespaceDecl *D) {
Switch assert(0/false) llvm_unreachable. llvm-svn: 140367
2011-09-23 13:06:16 +08:00
llvm_unreachable("Namespaces cannot be instantiated");
Stub out some declaration kinds that cannot ever be instantiated llvm-svn: 67686
2009-03-25 23:45:12 +08:00
}
Support local namespace aliases and permit them to be instantiated. llvm-svn: 96335
2010-02-16 14:53:13 +08:00
Decl *
TemplateDeclInstantiator::VisitNamespaceAliasDecl(NamespaceAliasDecl *D) {
NamespaceAliasDecl *Inst
= NamespaceAliasDecl::Create(SemaRef.Context, Owner,
D->getNamespaceLoc(),
D->getAliasLoc(),
Push nested-name-specifier source location information into namespace aliases. llvm-svn: 126496
2011-02-26 01:08:07 +08:00
D->getIdentifier(),
D->getQualifierLoc(),
Support local namespace aliases and permit them to be instantiated. llvm-svn: 96335
2010-02-16 14:53:13 +08:00
D->getTargetNameLoc(),
D->getNamespace());
Owner->addDecl(Inst);
return Inst;
}
Implement support for C++0x alias templates. llvm-svn: 130953
2011-05-06 05:57:07 +08:00
Decl *TemplateDeclInstantiator::InstantiateTypedefNameDecl(TypedefNameDecl *D,
bool IsTypeAlias) {
Refactor instantiation of declarations within a template into a much cleaner visitor framework. Added a visitor for declarations, which is quite similar to the visitor for statatements. llvm-svn: 67104
2009-03-18 05:15:40 +08:00
bool Invalid = false;
DeclaratorInfo -> TypeSourceInfo. Makes an effort to rename associated variables, but the results are imperfect. For posterity, I did: cat <<EOF > $cmdfile s/DeclaratorInfo/TypeSourceInfo/g s/DInfo/TInfo/g s/TypeTypeSourceInfo/TypeSourceInfo/g s/SourceTypeSourceInfo/TypeSourceInfo/g EOF find lib -name '*.cpp' -not -path 'lib/Parse/*' -exec sed -i '' -f $cmdfile '{}' \; find lib -name '*.h' -exec sed -i '' -f $cmdfile '{}' \; find include -name '*.h' -not -path 'include/clang/Parse/*' -not -path 'include/clang/Basic/*' -exec sed -i '' -f $cmdfile '{}' \; llvm-svn: 90743
2009-12-07 10:54:59 +08:00
TypeSourceInfo *DI = D->getTypeSourceInfo();
Introduce the notion of instantiation dependence into Clang's AST. A type/expression/template argument/etc. is instantiation-dependent if it somehow involves a template parameter, even if it doesn't meet the requirements for the more common kinds of dependence (dependent type, type-dependent expression, value-dependent expression). When we see an instantiation-dependent type, we know we always need to perform substitution into that instantiation-dependent type. This keeps us from short-circuiting evaluation in places where we shouldn't, and lets us properly implement C++0x [temp.type]p2. In theory, this would also allow us to properly mangle instantiation-dependent-but-not-dependent decltype types per the Itanium C++ ABI, but we aren't quite there because we still mangle based on the canonical type in cases like, e.g., template<unsigned> struct A { }; template<typename T> void f(A<sizeof(sizeof(decltype(T() + T())))>) { } template void f<int>(A<sizeof(sizeof(int))>); and therefore get the wrong answer. llvm-svn: 134225
2011-07-01 09:22:09 +08:00
if (DI->getType()->isInstantiationDependentType() ||
Make sure that we instantiate variably modified types, even if they aren't dependent. Fixes <rdar://problem/8020206>. llvm-svn: 104511
2010-05-25 01:22:01 +08:00
DI->getType()->isVariablyModifiedType()) {
Preserve type source information in TypedefDecls. Preserve it across template instantiation. Preserve it through PCH. Show it off to the indexer. I'm healthily ignoring the vector type cases because we don't have a sensible TypeLoc implementation for them anyway. llvm-svn: 84994
2009-10-24 16:00:42 +08:00
DI = SemaRef.SubstType(DI, TemplateArgs,
D->getLocation(), D->getDeclName());
if (!DI) {
Refactor instantiation of declarations within a template into a much cleaner visitor framework. Added a visitor for declarations, which is quite similar to the visitor for statatements. llvm-svn: 67104
2009-03-18 05:15:40 +08:00
Invalid = true;
DeclaratorInfo -> TypeSourceInfo. Makes an effort to rename associated variables, but the results are imperfect. For posterity, I did: cat <<EOF > $cmdfile s/DeclaratorInfo/TypeSourceInfo/g s/DInfo/TInfo/g s/TypeTypeSourceInfo/TypeSourceInfo/g s/SourceTypeSourceInfo/TypeSourceInfo/g EOF find lib -name '*.cpp' -not -path 'lib/Parse/*' -exec sed -i '' -f $cmdfile '{}' \; find lib -name '*.h' -exec sed -i '' -f $cmdfile '{}' \; find include -name '*.h' -not -path 'include/clang/Parse/*' -not -path 'include/clang/Basic/*' -exec sed -i '' -f $cmdfile '{}' \; llvm-svn: 90743
2009-12-07 10:54:59 +08:00
DI = SemaRef.Context.getTrivialTypeSourceInfo(SemaRef.Context.IntTy);
Refactor instantiation of declarations within a template into a much cleaner visitor framework. Added a visitor for declarations, which is quite similar to the visitor for statatements. llvm-svn: 67104
2009-03-18 05:15:40 +08:00
}
When we encounter a non-dependent type during template instantiation, mark any declarations we see inside of that type as "referenced". Fixes PR7079. llvm-svn: 103323
2010-05-08 07:12:07 +08:00
} else {
SemaRef.MarkDeclarationsReferencedInType(D->getLocation(), DI->getType());
Refactor instantiation of declarations within a template into a much cleaner visitor framework. Added a visitor for declarations, which is quite similar to the visitor for statatements. llvm-svn: 67104
2009-03-18 05:15:40 +08:00
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Ugly ugly hack for libstdc++-4.6 and libstdc++-4.7 compatibility. These libraries have an incorrect definition of std::common_type (inherited from a bug in the standard -- see LWG issue 2141), whereby they produce reference types when they should not. If we instantiate a typedef named std::common_type<...>::type, which is defined in a system header as decltype(... ? ... : ...), and the decltype produces a reference type, convert it to the non-reference type. (This doesn't affect any LWG2141-conforming implementation of common_type, such as libc++'s, because the default implementation of common_type<...>::type isn't supposed to produce a reference type.) This is horrible. I'm really sorry. :( Better ideas appreciated! llvm-svn: 166455
2012-10-23 08:32:41 +08:00
// HACK: g++ has a bug where it gets the value kind of ?: wrong.
// libstdc++ relies upon this bug in its implementation of common_type.
// If we happen to be processing that implementation, fake up the g++ ?:
// semantics. See LWG issue 2141 for more information on the bug.
const DecltypeType *DT = DI->getType()->getAs<DecltypeType>();
CXXRecordDecl *RD = dyn_cast<CXXRecordDecl>(D->getDeclContext());
if (DT && RD && isa<ConditionalOperator>(DT->getUnderlyingExpr()) &&
DT->isReferenceType() &&
RD->getEnclosingNamespaceContext() == SemaRef.getStdNamespace() &&
RD->getIdentifier() && RD->getIdentifier()->isStr("common_type") &&
D->getIdentifier() && D->getIdentifier()->isStr("type") &&
SemaRef.getSourceManager().isInSystemHeader(D->getLocStart()))
// Fold it to the (non-reference) type which g++ would have produced.
DI = SemaRef.Context.getTrivialTypeSourceInfo(
DI->getType().getNonReferenceType());
Refactor instantiation of declarations within a template into a much cleaner visitor framework. Added a visitor for declarations, which is quite similar to the visitor for statatements. llvm-svn: 67104
2009-03-18 05:15:40 +08:00
// Create the new typedef
Support for C++11 (non-template) alias declarations. llvm-svn: 129567
2011-04-15 22:24:37 +08:00
TypedefNameDecl *Typedef;
if (IsTypeAlias)
Typedef = TypeAliasDecl::Create(SemaRef.Context, Owner, D->getLocStart(),
D->getLocation(), D->getIdentifier(), DI);
else
Typedef = TypedefDecl::Create(SemaRef.Context, Owner, D->getLocStart(),
D->getLocation(), D->getIdentifier(), DI);
Refactor instantiation of declarations within a template into a much cleaner visitor framework. Added a visitor for declarations, which is quite similar to the visitor for statatements. llvm-svn: 67104
2009-03-18 05:15:40 +08:00
if (Invalid)
Typedef->setInvalidDecl();
The code trying to assign a typedef to an anonymous tag declaration was extremely rambunctious, both on parsing and on template instantiation. Calm it down, fixing an internal consistency assert on anonymous enum instantiation manglings. llvm-svn: 124653
2011-02-01 16:20:08 +08:00
// If the old typedef was the name for linkage purposes of an anonymous
// tag decl, re-establish that relationship for the new typedef.
if (const TagType *oldTagType = D->getUnderlyingType()->getAs<TagType>()) {
TagDecl *oldTag = oldTagType->getDecl();
<rdar://problem/13094134> Don't try to wire up typedef names for invalid anonymous tag declarations encountered during template instantiation. llvm-svn: 176727
2013-03-09 06:15:15 +08:00
if (oldTag->getTypedefNameForAnonDecl() == D && !Invalid) {
The code trying to assign a typedef to an anonymous tag declaration was extremely rambunctious, both on parsing and on template instantiation. Calm it down, fixing an internal consistency assert on anonymous enum instantiation manglings. llvm-svn: 124653
2011-02-01 16:20:08 +08:00
TagDecl *newTag = DI->getType()->castAs<TagType>()->getDecl();
Add TagDecl::hasNameForLinkage(), which is true if the tag is non-anonymous or is defined in a typedef of itself. llvm-svn: 176742
2013-03-09 08:54:27 +08:00
assert(!newTag->hasNameForLinkage());
Support for C++11 (non-template) alias declarations. llvm-svn: 129567
2011-04-15 22:24:37 +08:00
newTag->setTypedefNameForAnonDecl(Typedef);
The code trying to assign a typedef to an anonymous tag declaration was extremely rambunctious, both on parsing and on template instantiation. Calm it down, fixing an internal consistency assert on anonymous enum instantiation manglings. llvm-svn: 124653
2011-02-01 16:20:08 +08:00
}
When instantiating a typedef of an anonymous tag type, note in the tag declaration that this typedef gives the tag a name. Fixes a problem uncovered by Boost.GIL (Generic Image Library). llvm-svn: 102180
2010-04-24 00:25:07 +08:00
}
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
[modules] When instantiating a class member, don't expect to find the previous declaration in the instantiation if the previous declaration came from another definition of the class template that got merged into the pattern definition. llvm-svn: 219552
2014-10-11 08:37:16 +08:00
if (TypedefNameDecl *Prev = getPreviousDeclForInstantiation(D)) {
When looking for the instantiated declaration that corresponds to a given declaration in a template, make sure that the context we're searching through is complete. Fixes PR6376. llvm-svn: 97444
2010-03-01 23:56:25 +08:00
NamedDecl *InstPrev = SemaRef.FindInstantiatedDecl(D->getLocation(), Prev,
TemplateArgs);
Patch up several Sema::FindInstantiatedDecl() callers, so that they'll properly cope with NULL return values. llvm-svn: 127024
2011-03-05 03:46:35 +08:00
if (!InstPrev)
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Delay checking of typedefs of dependent types. Fixes PR11630. llvm-svn: 147281
2011-12-27 06:42:47 +08:00
TypedefNameDecl *InstPrevTypedef = cast<TypedefNameDecl>(InstPrev);
// If the typedef types are not identical, reject them.
SemaRef.isIncompatibleTypedef(InstPrevTypedef, Typedef);
Rename some functions for consistency. Every other function in Redeclarable.h was using Decl instead of Declaration. llvm-svn: 192900
2013-10-17 23:37:26 +08:00
Typedef->setPreviousDecl(InstPrevTypedef);
Typedefs can be redeclared. That seems like something we should record in the AST lest we run into some crazy canonicalization bug like PR5874. llvm-svn: 92283
2009-12-30 08:31:22 +08:00
}
Instantiate attributes from the pattern record when instantiating a class template. Fixes rdar://problem/8243419. llvm-svn: 109967
2010-08-01 10:01:53 +08:00
SemaRef.InstantiateAttrs(TemplateArgs, D, Typedef);
When instantiating a typedef of an anonymous tag type, note in the tag declaration that this typedef gives the tag a name. Fixes a problem uncovered by Boost.GIL (Generic Image Library). llvm-svn: 102180
2010-04-24 00:25:07 +08:00
First pass at collecting access-specifier information along inheritance paths. Triggers lots of assertions about missing access information; fix them. Will actually consume this information soon. llvm-svn: 94038
2010-01-21 05:53:11 +08:00
Typedef->setAccess(D->getAccess());
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Refactor instantiation of declarations within a template into a much cleaner visitor framework. Added a visitor for declarations, which is quite similar to the visitor for statatements. llvm-svn: 67104
2009-03-18 05:15:40 +08:00
return Typedef;
}
Support for C++11 (non-template) alias declarations. llvm-svn: 129567
2011-04-15 22:24:37 +08:00
Decl *TemplateDeclInstantiator::VisitTypedefDecl(TypedefDecl *D) {
Implement support for C++0x alias templates. llvm-svn: 130953
2011-05-06 05:57:07 +08:00
Decl *Typedef = InstantiateTypedefNameDecl(D, /*IsTypeAlias=*/false);
[modules] When instantiating a class member, don't expect to find the previous declaration in the instantiation if the previous declaration came from another definition of the class template that got merged into the pattern definition. llvm-svn: 219552
2014-10-11 08:37:16 +08:00
if (Typedef)
Owner->addDecl(Typedef);
Implement support for C++0x alias templates. llvm-svn: 130953
2011-05-06 05:57:07 +08:00
return Typedef;
Support for C++11 (non-template) alias declarations. llvm-svn: 129567
2011-04-15 22:24:37 +08:00
}
Decl *TemplateDeclInstantiator::VisitTypeAliasDecl(TypeAliasDecl *D) {
Implement support for C++0x alias templates. llvm-svn: 130953
2011-05-06 05:57:07 +08:00
Decl *Typedef = InstantiateTypedefNameDecl(D, /*IsTypeAlias=*/true);
[modules] When instantiating a class member, don't expect to find the previous declaration in the instantiation if the previous declaration came from another definition of the class template that got merged into the pattern definition. llvm-svn: 219552
2014-10-11 08:37:16 +08:00
if (Typedef)
Owner->addDecl(Typedef);
Implement support for C++0x alias templates. llvm-svn: 130953
2011-05-06 05:57:07 +08:00
return Typedef;
}
Decl *
TemplateDeclInstantiator::VisitTypeAliasTemplateDecl(TypeAliasTemplateDecl *D) {
// Create a local instantiation scope for this type alias template, which
// will contain the instantiations of the template parameters.
LocalInstantiationScope Scope(SemaRef);
TemplateParameterList *TempParams = D->getTemplateParameters();
TemplateParameterList *InstParams = SubstTemplateParams(TempParams);
if (!InstParams)
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Implement support for C++0x alias templates. llvm-svn: 130953
2011-05-06 05:57:07 +08:00
TypeAliasDecl *Pattern = D->getTemplatedDecl();
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
TypeAliasTemplateDecl *PrevAliasTemplate = nullptr;
[modules] When instantiating a class member, don't expect to find the previous declaration in the instantiation if the previous declaration came from another definition of the class template that got merged into the pattern definition. llvm-svn: 219552
2014-10-11 08:37:16 +08:00
if (getPreviousDeclForInstantiation<TypedefNameDecl>(Pattern)) {
Implement support for C++0x alias templates. llvm-svn: 130953
2011-05-06 05:57:07 +08:00
DeclContext::lookup_result Found = Owner->lookup(Pattern->getDeclName());
Change DeclContextLookup(Const)Result to (Mutable)ArrayRef<NamedDecl*>, as per review discussion in r170365 This does limit these typedefs to being sequences, but no current usage requires them to be contiguous (we could expand this to a more general iterator pair range concept at some point). Also, it'd be nice if SmallVector were constructible directly from an ArrayRef but this is a bit tricky since ArrayRef depends on SmallVectorBaseImpl for the inverse conversion. (& generalizing over all range-like things, while nice, would require some nontrivial SFINAE I haven't thought about yet) llvm-svn: 170482
2012-12-19 08:45:41 +08:00
if (!Found.empty()) {
PrevAliasTemplate = dyn_cast<TypeAliasTemplateDecl>(Found.front());
Implement support for C++0x alias templates. llvm-svn: 130953
2011-05-06 05:57:07 +08:00
}
}
TypeAliasDecl *AliasInst = cast_or_null<TypeAliasDecl>(
InstantiateTypedefNameDecl(Pattern, /*IsTypeAlias=*/true));
if (!AliasInst)
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Implement support for C++0x alias templates. llvm-svn: 130953
2011-05-06 05:57:07 +08:00
TypeAliasTemplateDecl *Inst
= TypeAliasTemplateDecl::Create(SemaRef.Context, Owner, D->getLocation(),
D->getDeclName(), InstParams, AliasInst);
[modules] Track the described template in an alias declaration that is the pattern of an alias template declaration. Use this to merge alias templates properly when they're members of class template specializations. llvm-svn: 216437
2014-08-26 11:52:16 +08:00
AliasInst->setDescribedAliasTemplate(Inst);
Implement support for C++0x alias templates. llvm-svn: 130953
2011-05-06 05:57:07 +08:00
if (PrevAliasTemplate)
Rename some functions for consistency. Every other function in Redeclarable.h was using Decl instead of Declaration. llvm-svn: 192900
2013-10-17 23:37:26 +08:00
Inst->setPreviousDecl(PrevAliasTemplate);
Implement support for C++0x alias templates. llvm-svn: 130953
2011-05-06 05:57:07 +08:00
Inst->setAccess(D->getAccess());
if (!PrevAliasTemplate)
Inst->setInstantiatedFromMemberTemplate(D);
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Implement support for C++0x alias templates. llvm-svn: 130953
2011-05-06 05:57:07 +08:00
Owner->addDecl(Inst);
return Inst;
Support for C++11 (non-template) alias declarations. llvm-svn: 129567
2011-04-15 22:24:37 +08:00
}
P0217R3: Parsing support and framework for AST representation of C++1z decomposition declarations. There are a couple of things in the wording that seem strange here: decomposition declarations are permitted at namespace scope (which we partially support here) and they are permitted as the declaration in a template (which we reject). llvm-svn: 276492
2016-07-23 07:36:59 +08:00
Decl *TemplateDeclInstantiator::VisitBindingDecl(BindingDecl *D) {
P0217R3: template instantiation support for decomposition declarations. llvm-svn: 278458
2016-08-12 09:55:21 +08:00
auto *NewBD = BindingDecl::Create(SemaRef.Context, Owner, D->getLocation(),
D->getIdentifier());
SemaRef.CurrentInstantiationScope->InstantiatedLocal(D, NewBD);
return NewBD;
P0217R3: Parsing support and framework for AST representation of C++1z decomposition declarations. There are a couple of things in the wording that seem strange here: decomposition declarations are permitted at namespace scope (which we partially support here) and they are permitted as the declaration in a template (which we reject). llvm-svn: 276492
2016-07-23 07:36:59 +08:00
}
Decl *TemplateDeclInstantiator::VisitDecompositionDecl(DecompositionDecl *D) {
P0217R3: template instantiation support for decomposition declarations. llvm-svn: 278458
2016-08-12 09:55:21 +08:00
// Transform the bindings first.
SmallVector<BindingDecl*, 16> NewBindings;
for (auto *OldBD : D->bindings())
NewBindings.push_back(cast<BindingDecl>(VisitBindingDecl(OldBD)));
ArrayRef<BindingDecl*> NewBindingArray = NewBindings;
auto *NewDD = cast_or_null<DecompositionDecl>(
VisitVarDecl(D, /*InstantiatingVarTemplate=*/false, &NewBindingArray));
if (!NewDD || NewDD->isInvalidDecl())
for (auto *NewBD : NewBindings)
NewBD->setInvalidDecl();
return NewDD;
P0217R3: Parsing support and framework for AST representation of C++1z decomposition declarations. There are a couple of things in the wording that seem strange here: decomposition declarations are permitted at namespace scope (which we partially support here) and they are permitted as the declaration in a template (which we reject). llvm-svn: 276492
2016-07-23 07:36:59 +08:00
}
Implement template instantiation for static data members of class templates, including in-class initializers. For example: template<typename T, T Divisor> class X { public: static const T value = 10 / Divisor; }; instantiated with, e.g., X<int, 5>::value to get the value '2'. llvm-svn: 67715
2009-03-26 07:32:15 +08:00
Decl *TemplateDeclInstantiator::VisitVarDecl(VarDecl *D) {
Refactor for clarity and simplicity. llvm-svn: 188974
2013-08-22 08:59:14 +08:00
return VisitVarDecl(D, /*InstantiatingVarTemplate=*/false);
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
}
Refactor for clarity and simplicity. llvm-svn: 188974
2013-08-22 08:59:14 +08:00
Decl *TemplateDeclInstantiator::VisitVarDecl(VarDecl *D,
P0217R3: template instantiation support for decomposition declarations. llvm-svn: 278458
2016-08-12 09:55:21 +08:00
bool InstantiatingVarTemplate,
ArrayRef<BindingDecl*> *Bindings) {
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
Clarify the difference between substitution and instantiation by renaming functions that don't instantiate definitions. llvm-svn: 80037
2009-08-26 06:02:44 +08:00
// Do substitution on the type of the declaration
Towards P0091R3: parsing support for class template argument deduction in typename-specifiers. This reinstates r293455, reverted in r293455, with a fix for cv-qualifier handling on dependent typename-specifiers. llvm-svn: 293544
2017-01-31 04:39:26 +08:00
TypeSourceInfo *DI = SemaRef.SubstType(
D->getTypeSourceInfo(), TemplateArgs, D->getTypeSpecStartLoc(),
D->getDeclName(), /*AllowDeducedTST*/true);
Preserve source information when substituting into VarDecls. llvm-svn: 84733
2009-10-21 10:39:02 +08:00
if (!DI)
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Implement template instantiation for static data members of class templates, including in-class initializers. For example: template<typename T, T Divisor> class X { public: static const T value = 10 / Divisor; }; instantiated with, e.g., X<int, 5>::value to get the value '2'. llvm-svn: 67715
2009-03-26 07:32:15 +08:00
Diagnose the instantiation of variables (including static data members) with function type. Fixes PR8047. llvm-svn: 113723
2010-09-12 15:37:24 +08:00
if (DI->getType()->isFunctionType()) {
SemaRef.Diag(D->getLocation(), diag::err_variable_instantiates_to_function)
<< D->isStaticDataMember() << DI->getType();
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Diagnose the instantiation of variables (including static data members) with function type. Fixes PR8047. llvm-svn: 113723
2010-09-12 15:37:24 +08:00
}
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Switch the semantic DeclContext for a block-scope declaration of a function or variable from being the function to being the enclosing namespace scope (in C++) or the TU (in C). This allows us to fix a selection of related issues where we would build incorrect redeclaration chains for such declarations, and fail to notice type mismatches. Such declarations are put into a new IdentifierNamespace, IDNS_LocalExtern, which is only found when searching scopes, and not found when searching DeclContexts. Such a declaration is only made visible in its DeclContext if there are no non-LocalExtern declarations. llvm-svn: 191064
2013-09-20 09:15:31 +08:00
DeclContext *DC = Owner;
if (D->isLocalExternDecl())
SemaRef.adjustContextForLocalExternDecl(DC);
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
// Build the instantiated declaration.
P0217R3: template instantiation support for decomposition declarations. llvm-svn: 278458
2016-08-12 09:55:21 +08:00
VarDecl *Var;
if (Bindings)
Var = DecompositionDecl::Create(SemaRef.Context, DC, D->getInnerLocStart(),
D->getLocation(), DI->getType(), DI,
D->getStorageClass(), *Bindings);
else
Var = VarDecl::Create(SemaRef.Context, DC, D->getInnerLocStart(),
D->getLocation(), D->getIdentifier(), DI->getType(),
DI, D->getStorageClass());
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Make sure that we infer __strong, etc. when we instantiate variables under ARC. Fixes <rdar://problem/10530209>. llvm-svn: 146307
2011-12-10 09:22:52 +08:00
// In ARC, infer 'retaining' for variables of retainable type.
Unify naming of LangOptions variable/get function across the Clang stack (Lex to AST). The member variable is always "LangOpts" and the member function is always "getLangOpts". Reviewed by Chris Lattner llvm-svn: 152536
2012-03-11 15:00:24 +08:00
if (SemaRef.getLangOpts().ObjCAutoRefCount &&
Make sure that we infer __strong, etc. when we instantiate variables under ARC. Fixes <rdar://problem/10530209>. llvm-svn: 146307
2011-12-10 09:22:52 +08:00
SemaRef.inferObjCARCLifetime(Var))
Var->setInvalidDecl();
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
// Substitute the nested name specifier, if any.
if (SubstQualifier(D, Var))
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Commit improved version of 111026 & 111027. Unused warnings for functions: -static functions -functions in anonymous namespace -class methods in anonymous namespace -class method specializations in anonymous namespace -function specializations in anonymous namespace Unused warnings for variables: -static variables -variables in anonymous namespace -static data members in anonymous namespace -static data members specializations in anonymous namespace Reveals lots of opportunities for dead code removal in llvm codebase that will interest my esteemed colleagues. llvm-svn: 111086
2010-08-15 09:15:20 +08:00
Switch the semantic DeclContext for a block-scope declaration of a function or variable from being the function to being the enclosing namespace scope (in C++) or the TU (in C). This allows us to fix a selection of related issues where we would build incorrect redeclaration chains for such declarations, and fail to notice type mismatches. Such declarations are put into a new IdentifierNamespace, IDNS_LocalExtern, which is only found when searching scopes, and not found when searching DeclContexts. Such a declaration is only made visible in its DeclContext if there are no non-LocalExtern declarations. llvm-svn: 191064
2013-09-20 09:15:31 +08:00
SemaRef.BuildVariableInstantiation(Var, D, TemplateArgs, LateAttrs, Owner,
Refactor for clarity and simplicity. llvm-svn: 188974
2013-08-22 08:59:14 +08:00
StartingScope, InstantiatingVarTemplate);
Rewrite NRVO determination. Track NRVO candidates on the parser Scope and apply the NRVO candidate flag to all possible NRVO candidates here, and remove the flags in computeNRVO or upon template instantiation. A variable now has NRVO applied if and only if every return statement in that scope returns that variable. This is nearly optimal. Performs NRVO roughly 7% more often in a bootstrap build of clang. Patch co-authored by Richard Smith. llvm-svn: 207890
2014-05-03 08:41:18 +08:00
if (D->isNRVOVariable()) {
QualType ReturnType = cast<FunctionDecl>(DC)->getReturnType();
if (SemaRef.isCopyElisionCandidate(ReturnType, Var, false))
Var->setNRVOVariable(true);
}
Retain isImplicit flag for local variable declarations when instantiating templates. Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D3924 llvm-svn: 209686
2014-05-28 05:29:22 +08:00
Var->setImplicit(D->isImplicit());
Implement template instantiation for static data members of class templates, including in-class initializers. For example: template<typename T, T Divisor> class X { public: static const T value = 10 / Divisor; }; instantiated with, e.g., X<int, 5>::value to get the value '2'. llvm-svn: 67715
2009-03-26 07:32:15 +08:00
return Var;
}
Added AccessSpecDecl node. llvm-svn: 105525
2010-06-05 13:09:32 +08:00
Decl *TemplateDeclInstantiator::VisitAccessSpecDecl(AccessSpecDecl *D) {
AccessSpecDecl* AD
= AccessSpecDecl::Create(SemaRef.Context, D->getAccess(), Owner,
D->getAccessSpecifierLoc(), D->getColonLoc());
Owner->addHiddenDecl(AD);
return AD;
}
Refactor instantiation of declarations within a template into a much cleaner visitor framework. Added a visitor for declarations, which is quite similar to the visitor for statatements. llvm-svn: 67104
2009-03-18 05:15:40 +08:00
Decl *TemplateDeclInstantiator::VisitFieldDecl(FieldDecl *D) {
bool Invalid = false;
DeclaratorInfo -> TypeSourceInfo. Makes an effort to rename associated variables, but the results are imperfect. For posterity, I did: cat <<EOF > $cmdfile s/DeclaratorInfo/TypeSourceInfo/g s/DInfo/TInfo/g s/TypeTypeSourceInfo/TypeSourceInfo/g s/SourceTypeSourceInfo/TypeSourceInfo/g EOF find lib -name '*.cpp' -not -path 'lib/Parse/*' -exec sed -i '' -f $cmdfile '{}' \; find lib -name '*.h' -exec sed -i '' -f $cmdfile '{}' \; find include -name '*.h' -not -path 'include/clang/Parse/*' -not -path 'include/clang/Basic/*' -exec sed -i '' -f $cmdfile '{}' \; llvm-svn: 90743
2009-12-07 10:54:59 +08:00
TypeSourceInfo *DI = D->getTypeSourceInfo();
Introduce the notion of instantiation dependence into Clang's AST. A type/expression/template argument/etc. is instantiation-dependent if it somehow involves a template parameter, even if it doesn't meet the requirements for the more common kinds of dependence (dependent type, type-dependent expression, value-dependent expression). When we see an instantiation-dependent type, we know we always need to perform substitution into that instantiation-dependent type. This keeps us from short-circuiting evaluation in places where we shouldn't, and lets us properly implement C++0x [temp.type]p2. In theory, this would also allow us to properly mangle instantiation-dependent-but-not-dependent decltype types per the Itanium C++ ABI, but we aren't quite there because we still mangle based on the canonical type in cases like, e.g., template<unsigned> struct A { }; template<typename T> void f(A<sizeof(sizeof(decltype(T() + T())))>) { } template void f<int>(A<sizeof(sizeof(int))>); and therefore get the wrong answer. llvm-svn: 134225
2011-07-01 09:22:09 +08:00
if (DI->getType()->isInstantiationDependentType() ||
Make sure that we instantiate variably modified types, even if they aren't dependent. Fixes <rdar://problem/8020206>. llvm-svn: 104511
2010-05-25 01:22:01 +08:00
DI->getType()->isVariablyModifiedType()) {
Preserve type source information when substituting into FieldDecls. Just r84734 now that some fundamental work has been completed. llvm-svn: 84914
2009-10-23 07:33:21 +08:00
DI = SemaRef.SubstType(DI, TemplateArgs,
D->getLocation(), D->getDeclName());
if (!DI) {
DeclaratorInfo -> TypeSourceInfo. Makes an effort to rename associated variables, but the results are imperfect. For posterity, I did: cat <<EOF > $cmdfile s/DeclaratorInfo/TypeSourceInfo/g s/DInfo/TInfo/g s/TypeTypeSourceInfo/TypeSourceInfo/g s/SourceTypeSourceInfo/TypeSourceInfo/g EOF find lib -name '*.cpp' -not -path 'lib/Parse/*' -exec sed -i '' -f $cmdfile '{}' \; find lib -name '*.h' -exec sed -i '' -f $cmdfile '{}' \; find include -name '*.h' -not -path 'include/clang/Parse/*' -not -path 'include/clang/Basic/*' -exec sed -i '' -f $cmdfile '{}' \; llvm-svn: 90743
2009-12-07 10:54:59 +08:00
DI = D->getTypeSourceInfo();
Preserve type source information when substituting into FieldDecls. Just r84734 now that some fundamental work has been completed. llvm-svn: 84914
2009-10-23 07:33:21 +08:00
Invalid = true;
} else if (DI->getType()->isFunctionType()) {
Refactor instantiation of declarations within a template into a much cleaner visitor framework. Added a visitor for declarations, which is quite similar to the visitor for statatements. llvm-svn: 67104
2009-03-18 05:15:40 +08:00
// C++ [temp.arg.type]p3:
// If a declaration acquires a function type through a type
// dependent on a template-parameter and this causes a
// declaration that does not use the syntactic form of a
// function declarator to have function type, the program is
// ill-formed.
SemaRef.Diag(D->getLocation(), diag::err_field_instantiates_to_function)
Preserve type source information when substituting into FieldDecls. Just r84734 now that some fundamental work has been completed. llvm-svn: 84914
2009-10-23 07:33:21 +08:00
<< DI->getType();
Refactor instantiation of declarations within a template into a much cleaner visitor framework. Added a visitor for declarations, which is quite similar to the visitor for statatements. llvm-svn: 67104
2009-03-18 05:15:40 +08:00
Invalid = true;
}
When we encounter a non-dependent type during template instantiation, mark any declarations we see inside of that type as "referenced". Fixes PR7079. llvm-svn: 103323
2010-05-08 07:12:07 +08:00
} else {
SemaRef.MarkDeclarationsReferencedInType(D->getLocation(), DI->getType());
Refactor instantiation of declarations within a template into a much cleaner visitor framework. Added a visitor for declarations, which is quite similar to the visitor for statatements. llvm-svn: 67104
2009-03-18 05:15:40 +08:00
}
Expr *BitWidth = D->getBitWidth();
if (Invalid)
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
BitWidth = nullptr;
Refactor instantiation of declarations within a template into a much cleaner visitor framework. Added a visitor for declarations, which is quite similar to the visitor for statatements. llvm-svn: 67104
2009-03-18 05:15:40 +08:00
else if (BitWidth) {
Unlike in C++03, a constant-expression is not an unevaluated operand in C++11. Split out a new ExpressionEvaluationContext flag for this case, and don't treat it as unevaluated in C++11. This fixes some crash-on-invalids where we would allow references to class members in potentially-evaluated constant expressions in static member functions, and also fixes half of PR10177. The fix to PR10177 exposed a case where template instantiation failed to provide a source location for a diagnostic, so TreeTransform has been tweaked to supply source locations when transforming a type. The source location is still not very good, but MarkDeclarationsReferencedInType would need to operate on a TypeLoc to improve it further. Also fix MarkDeclarationReferenced in C++98 mode to trigger instantiation for static data members of class templates which are used in constant expressions. This fixes a link-time problem, but we still incorrectly treat the member as non-constant. The rest of the fix for that issue is blocked on PCH support for early-instantiated static data members, which will be added in a subsequent patch. llvm-svn: 146955
2011-12-20 10:08:33 +08:00
// The bit-width expression is a constant expression.
[NFC, Scoped Enum] Convert Sema::ExpressionEvaluationContext into a scoped Enum - also replace direct equality checks against the ConstantEvaluated enumerator with isConstantEvaluted(), in anticipation of adding finer granularity to the various ConstantEvaluated contexts and reinstating certain restrictions on where lambda expressions can occur in C++17. - update the clang tablegen backend that uses these Enumerators, and add the relevant scope where needed. llvm-svn: 299316
2017-04-02 05:30:49 +08:00
EnterExpressionEvaluationContext Unevaluated(
SemaRef, Sema::ExpressionEvaluationContext::ConstantEvaluated);
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
OwningExprResult -> ExprResult. This patch brought to you by M-x query-replace-regexp \(Sema::\|Action::\|Parser::\|\)Owning\(Expr\|Stmt\)Result -> \2Result llvm-svn: 111903
2010-08-24 14:29:42 +08:00
ExprResult InstantiatedBitWidth
Clarify the difference between substitution and instantiation by renaming functions that don't instantiate definitions. llvm-svn: 80037
2009-08-26 06:02:44 +08:00
= SemaRef.SubstExpr(BitWidth, TemplateArgs);
Refactor instantiation of declarations within a template into a much cleaner visitor framework. Added a visitor for declarations, which is quite similar to the visitor for statatements. llvm-svn: 67104
2009-03-18 05:15:40 +08:00
if (InstantiatedBitWidth.isInvalid()) {
Invalid = true;
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
BitWidth = nullptr;
Refactor instantiation of declarations within a template into a much cleaner visitor framework. Added a visitor for declarations, which is quite similar to the visitor for statatements. llvm-svn: 67104
2009-03-18 05:15:40 +08:00
} else
Refactoring. Remove release and take methods from ActionResult. Rename takeAs to getAs. llvm-svn: 209800
2014-05-29 18:55:11 +08:00
BitWidth = InstantiatedBitWidth.getAs<Expr>();
Refactor instantiation of declarations within a template into a much cleaner visitor framework. Added a visitor for declarations, which is quite similar to the visitor for statatements. llvm-svn: 67104
2009-03-18 05:15:40 +08:00
}
Preserve type source information when substituting into FieldDecls. Just r84734 now that some fundamental work has been completed. llvm-svn: 84914
2009-10-23 07:33:21 +08:00
FieldDecl *Field = SemaRef.CheckFieldDecl(D->getDeclName(),
DI->getType(), DI,
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
cast<RecordDecl>(Owner),
Refactor instantiation of declarations within a template into a much cleaner visitor framework. Added a visitor for declarations, which is quite similar to the visitor for statatements. llvm-svn: 67104
2009-03-18 05:15:40 +08:00
D->getLocation(),
D->isMutable(),
BitWidth,
PR13064: Store whether an in-class initializer uses direct or copy initialization, and use that information to produce the right kind of initialization during template instantiation. llvm-svn: 158288
2012-06-10 11:12:00 +08:00
D->getInClassInitStyle(),
Correct the starting location for instantiations of field declarations which start with a cv-qualifier. DeclaratorDecl::getTypeSpecStartLoc() does not produce the location of the first type-specifier (the cv-qualifier) in this case, because we don't track source locations for cv-qualifiers. No test here: I've not found a way to test this with a lit-style test, and introducing a gtest test for this seems unwarranted. Suggestions welcome! Patch by Daniel Jasper! llvm-svn: 157311
2012-05-23 12:22:22 +08:00
D->getInnerLocStart(),
Refactor instantiation of declarations within a template into a much cleaner visitor framework. Added a visitor for declarations, which is quite similar to the visitor for statatements. llvm-svn: 67104
2009-03-18 05:15:40 +08:00
D->getAccess(),
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
nullptr);
Testing and some minor fixes for explicit template instantiation. llvm-svn: 84129
2009-10-15 04:14:33 +08:00
if (!Field) {
cast<Decl>(Owner)->setInvalidDecl();
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Testing and some minor fixes for explicit template instantiation. llvm-svn: 84129
2009-10-15 04:14:33 +08:00
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Delayed template instantiation of late-parsed attributes. llvm-svn: 148595
2012-01-21 06:50:54 +08:00
SemaRef.InstantiateAttrs(TemplateArgs, D, Field, LateAttrs, StartingScope);
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Implement [dcl.align]p5 and C11 6.7.5/4: alignas cannot underalign. Also support alignas(0), which C++11 and C11 require us to ignore. llvm-svn: 174157
2013-02-01 16:12:08 +08:00
if (Field->hasAttrs())
SemaRef.CheckAlignasUnderalignment(Field);
Fix a codegen crash when a class template has a constructor that does member initialization of an anonymous union. llvm-svn: 80826
2009-09-03 03:17:55 +08:00
if (Invalid)
Field->setInvalidDecl();
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Fix a codegen crash when a class template has a constructor that does member initialization of an anonymous union. llvm-svn: 80826
2009-09-03 03:17:55 +08:00
if (!Field->getDeclName()) {
// Keep track of where this decl came from.
SemaRef.Context.setInstantiatedFromUnnamedFieldDecl(Field, D);
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
}
When instantiating anonymous structs/unions within a function, make sure that the anonymous struct/union record declaration gets instantiated before the variable declaration, and that it and its fields (recursively) get entries in the local instantiation map. Fixes PR7088. llvm-svn: 104305
2010-05-21 08:31:19 +08:00
if (CXXRecordDecl *Parent= dyn_cast<CXXRecordDecl>(Field->getDeclContext())) {
if (Parent->isAnonymousStructOrUnion() &&
Rename DeclContext::getLookupContext to getRedeclContext and change its semantics slightly. No functionality change in the absence of inline namespaces. Also, change a few places where inline namespaces actually make a difference to be prepared for them. llvm-svn: 112563
2010-08-31 08:36:30 +08:00
Parent->getRedeclContext()->isFunctionOrMethod())
When instantiating anonymous structs/unions within a function, make sure that the anonymous struct/union record declaration gets instantiated before the variable declaration, and that it and its fields (recursively) get entries in the local instantiation map. Fixes PR7088. llvm-svn: 104305
2010-05-21 08:31:19 +08:00
SemaRef.CurrentInstantiationScope->InstantiatedLocal(D, Field);
Refactor instantiation of declarations within a template into a much cleaner visitor framework. Added a visitor for declarations, which is quite similar to the visitor for statatements. llvm-svn: 67104
2009-03-18 05:15:40 +08:00
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Fix a codegen crash when a class template has a constructor that does member initialization of an anonymous union. llvm-svn: 80826
2009-09-03 03:17:55 +08:00
Field->setImplicit(D->isImplicit());
First pass at collecting access-specifier information along inheritance paths. Triggers lots of assertions about missing access information; fix them. Will actually consume this information soon. llvm-svn: 94038
2010-01-21 05:53:11 +08:00
Field->setAccess(D->getAccess());
Fix a codegen crash when a class template has a constructor that does member initialization of an anonymous union. llvm-svn: 80826
2009-09-03 03:17:55 +08:00
Owner->addDecl(Field);
Refactor instantiation of declarations within a template into a much cleaner visitor framework. Added a visitor for declarations, which is quite similar to the visitor for statatements. llvm-svn: 67104
2009-03-18 05:15:40 +08:00
return Field;
}
Basic support for Microsoft property declarations and references thereto. Patch by Tong Shen! llvm-svn: 179585
2013-04-16 15:28:30 +08:00
Decl *TemplateDeclInstantiator::VisitMSPropertyDecl(MSPropertyDecl *D) {
bool Invalid = false;
TypeSourceInfo *DI = D->getTypeSourceInfo();
if (DI->getType()->isVariablyModifiedType()) {
SemaRef.Diag(D->getLocation(), diag::err_property_is_variably_modified)
Removing some more unnecessary manual quotes from attribute diagnostics. llvm-svn: 198387
2014-01-03 09:09:27 +08:00
<< D;
Basic support for Microsoft property declarations and references thereto. Patch by Tong Shen! llvm-svn: 179585
2013-04-16 15:28:30 +08:00
Invalid = true;
} else if (DI->getType()->isInstantiationDependentType()) {
DI = SemaRef.SubstType(DI, TemplateArgs,
D->getLocation(), D->getDeclName());
if (!DI) {
DI = D->getTypeSourceInfo();
Invalid = true;
} else if (DI->getType()->isFunctionType()) {
// C++ [temp.arg.type]p3:
// If a declaration acquires a function type through a type
// dependent on a template-parameter and this causes a
// declaration that does not use the syntactic form of a
// function declarator to have function type, the program is
// ill-formed.
SemaRef.Diag(D->getLocation(), diag::err_field_instantiates_to_function)
<< DI->getType();
Invalid = true;
}
} else {
SemaRef.MarkDeclarationsReferencedInType(D->getLocation(), DI->getType());
}
Add class-specific operator new to Decl hierarchy. This guarantees that Decls can't accidentally be allocated the wrong way (missing prefix data for decls from AST files, for instance) and simplifies the CreateDeserialized functions a little. An extra DeclContext* parameter to the not-from-AST-file operator new allows us to ensure that we don't accidentally call the wrong one when deserializing (when we don't have a DeclContext), allows some extra checks, and prepares for some planned modules-related changes to Decl allocation. No functionality change intended. llvm-svn: 195426
2013-11-22 17:01:48 +08:00
MSPropertyDecl *Property = MSPropertyDecl::Create(
SemaRef.Context, Owner, D->getLocation(), D->getDeclName(), DI->getType(),
DI, D->getLocStart(), D->getGetterId(), D->getSetterId());
Basic support for Microsoft property declarations and references thereto. Patch by Tong Shen! llvm-svn: 179585
2013-04-16 15:28:30 +08:00
SemaRef.InstantiateAttrs(TemplateArgs, D, Property, LateAttrs,
StartingScope);
if (Invalid)
Property->setInvalidDecl();
Property->setAccess(D->getAccess());
Owner->addDecl(Property);
return Property;
}
Major anonymous union/struct redesign. A new AST node is introduced: def IndirectField : DDecl<Value>; IndirectFields are injected into the anonymous's parent scope and chain back to the original field. Name lookup for anonymous entities now result in an IndirectFieldDecl instead of a FieldDecl. There is no functionality change, the code generated should be the same. llvm-svn: 119919
2010-11-21 14:08:52 +08:00
Decl *TemplateDeclInstantiator::VisitIndirectFieldDecl(IndirectFieldDecl *D) {
NamedDecl **NamedChain =
new (SemaRef.Context)NamedDecl*[D->getChainingSize()];
int i = 0;
Renaming the chains() ranged iterator to chain() per suggestion by Richard Smith. llvm-svn: 203262
2014-03-08 02:36:15 +08:00
for (auto *PI : D->chain()) {
[C++11] Replacing IndirectFieldDecl iterators chain_begin() and chain_end() with iterator_range chains(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203261
2014-03-08 02:11:58 +08:00
NamedDecl *Next = SemaRef.FindInstantiatedDecl(D->getLocation(), PI,
Patch up several Sema::FindInstantiatedDecl() callers, so that they'll properly cope with NULL return values. llvm-svn: 127024
2011-03-05 03:46:35 +08:00
TemplateArgs);
if (!Next)
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Patch up several Sema::FindInstantiatedDecl() callers, so that they'll properly cope with NULL return values. llvm-svn: 127024
2011-03-05 03:46:35 +08:00
NamedChain[i++] = Next;
}
Major anonymous union/struct redesign. A new AST node is introduced: def IndirectField : DDecl<Value>; IndirectFields are injected into the anonymous's parent scope and chain back to the original field. Name lookup for anonymous entities now result in an IndirectFieldDecl instead of a FieldDecl. There is no functionality change, the code generated should be the same. llvm-svn: 119919
2010-11-21 14:08:52 +08:00
Fix PR8760: IndirectFieldDecl Type was not updated during template instantiation. llvm-svn: 121363
2010-12-09 18:07:54 +08:00
QualType T = cast<FieldDecl>(NamedChain[i-1])->getType();
Adding attributes to the IndirectFieldDecl that we generate for anonymous struct/union fields. This fixes PR20930. llvm-svn: 219807
2014-10-16 00:58:18 +08:00
IndirectFieldDecl *IndirectField = IndirectFieldDecl::Create(
SemaRef.Context, Owner, D->getLocation(), D->getIdentifier(), T,
Use more ArrayRefs No functional change is intended, just a small refactoring. llvm-svn: 273647
2016-06-24 12:05:48 +08:00
{NamedChain, D->getChainingSize()});
Major anonymous union/struct redesign. A new AST node is introduced: def IndirectField : DDecl<Value>; IndirectFields are injected into the anonymous's parent scope and chain back to the original field. Name lookup for anonymous entities now result in an IndirectFieldDecl instead of a FieldDecl. There is no functionality change, the code generated should be the same. llvm-svn: 119919
2010-11-21 14:08:52 +08:00
Prune CRLF. llvm-svn: 220678
2014-10-27 20:37:26 +08:00
for (const auto *Attr : D->attrs())
IndirectField->addAttr(Attr->clone(SemaRef.Context));
Major anonymous union/struct redesign. A new AST node is introduced: def IndirectField : DDecl<Value>; IndirectFields are injected into the anonymous's parent scope and chain back to the original field. Name lookup for anonymous entities now result in an IndirectFieldDecl instead of a FieldDecl. There is no functionality change, the code generated should be the same. llvm-svn: 119919
2010-11-21 14:08:52 +08:00
IndirectField->setImplicit(D->isImplicit());
IndirectField->setAccess(D->getAccess());
Owner->addDecl(IndirectField);
return IndirectField;
}
Omnibus friend decl refactoring. Instead of cloning AST classes for friend declarations of same, introduce a single AST class and add appropriate bits (encoded in the namespace) for whether a decl is "real" or not. Much hackery about previously-declared / not-previously-declared, but it's essentially mandated by the standard that friends alter lookup, and this is at least fairly non-intrusive. Refactor the Sema methods specific to friends for cleaner flow and less nesting. Incidentally solve a few bugs, but I remain confident that we can put them back. llvm-svn: 80353
2009-08-28 15:59:38 +08:00
Decl *TemplateDeclInstantiator::VisitFriendDecl(FriendDecl *D) {
// Handle friend type expressions by simply substituting template
Improve handling of friend types in several ways: - When instantiating a friend type template, perform semantic analysis on the resulting type. - Downgrade the errors concerning friend type declarations that do not refer to classes to ExtWarns in C++98/03. C++0x allows practically any type to be befriended, and ignores the friend declaration if the type is not a class. llvm-svn: 100635
2010-04-08 01:57:12 +08:00
// parameters into the pattern type and checking the result.
Preserve type-source information in friend declarations. llvm-svn: 99525
2010-03-26 02:04:51 +08:00
if (TypeSourceInfo *Ty = D->getFriendType()) {
Re-applies the patch first applied way back in r106099, with accompanying fixes to make it work today. The core of this patch is to provide a link from a TemplateTypeParmType back to the TemplateTypeParmDecl node which declared it. This in turn provides much more precise information about the type, where it came from, and how it functions for AST consumers. To make the patch work almost a year after its first attempt, it needed serialization support, and it now retains the old getName() interface. Finally, it requires us to not attempt to instantiate the type in an unsupported friend decl -- specifically those coming from template friend decls but which refer to a specific type through a dependent name. A cleaner representation of the last item would be to build FriendTemplateDecl nodes for these, storing their template parameters etc, and to perform proper instantation of them like any other template declaration. They can still be flagged as unsupported for the purpose of access checking, etc. This passed an asserts-enabled bootstrap for me, and the reduced test case mentioned in the original review thread no longer causes issues, likely fixed at somewhere amidst the 24k revisions that have elapsed. llvm-svn: 130628
2011-05-01 08:51:33 +08:00
TypeSourceInfo *InstTy;
// If this is an unsupported friend, don't bother substituting template
// arguments into it. The actual type referred to won't be used by any
// parts of Clang, and may not be valid for instantiating. Just use the
// same info for the instantiated friend.
if (D->isUnsupportedFriend()) {
InstTy = Ty;
} else {
InstTy = SemaRef.SubstType(Ty, TemplateArgs,
D->getLocation(), DeclarationName());
}
if (!InstTy)
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Support friend declarations in templates and test that argdep lookup still works. llvm-svn: 78979
2009-08-14 10:03:10 +08:00
Per C++11 [class.friend]p3, the 'friend' keyword must appear first in a non-function friend declaration. Patch by Josh Magee! llvm-svn: 164273
2012-09-20 09:31:00 +08:00
FriendDecl *FD = SemaRef.CheckFriendTypeDecl(D->getLocStart(),
Fixed FriendDecl source locations. llvm-svn: 143295
2011-10-30 04:52:52 +08:00
D->getFriendLoc(), InstTy);
Improve handling of friend types in several ways: - When instantiating a friend type template, perform semantic analysis on the resulting type. - Downgrade the errors concerning friend type declarations that do not refer to classes to ExtWarns in C++98/03. C++0x allows practically any type to be befriended, and ignores the friend declaration if the type is not a class. llvm-svn: 100635
2010-04-08 01:57:12 +08:00
if (!FD)
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Improve handling of friend types in several ways: - When instantiating a friend type template, perform semantic analysis on the resulting type. - Downgrade the errors concerning friend type declarations that do not refer to classes to ExtWarns in C++98/03. C++0x allows practically any type to be befriended, and ignores the friend declaration if the type is not a class. llvm-svn: 100635
2010-04-08 01:57:12 +08:00
FD->setAccess(AS_public);
Redirect templated friend class decls to a new Sema callback and construct an unsupported friend when there's a friend with a templated scope specifier. Fixes a consistency crash, rdar://problem/8540527 llvm-svn: 116786
2010-10-19 09:40:49 +08:00
FD->setUnsupportedFriend(D->isUnsupportedFriend());
Improve handling of friend types in several ways: - When instantiating a friend type template, perform semantic analysis on the resulting type. - Downgrade the errors concerning friend type declarations that do not refer to classes to ExtWarns in C++98/03. C++0x allows practically any type to be befriended, and ignores the friend declaration if the type is not a class. llvm-svn: 100635
2010-04-08 01:57:12 +08:00
Owner->addDecl(FD);
return FD;
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
}
Improve handling of friend types in several ways: - When instantiating a friend type template, perform semantic analysis on the resulting type. - Downgrade the errors concerning friend type declarations that do not refer to classes to ExtWarns in C++98/03. C++0x allows practically any type to be befriended, and ignores the friend declaration if the type is not a class. llvm-svn: 100635
2010-04-08 01:57:12 +08:00
NamedDecl *ND = D->getFriendDecl();
assert(ND && "friend decl must be a decl or a type!");
Preserve type-source information in friend declarations. llvm-svn: 99525
2010-03-26 02:04:51 +08:00
Implement dependent friend function template specializations. llvm-svn: 100753
2010-04-08 17:05:18 +08:00
// All of the Visit implementations for the various potential friend
// declarations have to be carefully written to work for friend
// objects, with the most important detail being that the target
// decl should almost certainly not be placed in Owner.
Decl *NewND = Visit(ND);
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
if (!NewND) return nullptr;
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Omnibus friend decl refactoring. Instead of cloning AST classes for friend declarations of same, introduce a single AST class and add appropriate bits (encoded in the namespace) for whether a decl is "real" or not. Much hackery about previously-declared / not-previously-declared, but it's essentially mandated by the standard that friends alter lookup, and this is at least fairly non-intrusive. Refactor the Sema methods specific to friends for cleaner flow and less nesting. Incidentally solve a few bugs, but I remain confident that we can put them back. llvm-svn: 80353
2009-08-28 15:59:38 +08:00
FriendDecl *FD =
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
FriendDecl::Create(SemaRef.Context, Owner, D->getLocation(),
Improve handling of friend types in several ways: - When instantiating a friend type template, perform semantic analysis on the resulting type. - Downgrade the errors concerning friend type declarations that do not refer to classes to ExtWarns in C++98/03. C++0x allows practically any type to be befriended, and ignores the friend declaration if the type is not a class. llvm-svn: 100635
2010-04-08 01:57:12 +08:00
cast<NamedDecl>(NewND), D->getFriendLoc());
For consistency, just make friend declarations AS_public. llvm-svn: 80420
2009-08-29 11:50:18 +08:00
FD->setAccess(AS_public);
Redirect templated friend class decls to a new Sema callback and construct an unsupported friend when there's a friend with a templated scope specifier. Fixes a consistency crash, rdar://problem/8540527 llvm-svn: 116786
2010-10-19 09:40:49 +08:00
FD->setUnsupportedFriend(D->isUnsupportedFriend());
Omnibus friend decl refactoring. Instead of cloning AST classes for friend declarations of same, introduce a single AST class and add appropriate bits (encoded in the namespace) for whether a decl is "real" or not. Much hackery about previously-declared / not-previously-declared, but it's essentially mandated by the standard that friends alter lookup, and this is at least fairly non-intrusive. Refactor the Sema methods specific to friends for cleaner flow and less nesting. Incidentally solve a few bugs, but I remain confident that we can put them back. llvm-svn: 80353
2009-08-28 15:59:38 +08:00
Owner->addDecl(FD);
return FD;
Support friend declarations in templates and test that argdep lookup still works. llvm-svn: 78979
2009-08-14 10:03:10 +08:00
}
Refactor instantiation of declarations within a template into a much cleaner visitor framework. Added a visitor for declarations, which is quite similar to the visitor for statatements. llvm-svn: 67104
2009-03-18 05:15:40 +08:00
Decl *TemplateDeclInstantiator::VisitStaticAssertDecl(StaticAssertDecl *D) {
Expr *AssertExpr = D->getAssertExpr();
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Unlike in C++03, a constant-expression is not an unevaluated operand in C++11. Split out a new ExpressionEvaluationContext flag for this case, and don't treat it as unevaluated in C++11. This fixes some crash-on-invalids where we would allow references to class members in potentially-evaluated constant expressions in static member functions, and also fixes half of PR10177. The fix to PR10177 exposed a case where template instantiation failed to provide a source location for a diagnostic, so TreeTransform has been tweaked to supply source locations when transforming a type. The source location is still not very good, but MarkDeclarationsReferencedInType would need to operate on a TypeLoc to improve it further. Also fix MarkDeclarationReferenced in C++98 mode to trigger instantiation for static data members of class templates which are used in constant expressions. This fixes a link-time problem, but we still incorrectly treat the member as non-constant. The rest of the fix for that issue is blocked on PCH support for early-instantiated static data members, which will be added in a subsequent patch. llvm-svn: 146955
2011-12-20 10:08:33 +08:00
// The expression in a static assertion is a constant expression.
[NFC, Scoped Enum] Convert Sema::ExpressionEvaluationContext into a scoped Enum - also replace direct equality checks against the ConstantEvaluated enumerator with isConstantEvaluted(), in anticipation of adding finer granularity to the various ConstantEvaluated contexts and reinstating certain restrictions on where lambda expressions can occur in C++17. - update the clang tablegen backend that uses these Enumerators, and add the relevant scope where needed. llvm-svn: 299316
2017-04-02 05:30:49 +08:00
EnterExpressionEvaluationContext Unevaluated(
SemaRef, Sema::ExpressionEvaluationContext::ConstantEvaluated);
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
OwningExprResult -> ExprResult. This patch brought to you by M-x query-replace-regexp \(Sema::\|Action::\|Parser::\|\)Owning\(Expr\|Stmt\)Result -> \2Result llvm-svn: 111903
2010-08-24 14:29:42 +08:00
ExprResult InstantiatedAssertExpr
Clarify the difference between substitution and instantiation by renaming functions that don't instantiate definitions. llvm-svn: 80037
2009-08-26 06:02:44 +08:00
= SemaRef.SubstExpr(AssertExpr, TemplateArgs);
Refactor instantiation of declarations within a template into a much cleaner visitor framework. Added a visitor for declarations, which is quite similar to the visitor for statatements. llvm-svn: 67104
2009-03-18 05:15:40 +08:00
if (InstantiatedAssertExpr.isInvalid())
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Refactor instantiation of declarations within a template into a much cleaner visitor framework. Added a visitor for declarations, which is quite similar to the visitor for statatements. llvm-svn: 67104
2009-03-18 05:15:40 +08:00
Stop instantiating a class if we hit a static_assert failure. Also, if the static_assert fails when parsing the template, don't diagnose it again on every instantiation. llvm-svn: 160088
2012-07-12 06:37:56 +08:00
return SemaRef.BuildStaticAssertDeclaration(D->getLocation(),
Kill off ExprArg (now just Expr*) and StmtArg (now just Stmt*). llvm-svn: 111863
2010-08-24 07:25:46 +08:00
InstantiatedAssertExpr.get(),
Stop instantiating a class if we hit a static_assert failure. Also, if the static_assert fails when parsing the template, don't diagnose it again on every instantiation. llvm-svn: 160088
2012-07-12 06:37:56 +08:00
D->getMessage(),
D->getRParenLoc(),
D->isFailed());
Refactor instantiation of declarations within a template into a much cleaner visitor framework. Added a visitor for declarations, which is quite similar to the visitor for statatements. llvm-svn: 67104
2009-03-18 05:15:40 +08:00
}
Decl *TemplateDeclInstantiator::VisitEnumDecl(EnumDecl *D) {
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
EnumDecl *PrevDecl = nullptr;
[modules] When instantiating a class member, don't expect to find the previous declaration in the instantiation if the previous declaration came from another definition of the class template that got merged into the pattern definition. llvm-svn: 219552
2014-10-11 08:37:16 +08:00
if (EnumDecl *PatternPrev = getPreviousDeclForInstantiation(D)) {
Handle instantiations of redeclarations of forward-declared enumerations within templated functions. Build a redeclaration chain, and only instantiate the definition of the enum when visiting the defining declaration. llvm-svn: 153427
2012-03-26 12:58:10 +08:00
NamedDecl *Prev = SemaRef.FindInstantiatedDecl(D->getLocation(),
[modules] When instantiating a class member, don't expect to find the previous declaration in the instantiation if the previous declaration came from another definition of the class template that got merged into the pattern definition. llvm-svn: 219552
2014-10-11 08:37:16 +08:00
PatternPrev,
Handle instantiations of redeclarations of forward-declared enumerations within templated functions. Build a redeclaration chain, and only instantiate the definition of the enum when visiting the defining declaration. llvm-svn: 153427
2012-03-26 12:58:10 +08:00
TemplateArgs);
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
if (!Prev) return nullptr;
Handle instantiations of redeclarations of forward-declared enumerations within templated functions. Build a redeclaration chain, and only instantiate the definition of the enum when visiting the defining declaration. llvm-svn: 153427
2012-03-26 12:58:10 +08:00
PrevDecl = cast<EnumDecl>(Prev);
}
Fixed InnerLocStart. llvm-svn: 127330
2011-03-09 22:09:51 +08:00
EnumDecl *Enum = EnumDecl::Create(SemaRef.Context, Owner, D->getLocStart(),
Refactor instantiation of declarations within a template into a much cleaner visitor framework. Added a visitor for declarations, which is quite similar to the visitor for statatements. llvm-svn: 67104
2009-03-18 05:15:40 +08:00
D->getLocation(), D->getIdentifier(),
Handle instantiations of redeclarations of forward-declared enumerations within templated functions. Build a redeclaration chain, and only instantiate the definition of the enum when visiting the defining declaration. llvm-svn: 153427
2012-03-26 12:58:10 +08:00
PrevDecl, D->isScoped(),
Added struct/class syntactic info for c++0x scoped enum. llvm-svn: 120828
2010-12-04 02:54:17 +08:00
D->isScopedUsingClassTag(), D->isFixed());
Implement C++0x scoped enumerations, from Daniel Wallin! (and tweaked a bit by me). llvm-svn: 116122
2010-10-09 07:50:27 +08:00
if (D->isFixed()) {
Instantiating a class template should not instantiate the definition of any scoped enumeration members. Later uses of an enumeration temploid as a nested name specifier should cause its instantiation. Plus some groundwork for explicit specialization of member enumerations of class templates. llvm-svn: 152750
2012-03-15 07:13:10 +08:00
if (TypeSourceInfo *TI = D->getIntegerTypeSourceInfo()) {
Implement C++0x scoped enumerations, from Daniel Wallin! (and tweaked a bit by me). llvm-svn: 116122
2010-10-09 07:50:27 +08:00
// If we have type source information for the underlying type, it means it
// has been explicitly set by the user. Perform substitution on it before
// moving on.
SourceLocation UnderlyingLoc = TI->getTypeLoc().getBeginLoc();
Instantiating a class template should not instantiate the definition of any scoped enumeration members. Later uses of an enumeration temploid as a nested name specifier should cause its instantiation. Plus some groundwork for explicit specialization of member enumerations of class templates. llvm-svn: 152750
2012-03-15 07:13:10 +08:00
TypeSourceInfo *NewTI = SemaRef.SubstType(TI, TemplateArgs, UnderlyingLoc,
DeclarationName());
if (!NewTI || SemaRef.CheckEnumUnderlyingType(NewTI))
Implement C++0x scoped enumerations, from Daniel Wallin! (and tweaked a bit by me). llvm-svn: 116122
2010-10-09 07:50:27 +08:00
Enum->setIntegerType(SemaRef.Context.IntTy);
Instantiating a class template should not instantiate the definition of any scoped enumeration members. Later uses of an enumeration temploid as a nested name specifier should cause its instantiation. Plus some groundwork for explicit specialization of member enumerations of class templates. llvm-svn: 152750
2012-03-15 07:13:10 +08:00
else
Enum->setIntegerTypeSourceInfo(NewTI);
} else {
Implement C++0x scoped enumerations, from Daniel Wallin! (and tweaked a bit by me). llvm-svn: 116122
2010-10-09 07:50:27 +08:00
assert(!D->getIntegerType()->isDependentType()
&& "Dependent type without type source info");
Enum->setIntegerType(D->getIntegerType());
}
}
Parse attributes on enumerators and instantiate attributes on enum decls. llvm-svn: 117182
2010-10-23 07:36:17 +08:00
SemaRef.InstantiateAttrs(TemplateArgs, D, Enum);
Instantiating a class template should not instantiate the definition of any scoped enumeration members. Later uses of an enumeration temploid as a nested name specifier should cause its instantiation. Plus some groundwork for explicit specialization of member enumerations of class templates. llvm-svn: 152750
2012-03-15 07:13:10 +08:00
Enum->setInstantiationOfMemberEnum(D, TSK_ImplicitInstantiation);
Pass access specifiers through to member classes and member enums. llvm-svn: 67710
2009-03-26 06:00:53 +08:00
Enum->setAccess(D->getAccess());
Sema: Propagate the mangling number into instantiations We would lose track of the mangling number assigned to the original declaration which would cause us to create manglings that didn't match the Itanium C++ specification. e.g. Two static fields with the same name inside of a function template would receive the same mangling with LLVM fixing up the second field so they wouldn't collide. This would create an incompatibility with other compilers following the Itanium ABI. I've confirmed that the new mangling is identical to the ones generated by icc and gcc. N.B. This was uncovered while working on Microsoft mangler. llvm-svn: 196368
2013-12-04 17:01:55 +08:00
// Forward the mangling number from the template to the instantiated decl.
SemaRef.Context.setManglingNumber(Enum, SemaRef.Context.getManglingNumber(D));
[MS ABI] Correctly mangle classes without names for linkage purposes A class without a name for linkage purposes gets a name along the lines of <unnamed-type-foo> where foo is either the name of a declarator which defined it (like a variable or field) or a typedef-name (like a typedef or alias-declaration). We handled the declarator case correctly but it would fall down during template instantiation if the declarator didn't share the tag's type. We failed to handle the typedef-name case at all. Instead, keep track of the association between the two and keep it up to date in the face of template instantiation. llvm-svn: 246469
2015-09-01 02:48:39 +08:00
// See if the old tag was defined along with a declarator.
// If it did, mark the new tag as being associated with that declarator.
if (DeclaratorDecl *DD = SemaRef.Context.getDeclaratorForUnnamedTagDecl(D))
SemaRef.Context.addDeclaratorForUnnamedTagDecl(Enum, DD);
// See if the old tag was defined along with a typedef.
// If it did, mark the new tag as being associated with that typedef.
if (TypedefNameDecl *TND = SemaRef.Context.getTypedefNameForUnnamedTagDecl(D))
SemaRef.Context.addTypedefNameForUnnamedTagDecl(Enum, TND);
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
if (SubstQualifier(D, Enum)) return nullptr;
De-ASTContext-ify DeclContext. Remove ASTContext parameter from DeclContext's methods. This change cascaded down to other Decl's methods and changes to call sites started "escalating". Timings using pre-tokenized "cocoa.h" showed only a ~1% increase in time run between and after this commit. llvm-svn: 74506
2009-06-30 10:36:12 +08:00
Owner->addDecl(Enum);
Instantiating a class template should not instantiate the definition of any scoped enumeration members. Later uses of an enumeration temploid as a nested name specifier should cause its instantiation. Plus some groundwork for explicit specialization of member enumerations of class templates. llvm-svn: 152750
2012-03-15 07:13:10 +08:00
Delay checking of dependent underlying types for redeclarations of member enumerations in templates until the template is instantiated. llvm-svn: 153426
2012-03-26 12:08:46 +08:00
EnumDecl *Def = D->getDefinition();
if (Def && Def != D) {
// If this is an out-of-line definition of an enum member template, check
// that the underlying types match in the instantiation of both
// declarations.
if (TypeSourceInfo *TI = Def->getIntegerTypeSourceInfo()) {
SourceLocation UnderlyingLoc = TI->getTypeLoc().getBeginLoc();
QualType DefnUnderlying =
SemaRef.SubstType(TI->getType(), TemplateArgs,
UnderlyingLoc, DeclarationName());
SemaRef.CheckEnumRedeclaration(Def->getLocation(), Def->isScoped(),
[MSVC Compat] Try to treat an implicit, fixed enum as an unfixed enum consider the following: enum E *p; enum E { e }; The above snippet is not ANSI C because 'enum E' has not bee defined when we are processing the declaration of 'p'; however, it is a popular extension to make the above work. This would fail using the Microsoft enum semantics because the definition of 'E' would implicitly have a fixed underlying type of 'int' which would trigger diagnostic messages about a mismatch between the declaration and the definition. Instead, treat fixed underlying types as not fixed for the purposes of the diagnostic. llvm-svn: 249674
2015-10-08 18:04:46 +08:00
DefnUnderlying,
/*EnumUnderlyingIsImplicit=*/false, Enum);
Delay checking of dependent underlying types for redeclarations of member enumerations in templates until the template is instantiated. llvm-svn: 153426
2012-03-26 12:08:46 +08:00
}
}
Refactor instantiation of declarations within a template into a much cleaner visitor framework. Added a visitor for declarations, which is quite similar to the visitor for statatements. llvm-svn: 67104
2009-03-18 05:15:40 +08:00
Instantiating a class template should not instantiate the definition of any scoped enumeration members. Later uses of an enumeration temploid as a nested name specifier should cause its instantiation. Plus some groundwork for explicit specialization of member enumerations of class templates. llvm-svn: 152750
2012-03-15 07:13:10 +08:00
// C++11 [temp.inst]p1: The implicit instantiation of a class template
// specialization causes the implicit instantiation of the declarations, but
// not the definitions of scoped member enumerations.
Sema: Instantiate local class and their members appropriately We would fail to instantiate them when the surrounding function was instantiated. Instantiate the class and add it's members to the list of pending instantiations, they should be resolved when we are finished with the function's body. This fixes PR9685. llvm-svn: 195827
2013-11-27 16:20:38 +08:00
//
// DR1484 clarifies that enumeration definitions inside of a template
// declaration aren't considered entities that can be separately instantiated
// from the rest of the entity they are declared inside of.
if (isDeclWithinFunction(D) ? D == Def : Def && !Enum->isScoped()) {
SemaRef.CurrentInstantiationScope->InstantiatedLocal(D, Enum);
Delay checking of dependent underlying types for redeclarations of member enumerations in templates until the template is instantiated. llvm-svn: 153426
2012-03-26 12:08:46 +08:00
InstantiateEnumDefinition(Enum, Def);
Sema: Instantiate local class and their members appropriately We would fail to instantiate them when the surrounding function was instantiated. Instantiate the class and add it's members to the list of pending instantiations, they should be resolved when we are finished with the function's body. This fixes PR9685. llvm-svn: 195827
2013-11-27 16:20:38 +08:00
}
Instantiating a class template should not instantiate the definition of any scoped enumeration members. Later uses of an enumeration temploid as a nested name specifier should cause its instantiation. Plus some groundwork for explicit specialization of member enumerations of class templates. llvm-svn: 152750
2012-03-15 07:13:10 +08:00
return Enum;
}
void TemplateDeclInstantiator::InstantiateEnumDefinition(
EnumDecl *Enum, EnumDecl *Pattern) {
Enum->startDefinition();
Support for definitions of member enumerations of class templates outside the class template's definition, and for explicit specializations of such enum members. llvm-svn: 153304
2012-03-23 11:33:32 +08:00
// Update the location to refer to the definition.
Enum->setLocation(Pattern->getLocation());
remove unneeded llvm:: namespace qualifiers on some core types now that LLVM.h imports them into the clang namespace. llvm-svn: 135852
2011-07-23 18:55:15 +08:00
SmallVector<Decl*, 4> Enumerators;
Refactor instantiation of declarations within a template into a much cleaner visitor framework. Added a visitor for declarations, which is quite similar to the visitor for statatements. llvm-svn: 67104
2009-03-18 05:15:40 +08:00
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
EnumConstantDecl *LastEnumConst = nullptr;
[C++11] Replacing EnumDecl iterators enumerator_begin() and enumerator_end() with iterator_range enumerators(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203353
2014-03-09 02:45:14 +08:00
for (auto *EC : Pattern->enumerators()) {
Refactor instantiation of declarations within a template into a much cleaner visitor framework. Added a visitor for declarations, which is quite similar to the visitor for statatements. llvm-svn: 67104
2009-03-18 05:15:40 +08:00
// The specified value for the enumerator.
Refactoring. Remove Owned method from Sema. llvm-svn: 209812
2014-05-29 22:05:12 +08:00
ExprResult Value((Expr *)nullptr);
Rework the way we track which declarations are "used" during compilation, and (hopefully) introduce RAII objects for changing the "potentially evaluated" state at all of the necessary places within Sema and Parser. Other changes: - Set the unevaluated/potentially-evaluated context appropriately during template instantiation. - We now recognize three different states while parsing or instantiating expressions: unevaluated, potentially evaluated, and potentially potentially evaluated (for C++'s typeid). - When we're in a potentially potentially-evaluated context, queue up MarkDeclarationReferenced calls in a stack. For C++ typeid expressions that are potentially evaluated, we will play back these MarkDeclarationReferenced calls when we exit the corresponding potentially potentially-evaluated context. - Non-type template arguments are now parsed as constant expressions, so they are not potentially-evaluated. llvm-svn: 73899
2009-06-23 04:57:11 +08:00
if (Expr *UninstValue = EC->getInitExpr()) {
Unlike in C++03, a constant-expression is not an unevaluated operand in C++11. Split out a new ExpressionEvaluationContext flag for this case, and don't treat it as unevaluated in C++11. This fixes some crash-on-invalids where we would allow references to class members in potentially-evaluated constant expressions in static member functions, and also fixes half of PR10177. The fix to PR10177 exposed a case where template instantiation failed to provide a source location for a diagnostic, so TreeTransform has been tweaked to supply source locations when transforming a type. The source location is still not very good, but MarkDeclarationsReferencedInType would need to operate on a TypeLoc to improve it further. Also fix MarkDeclarationReferenced in C++98 mode to trigger instantiation for static data members of class templates which are used in constant expressions. This fixes a link-time problem, but we still incorrectly treat the member as non-constant. The rest of the fix for that issue is blocked on PCH support for early-instantiated static data members, which will be added in a subsequent patch. llvm-svn: 146955
2011-12-20 10:08:33 +08:00
// The enumerator's value expression is a constant expression.
[NFC, Scoped Enum] Convert Sema::ExpressionEvaluationContext into a scoped Enum - also replace direct equality checks against the ConstantEvaluated enumerator with isConstantEvaluted(), in anticipation of adding finer granularity to the various ConstantEvaluated contexts and reinstating certain restrictions on where lambda expressions can occur in C++17. - update the clang tablegen backend that uses these Enumerators, and add the relevant scope where needed. llvm-svn: 299316
2017-04-02 05:30:49 +08:00
EnterExpressionEvaluationContext Unevaluated(
SemaRef, Sema::ExpressionEvaluationContext::ConstantEvaluated);
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Clarify the difference between substitution and instantiation by renaming functions that don't instantiate definitions. llvm-svn: 80037
2009-08-26 06:02:44 +08:00
Value = SemaRef.SubstExpr(UninstValue, TemplateArgs);
Rework the way we track which declarations are "used" during compilation, and (hopefully) introduce RAII objects for changing the "potentially evaluated" state at all of the necessary places within Sema and Parser. Other changes: - Set the unevaluated/potentially-evaluated context appropriately during template instantiation. - We now recognize three different states while parsing or instantiating expressions: unevaluated, potentially evaluated, and potentially potentially evaluated (for C++'s typeid). - When we're in a potentially potentially-evaluated context, queue up MarkDeclarationReferenced calls in a stack. For C++ typeid expressions that are potentially evaluated, we will play back these MarkDeclarationReferenced calls when we exit the corresponding potentially potentially-evaluated context. - Non-type template arguments are now parsed as constant expressions, so they are not potentially-evaluated. llvm-svn: 73899
2009-06-23 04:57:11 +08:00
}
Refactor instantiation of declarations within a template into a much cleaner visitor framework. Added a visitor for declarations, which is quite similar to the visitor for statatements. llvm-svn: 67104
2009-03-18 05:15:40 +08:00
// Drop the initial value and continue.
bool isInvalid = false;
if (Value.isInvalid()) {
Refactoring. Remove Owned method from Sema. llvm-svn: 209812
2014-05-29 22:05:12 +08:00
Value = nullptr;
Refactor instantiation of declarations within a template into a much cleaner visitor framework. Added a visitor for declarations, which is quite similar to the visitor for statatements. llvm-svn: 67104
2009-03-18 05:15:40 +08:00
isInvalid = true;
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
EnumConstantDecl *EnumConst
Refactor instantiation of declarations within a template into a much cleaner visitor framework. Added a visitor for declarations, which is quite similar to the visitor for statatements. llvm-svn: 67104
2009-03-18 05:15:40 +08:00
= SemaRef.CheckEnumConstant(Enum, LastEnumConst,
EC->getLocation(), EC->getIdentifier(),
Kill off ExprArg (now just Expr*) and StmtArg (now just Stmt*). llvm-svn: 111863
2010-08-24 07:25:46 +08:00
Value.get());
Refactor instantiation of declarations within a template into a much cleaner visitor framework. Added a visitor for declarations, which is quite similar to the visitor for statatements. llvm-svn: 67104
2009-03-18 05:15:40 +08:00
if (isInvalid) {
if (EnumConst)
EnumConst->setInvalidDecl();
Enum->setInvalidDecl();
}
if (EnumConst) {
[C++11] Replacing EnumDecl iterators enumerator_begin() and enumerator_end() with iterator_range enumerators(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203353
2014-03-09 02:45:14 +08:00
SemaRef.InstantiateAttrs(TemplateArgs, EC, EnumConst);
Parse attributes on enumerators and instantiate attributes on enum decls. llvm-svn: 117182
2010-10-23 07:36:17 +08:00
Preserve access for enum constants during template instantiation. llvm-svn: 94333
2010-01-24 06:37:59 +08:00
EnumConst->setAccess(Enum->getAccess());
De-ASTContext-ify DeclContext. Remove ASTContext parameter from DeclContext's methods. This change cascaded down to other Decl's methods and changes to call sites started "escalating". Timings using pre-tokenized "cocoa.h" showed only a ~1% increase in time run between and after this commit. llvm-svn: 74506
2009-06-30 10:36:12 +08:00
Enum->addDecl(EnumConst);
DeclPtrTy -> Decl * llvm-svn: 111733
2010-08-21 17:40:31 +08:00
Enumerators.push_back(EnumConst);
Refactor instantiation of declarations within a template into a much cleaner visitor framework. Added a visitor for declarations, which is quite similar to the visitor for statatements. llvm-svn: 67104
2009-03-18 05:15:40 +08:00
LastEnumConst = EnumConst;
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Instantiating a class template should not instantiate the definition of any scoped enumeration members. Later uses of an enumeration temploid as a nested name specifier should cause its instantiation. Plus some groundwork for explicit specialization of member enumerations of class templates. llvm-svn: 152750
2012-03-15 07:13:10 +08:00
if (Pattern->getDeclContext()->isFunctionOrMethod() &&
!Enum->isScoped()) {
When instantiating a function-scoped enum, make sure that it and its enumeration constants get placed into the local instantiation hash table. Fixes PR6375. llvm-svn: 97471
2010-03-02 03:00:07 +08:00
// If the enumeration is within a function or method, record the enum
// constant as a local.
[C++11] Replacing EnumDecl iterators enumerator_begin() and enumerator_end() with iterator_range enumerators(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203353
2014-03-09 02:45:14 +08:00
SemaRef.CurrentInstantiationScope->InstantiatedLocal(EC, EnumConst);
When instantiating a function-scoped enum, make sure that it and its enumeration constants get placed into the local instantiation hash table. Fixes PR6375. llvm-svn: 97471
2010-03-02 03:00:07 +08:00
}
Refactor instantiation of declarations within a template into a much cleaner visitor framework. Added a visitor for declarations, which is quite similar to the visitor for statatements. llvm-svn: 67104
2009-03-18 05:15:40 +08:00
}
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
[AST] Keep track of the left brace source location of a tag decl. This is useful for source modification tools. There will be a follow-up commit using it. llvm-svn: 275590
2016-07-16 02:11:33 +08:00
SemaRef.ActOnEnumBody(Enum->getLocation(), Enum->getBraceRange(), Enum,
ArrayRef'ize Sema::ActOnEnumBody. No functionality change. Patch by Robert Wilhelm. llvm-svn: 180682
2013-04-28 04:23:52 +08:00
Enumerators,
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
nullptr, nullptr);
Refactor instantiation of declarations within a template into a much cleaner visitor framework. Added a visitor for declarations, which is quite similar to the visitor for statatements. llvm-svn: 67104
2009-03-18 05:15:40 +08:00
}
Minor refactoring to eliminate an extra switch during template instantiation llvm-svn: 67684
2009-03-25 23:04:13 +08:00
Decl *TemplateDeclInstantiator::VisitEnumConstantDecl(EnumConstantDecl *D) {
Switch assert(0/false) llvm_unreachable. llvm-svn: 140367
2011-09-23 13:06:16 +08:00
llvm_unreachable("EnumConstantDecls can only occur within EnumDecls.");
Minor refactoring to eliminate an extra switch during template instantiation llvm-svn: 67684
2009-03-25 23:04:13 +08:00
}
[Sema] Implement __make_integer_seq This new builtin template allows for incredibly fast instantiations of templates like std::integer_sequence. Performance numbers follow: My work station has 64 GB of ram + 20 Xeon Cores at 2.8 GHz. __make_integer_seq<std::integer_sequence, int, 90000> takes 0.25 seconds. std::make_integer_sequence<int, 90000> takes unbound time, it is still running. Clang is consuming gigabytes of memory. Differential Revision: http://reviews.llvm.org/D13786 llvm-svn: 252036
2015-11-04 11:40:30 +08:00
Decl *
TemplateDeclInstantiator::VisitBuiltinTemplateDecl(BuiltinTemplateDecl *D) {
llvm_unreachable("BuiltinTemplateDecls cannot be instantiated.");
}
Basic nested-template implementation. llvm-svn: 79504
2009-08-20 09:44:21 +08:00
Decl *TemplateDeclInstantiator::VisitClassTemplateDecl(ClassTemplateDecl *D) {
Properly instantiate friend class template declarations and link them into the redeclaration chain. Recommitted from r99477 with a fix: we need to merge in default template arguments from previous declarations. llvm-svn: 99496
2010-03-25 14:39:04 +08:00
bool isFriend = (D->getFriendObjectKind() != Decl::FOK_None);
Implement "incremental" template instantiation for non-type template parameters and template type parameters, which occurs when substituting into the declarations of member templates inside class templates. This eliminates errors about our inability to "reduce non-type template parameter depth", fixing PR5311. Also fixes a bug when instantiating a template type parameter declaration in a member template, where we weren't properly reducing the template parameter's depth. LLVM's StringSwitch header now parses. llvm-svn: 85669
2009-11-01 01:21:17 +08:00
// Create a local instantiation scope for this class template, which
// will contain the instantiations of the template parameters.
Move more stuff out of Sema.h. llvm-svn: 112026
2010-08-25 13:32:35 +08:00
LocalInstantiationScope Scope(SemaRef);
Basic nested-template implementation. llvm-svn: 79504
2009-08-20 09:44:21 +08:00
TemplateParameterList *TempParams = D->getTemplateParameters();
Clarify the difference between substitution and instantiation by renaming functions that don't instantiate definitions. llvm-svn: 80037
2009-08-26 06:02:44 +08:00
TemplateParameterList *InstParams = SubstTemplateParams(TempParams);
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
if (!InstParams)
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Basic nested-template implementation. llvm-svn: 79504
2009-08-20 09:44:21 +08:00
CXXRecordDecl *Pattern = D->getTemplatedDecl();
Properly instantiate friend class template declarations and link them into the redeclaration chain. Recommitted from r99477 with a fix: we need to merge in default template arguments from previous declarations. llvm-svn: 99496
2010-03-25 14:39:04 +08:00
// Instantiate the qualifier. We have to do this first in case
// we're a friend declaration, because if we are then we need to put
// the new declaration in the appropriate context.
Use NestedNameSpecifierLoc within out-of-line variables, function, and tag definitions. Also, add support for template instantiation of NestedNameSpecifierLocs. llvm-svn: 126470
2011-02-25 10:25:35 +08:00
NestedNameSpecifierLoc QualifierLoc = Pattern->getQualifierLoc();
if (QualifierLoc) {
QualifierLoc = SemaRef.SubstNestedNameSpecifierLoc(QualifierLoc,
TemplateArgs);
if (!QualifierLoc)
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Properly instantiate friend class template declarations and link them into the redeclaration chain. Recommitted from r99477 with a fix: we need to merge in default template arguments from previous declarations. llvm-svn: 99496
2010-03-25 14:39:04 +08:00
}
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
CXXRecordDecl *PrevDecl = nullptr;
ClassTemplateDecl *PrevClassTemplate = nullptr;
Properly instantiate friend class template declarations and link them into the redeclaration chain. Recommitted from r99477 with a fix: we need to merge in default template arguments from previous declarations. llvm-svn: 99496
2010-03-25 14:39:04 +08:00
[modules] When instantiating a class member, don't expect to find the previous declaration in the instantiation if the previous declaration came from another definition of the class template that got merged into the pattern definition. llvm-svn: 219552
2014-10-11 08:37:16 +08:00
if (!isFriend && getPreviousDeclForInstantiation(Pattern)) {
Don't lose track of previous-declarations when instantiating a class template. Fixes PR8001. llvm-svn: 118454
2010-11-09 07:29:42 +08:00
DeclContext::lookup_result Found = Owner->lookup(Pattern->getDeclName());
Change DeclContextLookup(Const)Result to (Mutable)ArrayRef<NamedDecl*>, as per review discussion in r170365 This does limit these typedefs to being sequences, but no current usage requires them to be contiguous (we could expand this to a more general iterator pair range concept at some point). Also, it'd be nice if SmallVector were constructible directly from an ArrayRef but this is a bit tricky since ArrayRef depends on SmallVectorBaseImpl for the inverse conversion. (& generalizing over all range-like things, while nice, would require some nontrivial SFINAE I haven't thought about yet) llvm-svn: 170482
2012-12-19 08:45:41 +08:00
if (!Found.empty()) {
PrevClassTemplate = dyn_cast<ClassTemplateDecl>(Found.front());
Don't lose track of previous-declarations when instantiating a class template. Fixes PR8001. llvm-svn: 118454
2010-11-09 07:29:42 +08:00
if (PrevClassTemplate)
PrevDecl = PrevClassTemplate->getTemplatedDecl();
}
}
Properly instantiate friend class template declarations and link them into the redeclaration chain. Recommitted from r99477 with a fix: we need to merge in default template arguments from previous declarations. llvm-svn: 99496
2010-03-25 14:39:04 +08:00
// If this isn't a friend, then it's a member template, in which
// case we just want to build the instantiation in the
// specialization. If it is a friend, we want to build it in
// the appropriate context.
DeclContext *DC = Owner;
if (isFriend) {
Use NestedNameSpecifierLoc within out-of-line variables, function, and tag definitions. Also, add support for template instantiation of NestedNameSpecifierLocs. llvm-svn: 126470
2011-02-25 10:25:35 +08:00
if (QualifierLoc) {
Properly instantiate friend class template declarations and link them into the redeclaration chain. Recommitted from r99477 with a fix: we need to merge in default template arguments from previous declarations. llvm-svn: 99496
2010-03-25 14:39:04 +08:00
CXXScopeSpec SS;
Use NestedNameSpecifierLoc within out-of-line variables, function, and tag definitions. Also, add support for template instantiation of NestedNameSpecifierLocs. llvm-svn: 126470
2011-02-25 10:25:35 +08:00
SS.Adopt(QualifierLoc);
Properly instantiate friend class template declarations and link them into the redeclaration chain. Recommitted from r99477 with a fix: we need to merge in default template arguments from previous declarations. llvm-svn: 99496
2010-03-25 14:39:04 +08:00
DC = SemaRef.computeDeclContext(SS);
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
if (!DC) return nullptr;
Properly instantiate friend class template declarations and link them into the redeclaration chain. Recommitted from r99477 with a fix: we need to merge in default template arguments from previous declarations. llvm-svn: 99496
2010-03-25 14:39:04 +08:00
} else {
DC = SemaRef.FindInstantiatedContext(Pattern->getLocation(),
Pattern->getDeclContext(),
TemplateArgs);
}
// Look for a previous declaration of the template in the owning
// context.
LookupResult R(SemaRef, Pattern->getDeclName(), Pattern->getLocation(),
Sema::LookupOrdinaryName, Sema::ForRedeclaration);
SemaRef.LookupQualifiedName(R, DC);
if (R.isSingleResult()) {
PrevClassTemplate = R.getAsSingle<ClassTemplateDecl>();
if (PrevClassTemplate)
PrevDecl = PrevClassTemplate->getTemplatedDecl();
}
Use NestedNameSpecifierLoc within out-of-line variables, function, and tag definitions. Also, add support for template instantiation of NestedNameSpecifierLocs. llvm-svn: 126470
2011-02-25 10:25:35 +08:00
if (!PrevClassTemplate && QualifierLoc) {
Properly instantiate friend class template declarations and link them into the redeclaration chain. Recommitted from r99477 with a fix: we need to merge in default template arguments from previous declarations. llvm-svn: 99496
2010-03-25 14:39:04 +08:00
SemaRef.Diag(Pattern->getLocation(), diag::err_not_tag_in_scope)
Improve diagnostics when an elaborated-type-specifer containing a nested-name-specifier (e.g., "class T::foo") fails to find a tag member in the scope nominated by the nested-name-specifier. Previously, we gave a bland error: 'Nested' does not name a tag member in the specified scope which didn't actually say where we were looking, which was rather horrible when the nested-name-specifier was instantiated. Now, we give something a bit better: error: no class named 'Nested' in 'NoDepBase<T>' llvm-svn: 100060
2010-04-01 07:17:41 +08:00
<< D->getTemplatedDecl()->getTagKind() << Pattern->getDeclName() << DC
Use NestedNameSpecifierLoc within out-of-line variables, function, and tag definitions. Also, add support for template instantiation of NestedNameSpecifierLocs. llvm-svn: 126470
2011-02-25 10:25:35 +08:00
<< QualifierLoc.getSourceRange();
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Properly instantiate friend class template declarations and link them into the redeclaration chain. Recommitted from r99477 with a fix: we need to merge in default template arguments from previous declarations. llvm-svn: 99496
2010-03-25 14:39:04 +08:00
}
Introduce an egregious hack to work around a bug in libstdc++ 4.2.x's <tr1/hashtable> header, where a friend class template std::tr1::__detail::_Map_base is declared with the wrong template parameters. GCC doesn't catch the problem, so Clang does a little back-flip to avoid diagnosing just this one instance of the problem. llvm-svn: 100790
2010-04-09 02:16:15 +08:00
bool AdoptedPreviousTemplateParams = false;
Properly instantiate friend class template declarations and link them into the redeclaration chain. Recommitted from r99477 with a fix: we need to merge in default template arguments from previous declarations. llvm-svn: 99496
2010-03-25 14:39:04 +08:00
if (PrevClassTemplate) {
Introduce an egregious hack to work around a bug in libstdc++ 4.2.x's <tr1/hashtable> header, where a friend class template std::tr1::__detail::_Map_base is declared with the wrong template parameters. GCC doesn't catch the problem, so Clang does a little back-flip to avoid diagnosing just this one instance of the problem. llvm-svn: 100790
2010-04-09 02:16:15 +08:00
bool Complain = true;
// HACK: libstdc++ 4.2.1 contains an ill-formed friend class
// template for struct std::tr1::__detail::_Map_base, where the
// template parameters of the friend declaration don't match the
// template parameters of the original declaration. In this one
// case, we don't complain about the ill-formed friend
// declaration.
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
if (isFriend && Pattern->getIdentifier() &&
Introduce an egregious hack to work around a bug in libstdc++ 4.2.x's <tr1/hashtable> header, where a friend class template std::tr1::__detail::_Map_base is declared with the wrong template parameters. GCC doesn't catch the problem, so Clang does a little back-flip to avoid diagnosing just this one instance of the problem. llvm-svn: 100790
2010-04-09 02:16:15 +08:00
Pattern->getIdentifier()->isStr("_Map_base") &&
DC->isNamespace() &&
cast<NamespaceDecl>(DC)->getIdentifier() &&
cast<NamespaceDecl>(DC)->getIdentifier()->isStr("__detail")) {
DeclContext *DCParent = DC->getParent();
if (DCParent->isNamespace() &&
cast<NamespaceDecl>(DCParent)->getIdentifier() &&
cast<NamespaceDecl>(DCParent)->getIdentifier()->isStr("tr1")) {
Move the logic for testing for namespace std into one location. This check can be performed by using Decl::isInStdNamespace or DeclContext::isStdNamespace llvm-svn: 209708
2014-05-28 10:16:01 +08:00
if (cast<Decl>(DCParent)->isInStdNamespace())
Introduce an egregious hack to work around a bug in libstdc++ 4.2.x's <tr1/hashtable> header, where a friend class template std::tr1::__detail::_Map_base is declared with the wrong template parameters. GCC doesn't catch the problem, so Clang does a little back-flip to avoid diagnosing just this one instance of the problem. llvm-svn: 100790
2010-04-09 02:16:15 +08:00
Complain = false;
}
}
Properly instantiate friend class template declarations and link them into the redeclaration chain. Recommitted from r99477 with a fix: we need to merge in default template arguments from previous declarations. llvm-svn: 99496
2010-03-25 14:39:04 +08:00
TemplateParameterList *PrevParams
= PrevClassTemplate->getTemplateParameters();
// Make sure the parameter lists match.
if (!SemaRef.TemplateParameterListsAreEqual(InstParams, PrevParams,
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Complain,
Introduce an egregious hack to work around a bug in libstdc++ 4.2.x's <tr1/hashtable> header, where a friend class template std::tr1::__detail::_Map_base is declared with the wrong template parameters. GCC doesn't catch the problem, so Clang does a little back-flip to avoid diagnosing just this one instance of the problem. llvm-svn: 100790
2010-04-09 02:16:15 +08:00
Sema::TPL_TemplateMatch)) {
if (Complain)
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Introduce an egregious hack to work around a bug in libstdc++ 4.2.x's <tr1/hashtable> header, where a friend class template std::tr1::__detail::_Map_base is declared with the wrong template parameters. GCC doesn't catch the problem, so Clang does a little back-flip to avoid diagnosing just this one instance of the problem. llvm-svn: 100790
2010-04-09 02:16:15 +08:00
AdoptedPreviousTemplateParams = true;
InstParams = PrevParams;
}
Properly instantiate friend class template declarations and link them into the redeclaration chain. Recommitted from r99477 with a fix: we need to merge in default template arguments from previous declarations. llvm-svn: 99496
2010-03-25 14:39:04 +08:00
// Do some additional validation, then merge default arguments
// from the existing declarations.
Introduce an egregious hack to work around a bug in libstdc++ 4.2.x's <tr1/hashtable> header, where a friend class template std::tr1::__detail::_Map_base is declared with the wrong template parameters. GCC doesn't catch the problem, so Clang does a little back-flip to avoid diagnosing just this one instance of the problem. llvm-svn: 100790
2010-04-09 02:16:15 +08:00
if (!AdoptedPreviousTemplateParams &&
SemaRef.CheckTemplateParameterList(InstParams, PrevParams,
Properly instantiate friend class template declarations and link them into the redeclaration chain. Recommitted from r99477 with a fix: we need to merge in default template arguments from previous declarations. llvm-svn: 99496
2010-03-25 14:39:04 +08:00
Sema::TPC_ClassTemplate))
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Properly instantiate friend class template declarations and link them into the redeclaration chain. Recommitted from r99477 with a fix: we need to merge in default template arguments from previous declarations. llvm-svn: 99496
2010-03-25 14:39:04 +08:00
}
}
Basic nested-template implementation. llvm-svn: 79504
2009-08-20 09:44:21 +08:00
CXXRecordDecl *RecordInst
Properly instantiate friend class template declarations and link them into the redeclaration chain. Recommitted from r99477 with a fix: we need to merge in default template arguments from previous declarations. llvm-svn: 99496
2010-03-25 14:39:04 +08:00
= CXXRecordDecl::Create(SemaRef.Context, Pattern->getTagKind(), DC,
Fixed InnerLocStart. llvm-svn: 127330
2011-03-09 22:09:51 +08:00
Pattern->getLocStart(), Pattern->getLocation(),
Pattern->getIdentifier(), PrevDecl,
When declaring a class template whose name is qualified, make sure that the scope in which it is being declared is complete. Also, when instantiating a member class template's ClassTemplateDecl, be sure to delay type creation so that the resulting type is dependent. Ick. llvm-svn: 83923
2009-10-13 07:11:44 +08:00
/*DelayTypeCreation=*/true);
Basic nested-template implementation. llvm-svn: 79504
2009-08-20 09:44:21 +08:00
Use NestedNameSpecifierLoc within out-of-line variables, function, and tag definitions. Also, add support for template instantiation of NestedNameSpecifierLocs. llvm-svn: 126470
2011-02-25 10:25:35 +08:00
if (QualifierLoc)
RecordInst->setQualifierInfo(QualifierLoc);
Remember declaration scope qualifiers in the AST. Imposes no memory overhead on unqualified declarations. Patch by Enea Zaffanella! Minimal adjustments: allocate the ExtInfo nodes with the ASTContext and delete them during Destroy(). I audited a bunch of Destroy methods at the same time, to ensure that the correct teardown was being done. llvm-svn: 98540
2010-03-15 18:12:16 +08:00
Basic nested-template implementation. llvm-svn: 79504
2009-08-20 09:44:21 +08:00
ClassTemplateDecl *Inst
Properly instantiate friend class template declarations and link them into the redeclaration chain. Recommitted from r99477 with a fix: we need to merge in default template arguments from previous declarations. llvm-svn: 99496
2010-03-25 14:39:04 +08:00
= ClassTemplateDecl::Create(SemaRef.Context, DC, D->getLocation(),
PR31469: Don't add friend template class decls to redecl chain in dependent contexts. Fixes a crash in modules where the template class decl becomes the most recent decl in the redeclaration chain and forcing the template instantiator try to instantiate the friend declaration, rather than the template definition. In practice, A::list<int> produces a TemplateSpecializationType A::__1::list<int, allocator<type-parameter-0-0> >' failing to replace to subsitute the default argument to allocator<int>. Kudos Richard Smith (D28399). llvm-svn: 291753
2017-01-12 17:16:26 +08:00
D->getIdentifier(), InstParams, RecordInst);
assert(!(isFriend && Owner->isDependentContext()));
Inst->setPreviousDecl(PrevClassTemplate);
Basic nested-template implementation. llvm-svn: 79504
2009-08-20 09:44:21 +08:00
RecordInst->setDescribedClassTemplate(Inst);
Set access properly on instantiated friend class template declarations. Fixes PR6752. llvm-svn: 100806
2010-04-09 04:25:50 +08:00
Properly instantiate friend class template declarations and link them into the redeclaration chain. Recommitted from r99477 with a fix: we need to merge in default template arguments from previous declarations. llvm-svn: 99496
2010-03-25 14:39:04 +08:00
if (isFriend) {
Set access properly on instantiated friend class template declarations. Fixes PR6752. llvm-svn: 100806
2010-04-09 04:25:50 +08:00
if (PrevClassTemplate)
Inst->setAccess(PrevClassTemplate->getAccess());
else
Inst->setAccess(D->getAccess());
Reinstate r186040, with additional fixes and more test coverage (reverted in r186331). Original commit log: If we friend a declaration twice, that should not make it visible to name lookup in the surrounding context. Slightly rework how we handle friend declarations to inherit the visibility of the prior declaration, rather than setting a friend declaration to be visible whenever there was a prior declaration. llvm-svn: 186546
2013-07-18 07:53:16 +08:00
Inst->setObjectOfFriendDecl();
Properly instantiate friend class template declarations and link them into the redeclaration chain. Recommitted from r99477 with a fix: we need to merge in default template arguments from previous declarations. llvm-svn: 99496
2010-03-25 14:39:04 +08:00
// TODO: do we want to track the instantiation progeny of this
// friend target decl?
} else {
Instantiate class template friends better; fixes PR5332. llvm-svn: 85612
2009-10-31 05:07:27 +08:00
Inst->setAccess(D->getAccess());
Don't lose track of previous-declarations when instantiating a class template. Fixes PR8001. llvm-svn: 118454
2010-11-09 07:29:42 +08:00
if (!PrevClassTemplate)
Inst->setInstantiatedFromMemberTemplate(D);
Properly instantiate friend class template declarations and link them into the redeclaration chain. Recommitted from r99477 with a fix: we need to merge in default template arguments from previous declarations. llvm-svn: 99496
2010-03-25 14:39:04 +08:00
}
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
When declaring a class template whose name is qualified, make sure that the scope in which it is being declared is complete. Also, when instantiating a member class template's ClassTemplateDecl, be sure to delay type creation so that the resulting type is dependent. Ick. llvm-svn: 83923
2009-10-13 07:11:44 +08:00
// Trigger creation of the type for the instantiation.
Create a new InjectedClassNameType to represent bare-word references to the injected class name of a class template or class template partial specialization. This is a non-canonical type; the canonical type is still a template specialization type. This becomes the TypeForDecl of the pattern declaration, which cleans up some amount of code (and complicates some other parts, but whatever). Fixes PR6326 and probably a few others, primarily by re-establishing a few invariants about TypeLoc sizes. llvm-svn: 98134
2010-03-10 11:28:59 +08:00
SemaRef.Context.getInjectedClassNameType(RecordInst,
When performing substitution of template arguments within the body of a template, be sure to include the template arguments from the injected-class-name. Fixes PR7587. llvm-svn: 107895
2010-07-09 02:37:38 +08:00
Inst->getInjectedClassNameSpecialization());
Set access properly on instantiated friend class template declarations. Fixes PR6752. llvm-svn: 100806
2010-04-09 04:25:50 +08:00
When a friend is declared in a dependent context, don't even try to match it up with a declaration in the outer scope. llvm-svn: 85628
2009-10-31 06:42:42 +08:00
// Finish handling of friends.
Properly instantiate friend class template declarations and link them into the redeclaration chain. Recommitted from r99477 with a fix: we need to merge in default template arguments from previous declarations. llvm-svn: 99496
2010-03-25 14:39:04 +08:00
if (isFriend) {
Fix PR10447: lazily building name lookup tables for DeclContexts was broken. The deferred lookup table building step couldn't accurately tell which Decls should be included in the lookup table, and consequently built different tables in some cases. Fix this by removing lazy building of DeclContext name lookup tables. In practice, the laziness was frequently not worthwhile in C++, because we performed lookup into most DeclContexts. In C, it had a bit more value, since there is no qualified lookup. In the place of lazy lookup table building, we simply don't build lookup tables for function DeclContexts at all. Such name lookup tables are not useful, since they don't capture the scoping information required to correctly perform name lookup in a function scope. The resulting performance delta is within the noise on my testing, but appears to be a very slight win for C++ and a very slight loss for C. The C performance can probably be recovered (if it is a measurable problem) by avoiding building the lookup table for the translation unit. llvm-svn: 152608
2012-03-13 11:12:56 +08:00
DC->makeDeclVisibleInContext(Inst);
Fixed lexical declaration context when instantiating a friend / out-of-line class template member. llvm-svn: 145146
2011-11-26 21:33:46 +08:00
Inst->setLexicalDeclContext(Owner);
RecordInst->setLexicalDeclContext(Owner);
Instantiate class template friends better; fixes PR5332. llvm-svn: 85612
2009-10-31 05:07:27 +08:00
return Inst;
When a friend is declared in a dependent context, don't even try to match it up with a declaration in the outer scope. llvm-svn: 85628
2009-10-31 06:42:42 +08:00
}
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Fixed lexical declaration context when instantiating a friend / out-of-line class template member. llvm-svn: 145146
2011-11-26 21:33:46 +08:00
if (D->isOutOfLine()) {
Inst->setLexicalDeclContext(D->getLexicalDeclContext());
RecordInst->setLexicalDeclContext(D->getLexicalDeclContext());
}
Basic nested-template implementation. llvm-svn: 79504
2009-08-20 09:44:21 +08:00
Owner->addDecl(Inst);
Instantiate class member template partial specialization declarations in the order they occur within the class template, delaying out-of-line member template partial specializations until after the class has been fully instantiated. This fixes a regression introduced by r118454 (itself a fix for PR8001). llvm-svn: 118704
2010-11-11 03:44:59 +08:00
if (!PrevClassTemplate) {
// Queue up any out-of-line partial specializations of this member
// class template; the client will force their instantiation once
// the enclosing class has been instantiated.
remove unneeded llvm:: namespace qualifiers on some core types now that LLVM.h imports them into the clang namespace. llvm-svn: 135852
2011-07-23 18:55:15 +08:00
SmallVector<ClassTemplatePartialSpecializationDecl *, 4> PartialSpecs;
Instantiate class member template partial specialization declarations in the order they occur within the class template, delaying out-of-line member template partial specializations until after the class has been fully instantiated. This fixes a regression introduced by r118454 (itself a fix for PR8001). llvm-svn: 118704
2010-11-11 03:44:59 +08:00
D->getPartialSpecializations(PartialSpecs);
for (unsigned I = 0, N = PartialSpecs.size(); I != N; ++I)
Rename some functions for consistency. Every other function in Redeclarable.h was using Decl instead of Declaration. llvm-svn: 192900
2013-10-17 23:37:26 +08:00
if (PartialSpecs[I]->getFirstDecl()->isOutOfLine())
Instantiate class member template partial specialization declarations in the order they occur within the class template, delaying out-of-line member template partial specializations until after the class has been fully instantiated. This fixes a regression introduced by r118454 (itself a fix for PR8001). llvm-svn: 118704
2010-11-11 03:44:59 +08:00
OutOfLinePartialSpecs.push_back(std::make_pair(Inst, PartialSpecs[I]));
}
Basic nested-template implementation. llvm-svn: 79504
2009-08-20 09:44:21 +08:00
return Inst;
}
Class template partial specializations can be declared anywhere that its definition may be defined, including in a class. Also, put in an assertion when trying to instantiate a class template partial specialization of a member template, which is not yet implemented. llvm-svn: 83469
2009-10-08 01:21:34 +08:00
Decl *
TemplateDeclInstantiator::VisitClassTemplatePartialSpecializationDecl(
ClassTemplatePartialSpecializationDecl *D) {
Implement support for semantic checking and template instantiation of class template partial specializations of member templates. Also, fixes a silly little bug in the marking of "used" template parameters in member templates. Fixes PR5236. llvm-svn: 85447
2009-10-29 08:04:11 +08:00
ClassTemplateDecl *ClassTemplate = D->getSpecializedTemplate();
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Implement support for semantic checking and template instantiation of class template partial specializations of member templates. Also, fixes a silly little bug in the marking of "used" template parameters in member templates. Fixes PR5236. llvm-svn: 85447
2009-10-29 08:04:11 +08:00
// Lookup the already-instantiated declaration in the instantiation
// of the class template and return that.
DeclContext::lookup_result Found
= Owner->lookup(ClassTemplate->getDeclName());
Change DeclContextLookup(Const)Result to (Mutable)ArrayRef<NamedDecl*>, as per review discussion in r170365 This does limit these typedefs to being sequences, but no current usage requires them to be contiguous (we could expand this to a more general iterator pair range concept at some point). Also, it'd be nice if SmallVector were constructible directly from an ArrayRef but this is a bit tricky since ArrayRef depends on SmallVectorBaseImpl for the inverse conversion. (& generalizing over all range-like things, while nice, would require some nontrivial SFINAE I haven't thought about yet) llvm-svn: 170482
2012-12-19 08:45:41 +08:00
if (Found.empty())
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Implement support for semantic checking and template instantiation of class template partial specializations of member templates. Also, fixes a silly little bug in the marking of "used" template parameters in member templates. Fixes PR5236. llvm-svn: 85447
2009-10-29 08:04:11 +08:00
ClassTemplateDecl *InstClassTemplate
Change DeclContextLookup(Const)Result to (Mutable)ArrayRef<NamedDecl*>, as per review discussion in r170365 This does limit these typedefs to being sequences, but no current usage requires them to be contiguous (we could expand this to a more general iterator pair range concept at some point). Also, it'd be nice if SmallVector were constructible directly from an ArrayRef but this is a bit tricky since ArrayRef depends on SmallVectorBaseImpl for the inverse conversion. (& generalizing over all range-like things, while nice, would require some nontrivial SFINAE I haven't thought about yet) llvm-svn: 170482
2012-12-19 08:45:41 +08:00
= dyn_cast<ClassTemplateDecl>(Found.front());
Implement support for semantic checking and template instantiation of class template partial specializations of member templates. Also, fixes a silly little bug in the marking of "used" template parameters in member templates. Fixes PR5236. llvm-svn: 85447
2009-10-29 08:04:11 +08:00
if (!InstClassTemplate)
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Instantiate class member template partial specialization declarations in the order they occur within the class template, delaying out-of-line member template partial specializations until after the class has been fully instantiated. This fixes a regression introduced by r118454 (itself a fix for PR8001). llvm-svn: 118704
2010-11-11 03:44:59 +08:00
if (ClassTemplatePartialSpecializationDecl *Result
= InstClassTemplate->findPartialSpecInstantiatedFromMember(D))
return Result;
return InstantiateClassTemplatePartialSpecialization(InstClassTemplate, D);
Class template partial specializations can be declared anywhere that its definition may be defined, including in a class. Also, put in an assertion when trying to instantiate a class template partial specialization of a member template, which is not yet implemented. llvm-svn: 83469
2009-10-08 01:21:34 +08:00
}
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
Decl *TemplateDeclInstantiator::VisitVarTemplateDecl(VarTemplateDecl *D) {
assert(D->getTemplatedDecl()->isStaticDataMember() &&
"Only static data member templates are allowed.");
// Create a local instantiation scope for this variable template, which
// will contain the instantiations of the template parameters.
LocalInstantiationScope Scope(SemaRef);
TemplateParameterList *TempParams = D->getTemplateParameters();
TemplateParameterList *InstParams = SubstTemplateParams(TempParams);
if (!InstParams)
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
VarDecl *Pattern = D->getTemplatedDecl();
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
VarTemplateDecl *PrevVarTemplate = nullptr;
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
[modules] When instantiating a class member, don't expect to find the previous declaration in the instantiation if the previous declaration came from another definition of the class template that got merged into the pattern definition. llvm-svn: 219552
2014-10-11 08:37:16 +08:00
if (getPreviousDeclForInstantiation(Pattern)) {
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
DeclContext::lookup_result Found = Owner->lookup(Pattern->getDeclName());
if (!Found.empty())
PrevVarTemplate = dyn_cast<VarTemplateDecl>(Found.front());
}
Fix implementation of C11 6.2.7/4 and C++11 [dcl.array]p3: When a local extern declaration redeclares some other entity, the type of that entity is merged with the prior type if the prior declaration is visible (in C) or is declared in the same scope (in C++). - Make LookupRedeclarationWithLinkage actually work in C++, use it in the right set of cases, and make it track whether it found a shadowed declaration. - Track whether we found a declaration in the same scope (for C++) including across serialization and template instantiation. llvm-svn: 188307
2013-08-14 02:18:50 +08:00
VarDecl *VarInst =
Refactor for clarity and simplicity. llvm-svn: 188974
2013-08-22 08:59:14 +08:00
cast_or_null<VarDecl>(VisitVarDecl(Pattern,
/*InstantiatingVarTemplate=*/true));
If a variable template is inside a context with template arguments that is being instantiated, and that instantiation fails, fail our instantiation instead of crashing. Errors have already been emitted. llvm-svn: 244515
2015-08-11 05:54:08 +08:00
if (!VarInst) return nullptr;
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
DeclContext *DC = Owner;
VarTemplateDecl *Inst = VarTemplateDecl::Create(
SemaRef.Context, DC, D->getLocation(), D->getIdentifier(), InstParams,
Clean up variable template handling a bit, and correct the behavior of name lookup when declaring a variable template specialization. llvm-svn: 199438
2014-01-17 07:39:20 +08:00
VarInst);
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
VarInst->setDescribedVarTemplate(Inst);
Clean up variable template handling a bit, and correct the behavior of name lookup when declaring a variable template specialization. llvm-svn: 199438
2014-01-17 07:39:20 +08:00
Inst->setPreviousDecl(PrevVarTemplate);
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
Inst->setAccess(D->getAccess());
if (!PrevVarTemplate)
Inst->setInstantiatedFromMemberTemplate(D);
if (D->isOutOfLine()) {
Inst->setLexicalDeclContext(D->getLexicalDeclContext());
VarInst->setLexicalDeclContext(D->getLexicalDeclContext());
}
Owner->addDecl(Inst);
if (!PrevVarTemplate) {
// Queue up any out-of-line partial specializations of this member
// variable template; the client will force their instantiation once
// the enclosing class has been instantiated.
SmallVector<VarTemplatePartialSpecializationDecl *, 4> PartialSpecs;
D->getPartialSpecializations(PartialSpecs);
for (unsigned I = 0, N = PartialSpecs.size(); I != N; ++I)
Rename some functions for consistency. Every other function in Redeclarable.h was using Decl instead of Declaration. llvm-svn: 192900
2013-10-17 23:37:26 +08:00
if (PartialSpecs[I]->getFirstDecl()->isOutOfLine())
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
OutOfLineVarPartialSpecs.push_back(
std::make_pair(Inst, PartialSpecs[I]));
}
return Inst;
}
Decl *TemplateDeclInstantiator::VisitVarTemplatePartialSpecializationDecl(
VarTemplatePartialSpecializationDecl *D) {
assert(D->isStaticDataMember() &&
"Only static data member templates are allowed.");
VarTemplateDecl *VarTemplate = D->getSpecializedTemplate();
// Lookup the already-instantiated declaration and return that.
DeclContext::lookup_result Found = Owner->lookup(VarTemplate->getDeclName());
assert(!Found.empty() && "Instantiation found nothing?");
VarTemplateDecl *InstVarTemplate = dyn_cast<VarTemplateDecl>(Found.front());
assert(InstVarTemplate && "Instantiation did not find a variable template?");
if (VarTemplatePartialSpecializationDecl *Result =
InstVarTemplate->findPartialSpecInstantiatedFromMember(D))
return Result;
return InstantiateVarTemplatePartialSpecialization(InstVarTemplate, D);
}
Implement instantiation of the declarations of member function templates within class templates, producing a member function template of a class template specialization. If you can parse that, I'm sorry. Example: template<typename T> struct X { template<typename U> void f(T, U); }; When we instantiate X<int>, we now instantiate the declaration X<int>::f, which looks like this: template<typename U> void X<int>::f(int, U); The path this takes through TemplateDeclInstantiator::VisitCXXMethodDecl is convoluted and ugly, but I don't know how to improve it yet. I'm resting my hopes on the multi-level substitution required to instantiate definitions of nested templates, which may simplify this code as well. More testing to come... llvm-svn: 80252
2009-08-28 00:57:43 +08:00
Decl *
TemplateDeclInstantiator::VisitFunctionTemplateDecl(FunctionTemplateDecl *D) {
Implement "incremental" template instantiation for non-type template parameters and template type parameters, which occurs when substituting into the declarations of member templates inside class templates. This eliminates errors about our inability to "reduce non-type template parameter depth", fixing PR5311. Also fixes a bug when instantiating a template type parameter declaration in a member template, where we weren't properly reducing the template parameter's depth. LLVM's StringSwitch header now parses. llvm-svn: 85669
2009-11-01 01:21:17 +08:00
// Create a local instantiation scope for this function template, which
// will contain the instantiations of the template parameters and then get
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
// merged with the local instantiation scope for the function template
Implement "incremental" template instantiation for non-type template parameters and template type parameters, which occurs when substituting into the declarations of member templates inside class templates. This eliminates errors about our inability to "reduce non-type template parameter depth", fixing PR5311. Also fixes a bug when instantiating a template type parameter declaration in a member template, where we weren't properly reducing the template parameter's depth. LLVM's StringSwitch header now parses. llvm-svn: 85669
2009-11-01 01:21:17 +08:00
// itself.
Move more stuff out of Sema.h. llvm-svn: 112026
2010-08-25 13:32:35 +08:00
LocalInstantiationScope Scope(SemaRef);
Clean up our handling of local instantiation scopes, which keep track of the mapping from local declarations to their instantiated counterparts during template instantiation. Previously, we tried to do some unholy merging of local instantiation scopes that involved storing a single hash table along with an "undo" list on the side... which was ugly, and never handled function parameters properly. Now, we just keep separate hash tables for each local instantiation scope, and "combining" two scopes means that we'll look in each of the combined hash tables. The combined scope stack is rarely deep, and this makes it easy to avoid the "undo" issues we were hitting. Also, I've simplified the logic for function parameters: if we're declaring a function and we need the function parameters to live longer, we just push them back into the local instantiation scope where we need them. Fixes PR6990. llvm-svn: 102732
2010-05-01 02:55:50 +08:00
Implement instantiation of the declarations of member function templates within class templates, producing a member function template of a class template specialization. If you can parse that, I'm sorry. Example: template<typename T> struct X { template<typename U> void f(T, U); }; When we instantiate X<int>, we now instantiate the declaration X<int>::f, which looks like this: template<typename U> void X<int>::f(int, U); The path this takes through TemplateDeclInstantiator::VisitCXXMethodDecl is convoluted and ugly, but I don't know how to improve it yet. I'm resting my hopes on the multi-level substitution required to instantiate definitions of nested templates, which may simplify this code as well. More testing to come... llvm-svn: 80252
2009-08-28 00:57:43 +08:00
TemplateParameterList *TempParams = D->getTemplateParameters();
TemplateParameterList *InstParams = SubstTemplateParams(TempParams);
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
if (!InstParams)
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
FunctionDecl *Instantiated = nullptr;
Improve the internal representation and semantic analysis of friend function templates. This commit ensures that friend function templates are constructed as FunctionTemplateDecls rather than partial FunctionDecls (as they previously were). It then implements template instantiation for friend function templates, injecting the friend function template only when no previous declaration exists at the time of instantiation. Oh, and make sure that explicit specialization declarations are not friends. llvm-svn: 83970
2009-10-13 22:39:41 +08:00
if (CXXMethodDecl *DMethod = dyn_cast<CXXMethodDecl>(D->getTemplatedDecl()))
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Instantiated = cast_or_null<FunctionDecl>(VisitCXXMethodDecl(DMethod,
Improve the internal representation and semantic analysis of friend function templates. This commit ensures that friend function templates are constructed as FunctionTemplateDecls rather than partial FunctionDecls (as they previously were). It then implements template instantiation for friend function templates, injecting the friend function template only when no previous declaration exists at the time of instantiation. Oh, and make sure that explicit specialization declarations are not friends. llvm-svn: 83970
2009-10-13 22:39:41 +08:00
InstParams));
else
Instantiated = cast_or_null<FunctionDecl>(VisitFunctionDecl(
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
D->getTemplatedDecl(),
Improve the internal representation and semantic analysis of friend function templates. This commit ensures that friend function templates are constructed as FunctionTemplateDecls rather than partial FunctionDecls (as they previously were). It then implements template instantiation for friend function templates, injecting the friend function template only when no previous declaration exists at the time of instantiation. Oh, and make sure that explicit specialization declarations are not friends. llvm-svn: 83970
2009-10-13 22:39:41 +08:00
InstParams));
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Improve the internal representation and semantic analysis of friend function templates. This commit ensures that friend function templates are constructed as FunctionTemplateDecls rather than partial FunctionDecls (as they previously were). It then implements template instantiation for friend function templates, injecting the friend function template only when no previous declaration exists at the time of instantiation. Oh, and make sure that explicit specialization declarations are not friends. llvm-svn: 83970
2009-10-13 22:39:41 +08:00
if (!Instantiated)
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Implement instantiation of the declarations of member function templates within class templates, producing a member function template of a class template specialization. If you can parse that, I'm sorry. Example: template<typename T> struct X { template<typename U> void f(T, U); }; When we instantiate X<int>, we now instantiate the declaration X<int>::f, which looks like this: template<typename U> void X<int>::f(int, U); The path this takes through TemplateDeclInstantiator::VisitCXXMethodDecl is convoluted and ugly, but I don't know how to improve it yet. I'm resting my hopes on the multi-level substitution required to instantiate definitions of nested templates, which may simplify this code as well. More testing to come... llvm-svn: 80252
2009-08-28 00:57:43 +08:00
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
// Link the instantiated function template declaration to the function
Implement instantiation of the declarations of member function templates within class templates, producing a member function template of a class template specialization. If you can parse that, I'm sorry. Example: template<typename T> struct X { template<typename U> void f(T, U); }; When we instantiate X<int>, we now instantiate the declaration X<int>::f, which looks like this: template<typename U> void X<int>::f(int, U); The path this takes through TemplateDeclInstantiator::VisitCXXMethodDecl is convoluted and ugly, but I don't know how to improve it yet. I'm resting my hopes on the multi-level substitution required to instantiate definitions of nested templates, which may simplify this code as well. More testing to come... llvm-svn: 80252
2009-08-28 00:57:43 +08:00
// template from which it was instantiated.
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
FunctionTemplateDecl *InstTemplate
Improve the internal representation and semantic analysis of friend function templates. This commit ensures that friend function templates are constructed as FunctionTemplateDecls rather than partial FunctionDecls (as they previously were). It then implements template instantiation for friend function templates, injecting the friend function template only when no previous declaration exists at the time of instantiation. Oh, and make sure that explicit specialization declarations are not friends. llvm-svn: 83970
2009-10-13 22:39:41 +08:00
= Instantiated->getDescribedFunctionTemplate();
Permit explicit specialization of member functions of class templates that are declarations (rather than definitions). Also, be sure to set the access specifiers properly when instantiating the declarations of member function templates. llvm-svn: 83911
2009-10-13 06:27:17 +08:00
InstTemplate->setAccess(D->getAccess());
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
assert(InstTemplate &&
Improve the internal representation and semantic analysis of friend function templates. This commit ensures that friend function templates are constructed as FunctionTemplateDecls rather than partial FunctionDecls (as they previously were). It then implements template instantiation for friend function templates, injecting the friend function template only when no previous declaration exists at the time of instantiation. Oh, and make sure that explicit specialization declarations are not friends. llvm-svn: 83970
2009-10-13 22:39:41 +08:00
"VisitFunctionDecl/CXXMethodDecl didn't create a template!");
Fix PR5716 by bandaging over the solution until we can come back to it. I apologize for friend declarations. llvm-svn: 91359
2009-12-15 07:19:40 +08:00
Put function templates instantiated from friend declarations in the correct lexical context. This is required for ADL to work properly; fixes PR6716. llvm-svn: 99665
2010-03-27 07:10:15 +08:00
bool isFriend = (InstTemplate->getFriendObjectKind() != Decl::FOK_None);
Fix PR5716 by bandaging over the solution until we can come back to it. I apologize for friend declarations. llvm-svn: 91359
2009-12-15 07:19:40 +08:00
// Link the instantiation back to the pattern *unless* this is a
// non-definition friend declaration.
if (!InstTemplate->getInstantiatedFromMemberTemplate() &&
Put function templates instantiated from friend declarations in the correct lexical context. This is required for ADL to work properly; fixes PR6716. llvm-svn: 99665
2010-03-27 07:10:15 +08:00
!(isFriend && !D->getTemplatedDecl()->isThisDeclarationADefinition()))
Improve the internal representation and semantic analysis of friend function templates. This commit ensures that friend function templates are constructed as FunctionTemplateDecls rather than partial FunctionDecls (as they previously were). It then implements template instantiation for friend function templates, injecting the friend function template only when no previous declaration exists at the time of instantiation. Oh, and make sure that explicit specialization declarations are not friends. llvm-svn: 83970
2009-10-13 22:39:41 +08:00
InstTemplate->setInstantiatedFromMemberTemplate(D);
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Put function templates instantiated from friend declarations in the correct lexical context. This is required for ADL to work properly; fixes PR6716. llvm-svn: 99665
2010-03-27 07:10:15 +08:00
// Make declarations visible in the appropriate context.
Check access to friend declarations. There's a number of different things going on here that were problematic: - We were missing the actual access check, or rather, it was suppressed on account of being a redeclaration lookup. - The access check would naturally happen during delay, which isn't appropriate in this case. - We weren't actually emitting dependent diagnostics associated with class templates, which was unfortunate. - Access was being propagated incorrectly for friend method declarations that couldn't be matched at parse-time. llvm-svn: 161652
2012-08-10 11:15:35 +08:00
if (!isFriend) {
Improve the internal representation and semantic analysis of friend function templates. This commit ensures that friend function templates are constructed as FunctionTemplateDecls rather than partial FunctionDecls (as they previously were). It then implements template instantiation for friend function templates, injecting the friend function template only when no previous declaration exists at the time of instantiation. Oh, and make sure that explicit specialization declarations are not friends. llvm-svn: 83970
2009-10-13 22:39:41 +08:00
Owner->addDecl(InstTemplate);
Check access to friend declarations. There's a number of different things going on here that were problematic: - We were missing the actual access check, or rather, it was suppressed on account of being a redeclaration lookup. - The access check would naturally happen during delay, which isn't appropriate in this case. - We weren't actually emitting dependent diagnostics associated with class templates, which was unfortunate. - Access was being propagated incorrectly for friend method declarations that couldn't be matched at parse-time. llvm-svn: 161652
2012-08-10 11:15:35 +08:00
} else if (InstTemplate->getDeclContext()->isRecord() &&
[modules] When instantiating a class member, don't expect to find the previous declaration in the instantiation if the previous declaration came from another definition of the class template that got merged into the pattern definition. llvm-svn: 219552
2014-10-11 08:37:16 +08:00
!getPreviousDeclForInstantiation(D)) {
Check access to friend declarations. There's a number of different things going on here that were problematic: - We were missing the actual access check, or rather, it was suppressed on account of being a redeclaration lookup. - The access check would naturally happen during delay, which isn't appropriate in this case. - We weren't actually emitting dependent diagnostics associated with class templates, which was unfortunate. - Access was being propagated incorrectly for friend method declarations that couldn't be matched at parse-time. llvm-svn: 161652
2012-08-10 11:15:35 +08:00
SemaRef.CheckFriendAccess(InstTemplate);
}
Put function templates instantiated from friend declarations in the correct lexical context. This is required for ADL to work properly; fixes PR6716. llvm-svn: 99665
2010-03-27 07:10:15 +08:00
Implement instantiation of the declarations of member function templates within class templates, producing a member function template of a class template specialization. If you can parse that, I'm sorry. Example: template<typename T> struct X { template<typename U> void f(T, U); }; When we instantiate X<int>, we now instantiate the declaration X<int>::f, which looks like this: template<typename U> void X<int>::f(int, U); The path this takes through TemplateDeclInstantiator::VisitCXXMethodDecl is convoluted and ugly, but I don't know how to improve it yet. I'm resting my hopes on the multi-level substitution required to instantiate definitions of nested templates, which may simplify this code as well. More testing to come... llvm-svn: 80252
2009-08-28 00:57:43 +08:00
return InstTemplate;
}
Instantiation for member classes of class templates. Note that only the declarations of member classes are instantiated when the owning class template is instantiated. The definitions of such member classes are instantiated when a complete type is required. This change also introduces the injected-class-name into a class template specialization. llvm-svn: 67707
2009-03-26 05:17:03 +08:00
Decl *TemplateDeclInstantiator::VisitCXXRecordDecl(CXXRecordDecl *D) {
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
CXXRecordDecl *PrevDecl = nullptr;
Instantiation for member classes of class templates. Note that only the declarations of member classes are instantiated when the owning class template is instantiated. The definitions of such member classes are instantiated when a complete type is required. This change also introduces the injected-class-name into a class template specialization. llvm-svn: 67707
2009-03-26 05:17:03 +08:00
if (D->isInjectedClassName())
PrevDecl = cast<CXXRecordDecl>(Owner);
[modules] When instantiating a class member, don't expect to find the previous declaration in the instantiation if the previous declaration came from another definition of the class template that got merged into the pattern definition. llvm-svn: 219552
2014-10-11 08:37:16 +08:00
else if (CXXRecordDecl *PatternPrev = getPreviousDeclForInstantiation(D)) {
When looking for the instantiated declaration that corresponds to a given declaration in a template, make sure that the context we're searching through is complete. Fixes PR6376. llvm-svn: 97444
2010-03-01 23:56:25 +08:00
NamedDecl *Prev = SemaRef.FindInstantiatedDecl(D->getLocation(),
[modules] When instantiating a class member, don't expect to find the previous declaration in the instantiation if the previous declaration came from another definition of the class template that got merged into the pattern definition. llvm-svn: 219552
2014-10-11 08:37:16 +08:00
PatternPrev,
Link up member-class redeclarations during template instantiation. This test courtesy of LLVM. llvm-svn: 91462
2009-12-16 06:29:06 +08:00
TemplateArgs);
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
if (!Prev) return nullptr;
Link up member-class redeclarations during template instantiation. This test courtesy of LLVM. llvm-svn: 91462
2009-12-16 06:29:06 +08:00
PrevDecl = cast<CXXRecordDecl>(Prev);
}
Instantiation for member classes of class templates. Note that only the declarations of member classes are instantiated when the owning class template is instantiated. The definitions of such member classes are instantiated when a complete type is required. This change also introduces the injected-class-name into a class template specialization. llvm-svn: 67707
2009-03-26 05:17:03 +08:00
CXXRecordDecl *Record
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
= CXXRecordDecl::Create(SemaRef.Context, D->getTagKind(), Owner,
Fixed InnerLocStart. llvm-svn: 127330
2011-03-09 22:09:51 +08:00
D->getLocStart(), D->getLocation(),
D->getIdentifier(), PrevDecl);
Remember declaration scope qualifiers in the AST. Imposes no memory overhead on unqualified declarations. Patch by Enea Zaffanella! Minimal adjustments: allocate the ExtInfo nodes with the ASTContext and delete them during Destroy(). I audited a bunch of Destroy methods at the same time, to ensure that the correct teardown was being done. llvm-svn: 98540
2010-03-15 18:12:16 +08:00
// Substitute the nested name specifier, if any.
if (SubstQualifier(D, Record))
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Remember declaration scope qualifiers in the AST. Imposes no memory overhead on unqualified declarations. Patch by Enea Zaffanella! Minimal adjustments: allocate the ExtInfo nodes with the ASTContext and delete them during Destroy(). I audited a bunch of Destroy methods at the same time, to ensure that the correct teardown was being done. llvm-svn: 98540
2010-03-15 18:12:16 +08:00
Instantiation for member classes of class templates. Note that only the declarations of member classes are instantiated when the owning class template is instantiated. The definitions of such member classes are instantiated when a complete type is required. This change also introduces the injected-class-name into a class template specialization. llvm-svn: 67707
2009-03-26 05:17:03 +08:00
Record->setImplicit(D->isImplicit());
Fix for PR4794 (instantiating friend class decl); this version shouldn't cause any regressions. llvm-svn: 80277
2009-08-28 03:11:42 +08:00
// FIXME: Check against AS_none is an ugly hack to work around the issue that
// the tag decls introduced by friend class declarations don't have an access
// specifier. Remove once this area of the code gets sorted out.
if (D->getAccess() != AS_none)
Record->setAccess(D->getAccess());
Instantiation for member classes of class templates. Note that only the declarations of member classes are instantiated when the owning class template is instantiated. The definitions of such member classes are instantiated when a complete type is required. This change also introduces the injected-class-name into a class template specialization. llvm-svn: 67707
2009-03-26 05:17:03 +08:00
if (!D->isInjectedClassName())
Improve checking for specializations of member classes of class templates, and keep track of how those member classes were instantiated or specialized. Make sure that we don't try to instantiate an explicitly-specialized member class of a class template, when that explicit specialization was a declaration rather than a definition. llvm-svn: 83547
2009-10-08 23:14:33 +08:00
Record->setInstantiationOfMemberClass(D, TSK_ImplicitInstantiation);
Instantiation for member classes of class templates. Note that only the declarations of member classes are instantiated when the owning class template is instantiated. The definitions of such member classes are instantiated when a complete type is required. This change also introduces the injected-class-name into a class template specialization. llvm-svn: 67707
2009-03-26 05:17:03 +08:00
Omnibus friend decl refactoring. Instead of cloning AST classes for friend declarations of same, introduce a single AST class and add appropriate bits (encoded in the namespace) for whether a decl is "real" or not. Much hackery about previously-declared / not-previously-declared, but it's essentially mandated by the standard that friends alter lookup, and this is at least fairly non-intrusive. Refactor the Sema methods specific to friends for cleaner flow and less nesting. Incidentally solve a few bugs, but I remain confident that we can put them back. llvm-svn: 80353
2009-08-28 15:59:38 +08:00
// If the original function was part of a friend declaration,
// inherit its namespace state.
Reinstate r186040, with additional fixes and more test coverage (reverted in r186331). Original commit log: If we friend a declaration twice, that should not make it visible to name lookup in the surrounding context. Slightly rework how we handle friend declarations to inherit the visibility of the prior declaration, rather than setting a friend declaration to be visible whenever there was a prior declaration. llvm-svn: 186546
2013-07-18 07:53:16 +08:00
if (D->getFriendObjectKind())
Record->setObjectOfFriendDecl();
Omnibus friend decl refactoring. Instead of cloning AST classes for friend declarations of same, introduce a single AST class and add appropriate bits (encoded in the namespace) for whether a decl is "real" or not. Much hackery about previously-declared / not-previously-declared, but it's essentially mandated by the standard that friends alter lookup, and this is at least fairly non-intrusive. Refactor the Sema methods specific to friends for cleaner flow and less nesting. Incidentally solve a few bugs, but I remain confident that we can put them back. llvm-svn: 80353
2009-08-28 15:59:38 +08:00
When instantiating anonymous structs/unions within a function, make sure that the anonymous struct/union record declaration gets instantiated before the variable declaration, and that it and its fields (recursively) get entries in the local instantiation map. Fixes PR7088. llvm-svn: 104305
2010-05-21 08:31:19 +08:00
// Make sure that anonymous structs and unions are recorded.
Sema: Instantiate local class and their members appropriately We would fail to instantiate them when the surrounding function was instantiated. Instantiate the class and add it's members to the list of pending instantiations, they should be resolved when we are finished with the function's body. This fixes PR9685. llvm-svn: 195827
2013-11-27 16:20:38 +08:00
if (D->isAnonymousStructOrUnion())
When instantiating anonymous structs/unions within a function, make sure that the anonymous struct/union record declaration gets instantiated before the variable declaration, and that it and its fields (recursively) get entries in the local instantiation map. Fixes PR7088. llvm-svn: 104305
2010-05-21 08:31:19 +08:00
Record->setAnonymousStructOrUnion(true);
Sema: Instantiate local class and their members appropriately We would fail to instantiate them when the surrounding function was instantiated. Instantiate the class and add it's members to the list of pending instantiations, they should be resolved when we are finished with the function's body. This fixes PR9685. llvm-svn: 195827
2013-11-27 16:20:38 +08:00
if (D->isLocalClass())
SemaRef.CurrentInstantiationScope->InstantiatedLocal(D, Record);
Don't assert when instantiating member references to fields in anonymous structs. llvm-svn: 80657
2009-09-01 12:26:58 +08:00
Sema: Propagate the mangling number into instantiations We would lose track of the mangling number assigned to the original declaration which would cause us to create manglings that didn't match the Itanium C++ specification. e.g. Two static fields with the same name inside of a function template would receive the same mangling with LLVM fixing up the second field so they wouldn't collide. This would create an incompatibility with other compilers following the Itanium ABI. I've confirmed that the new mangling is identical to the ones generated by icc and gcc. N.B. This was uncovered while working on Microsoft mangler. llvm-svn: 196368
2013-12-04 17:01:55 +08:00
// Forward the mangling number from the template to the instantiated decl.
SemaRef.Context.setManglingNumber(Record,
SemaRef.Context.getManglingNumber(D));
[MS ABI] Correctly mangle classes without names for linkage purposes A class without a name for linkage purposes gets a name along the lines of <unnamed-type-foo> where foo is either the name of a declarator which defined it (like a variable or field) or a typedef-name (like a typedef or alias-declaration). We handled the declarator case correctly but it would fall down during template instantiation if the declarator didn't share the tag's type. We failed to handle the typedef-name case at all. Instead, keep track of the association between the two and keep it up to date in the face of template instantiation. llvm-svn: 246469
2015-09-01 02:48:39 +08:00
// See if the old tag was defined along with a declarator.
// If it did, mark the new tag as being associated with that declarator.
if (DeclaratorDecl *DD = SemaRef.Context.getDeclaratorForUnnamedTagDecl(D))
SemaRef.Context.addDeclaratorForUnnamedTagDecl(Record, DD);
// See if the old tag was defined along with a typedef.
// If it did, mark the new tag as being associated with that typedef.
if (TypedefNameDecl *TND = SemaRef.Context.getTypedefNameForUnnamedTagDecl(D))
SemaRef.Context.addTypedefNameForUnnamedTagDecl(Record, TND);
De-ASTContext-ify DeclContext. Remove ASTContext parameter from DeclContext's methods. This change cascaded down to other Decl's methods and changes to call sites started "escalating". Timings using pre-tokenized "cocoa.h" showed only a ~1% increase in time run between and after this commit. llvm-svn: 74506
2009-06-30 10:36:12 +08:00
Owner->addDecl(Record);
Sema: Instantiate local class and their members appropriately We would fail to instantiate them when the surrounding function was instantiated. Instantiate the class and add it's members to the list of pending instantiations, they should be resolved when we are finished with the function's body. This fixes PR9685. llvm-svn: 195827
2013-11-27 16:20:38 +08:00
// DR1484 clarifies that the members of a local class are instantiated as part
// of the instantiation of their enclosing entity.
if (D->isCompleteDefinition() && D->isLocalClass()) {
Rename RAII objects for performing eager instantiation to have names that describe what they're for, not how they do it, and factor out a bit more common code into them. llvm-svn: 303479
2017-05-20 09:36:41 +08:00
Sema::LocalEagerInstantiationScope LocalInstantiations(SemaRef);
PR20625: Instantiate static constexpr member function of a local struct in a function template earlier. This is necessary in order to allow the use of a constexpr member function, or a member function with deduced return type, of a local class within a surrounding instantiated function template specialization. Patch by Michael Park! This re-commits r236063, which was reverted in r236134, along with a fix for a delayed template parsing bug that was exposed by this change. llvm-svn: 237064
2015-05-12 07:09:06 +08:00
Sema: Don't crash when trying to instantiate a local class with an invalid base specifier It was previously thought that Sema::InstantiateClass could not fail from within this point in instantiate. However, it can happen if the class is invalid some way (i.e. invalid base specifier). This fixes PR18907. Differential Revision: http://llvm-reviews.chandlerc.com/D2850 llvm-svn: 201913
2014-02-22 08:17:46 +08:00
SemaRef.InstantiateClass(D->getLocation(), Record, D, TemplateArgs,
TSK_ImplicitInstantiation,
/*Complain=*/true);
PR20625: Instantiate static constexpr member function of a local struct in a function template earlier. This is necessary in order to allow the use of a constexpr member function, or a member function with deduced return type, of a local class within a surrounding instantiated function template specialization. Patch by Michael Park! This re-commits r236063, which was reverted in r236134, along with a fix for a delayed template parsing bug that was exposed by this change. llvm-svn: 237064
2015-05-12 07:09:06 +08:00
Only instantiate members of nested classes in local classes once, rather than once per enclosing class. llvm-svn: 291034
2017-01-05 07:45:01 +08:00
// For nested local classes, we will instantiate the members when we
// reach the end of the outermost (non-nested) local class.
if (!D->isCXXClassMember())
SemaRef.InstantiateClassMembers(D->getLocation(), Record, TemplateArgs,
TSK_ImplicitInstantiation);
PR20625: Instantiate static constexpr member function of a local struct in a function template earlier. This is necessary in order to allow the use of a constexpr member function, or a member function with deduced return type, of a local class within a surrounding instantiated function template specialization. Patch by Michael Park! This re-commits r236063, which was reverted in r236134, along with a fix for a delayed template parsing bug that was exposed by this change. llvm-svn: 237064
2015-05-12 07:09:06 +08:00
// This class may have local implicit instantiations that need to be
// performed within this scope.
Rename RAII objects for performing eager instantiation to have names that describe what they're for, not how they do it, and factor out a bit more common code into them. llvm-svn: 303479
2017-05-20 09:36:41 +08:00
LocalInstantiations.perform();
Sema: Instantiate local class and their members appropriately We would fail to instantiate them when the surrounding function was instantiated. Instantiate the class and add it's members to the list of pending instantiations, they should be resolved when we are finished with the function's body. This fixes PR9685. llvm-svn: 195827
2013-11-27 16:20:38 +08:00
}
Add -Wunused-local-typedef, a warning that finds unused local typedefs. The warning warns on TypedefNameDecls -- typedefs and C++11 using aliases -- that are !isReferenced(). Since the isReferenced() bit on TypedefNameDecls wasn't used for anything before this warning it wasn't always set correctly, so this patch also adds a few missing MarkAnyDeclReferenced() calls in various places for TypedefNameDecls. This is made a bit complicated due to local typedefs possibly being used only after their local scope has closed. Consider: template <class T> void template_fun(T t) { typename T::Foo s3foo; // YYY (void)s3foo; } void template_fun_user() { struct Local { typedef int Foo; // XXX } p; template_fun(p); } Here the typedef in XXX is only used at end-of-translation unit, when YYY in template_fun() gets instantiated. To handle this, typedefs that are unused when their scope exits are added to a set of potentially unused typedefs, and that set gets checked at end-of-TU. Typedefs that are still unused at that point then get warned on. There's also serialization code for this set, so that the warning works with precompiled headers and modules. For modules, the warning is emitted when the module is built, for precompiled headers each time the header gets used. Finally, consider a function using C++14 auto return types to return a local type defined in a header: auto f() { struct S { typedef int a; }; return S(); } Here, the typedef escapes its local scope and could be used by only some translation units including the header. To not warn on this, add a RecursiveASTVisitor that marks all delcs on local types returned from auto functions as referenced. (Except if it's a function with internal linkage, or the decls are private and the local type has no friends -- in these cases, it _is_ safe to warn.) Several of the included testcases (most of the interesting ones) were provided by Richard Smith. (gcc's spelling -Wunused-local-typedefs is supported as an alias for this warning.) llvm-svn: 217298
2014-09-06 09:25:55 +08:00
SemaRef.DiagnoseUnusedNestedTypedefs(Record);
Instantiation for member classes of class templates. Note that only the declarations of member classes are instantiated when the owning class template is instantiated. The definitions of such member classes are instantiated when a complete type is required. This change also introduces the injected-class-name into a class template specialization. llvm-svn: 67707
2009-03-26 05:17:03 +08:00
return Record;
}
When we substitute into the type of a function based on the TypeSourceInfo, we may have lost some adjustments made to the type of that function due to declaration merging. Adjust the resulting type correspondingly. Fixes PR12948 / <rdar://problem/11552434>. llvm-svn: 163845
2012-09-14 05:56:43 +08:00
/// \brief Adjust the given function type for an instantiation of the
/// given declaration, to cope with modifications to the function's type that
/// aren't reflected in the type-source information.
///
/// \param D The declaration we're instantiating.
/// \param TInfo The already-instantiated type.
static QualType adjustFunctionTypeForInstantiation(ASTContext &Context,
FunctionDecl *D,
TypeSourceInfo *TInfo) {
Actually rebuild function types properly when adjusting the function type of an instantiation. llvm-svn: 163848
2012-09-14 06:01:49 +08:00
const FunctionProtoType *OrigFunc
= D->getType()->castAs<FunctionProtoType>();
const FunctionProtoType *NewFunc
= TInfo->getType()->castAs<FunctionProtoType>();
if (OrigFunc->getExtInfo() == NewFunc->getExtInfo())
return TInfo->getType();
FunctionProtoType::ExtProtoInfo NewEPI = NewFunc->getExtProtoInfo();
NewEPI.ExtInfo = OrigFunc->getExtInfo();
Rename getResultType() on function and method declarations to getReturnType() A return type is the declared or deduced part of the function type specified in the declaration. A result type is the (potentially adjusted) type of the value of an expression that calls the function. Rule of thumb: * Declarations have return types and parameters. * Expressions have result types and arguments. llvm-svn: 200082
2014-01-26 00:55:45 +08:00
return Context.getFunctionType(NewFunc->getReturnType(),
Rename FunctionProtoType accessors from 'arguments' to 'parameters' Fix a perennial source of confusion in the clang type system: Declarations and function prototypes have parameters to which arguments are supplied, so calling these 'arguments' was a stretch even in C mode, let alone C++ where default arguments, templates and overloading make the distinction important to get right. Readability win across the board, especially in the casting, ADL and overloading implementations which make a lot more sense at a glance now. Will keep an eye on the builders and update dependent projects shortly. No functional change. llvm-svn: 199686
2014-01-21 04:26:09 +08:00
NewFunc->getParamTypes(), NewEPI);
When we substitute into the type of a function based on the TypeSourceInfo, we may have lost some adjustments made to the type of that function due to declaration merging. Adjust the resulting type correspondingly. Fixes PR12948 / <rdar://problem/11552434>. llvm-svn: 163845
2012-09-14 05:56:43 +08:00
}
Omnibus friend decl refactoring. Instead of cloning AST classes for friend declarations of same, introduce a single AST class and add appropriate bits (encoded in the namespace) for whether a decl is "real" or not. Much hackery about previously-declared / not-previously-declared, but it's essentially mandated by the standard that friends alter lookup, and this is at least fairly non-intrusive. Refactor the Sema methods specific to friends for cleaner flow and less nesting. Incidentally solve a few bugs, but I remain confident that we can put them back. llvm-svn: 80353
2009-08-28 15:59:38 +08:00
/// Normal class members are of more specific types and therefore
/// don't make it here. This function serves two purposes:
/// 1) instantiating function templates
/// 2) substituting friend declarations
Egregious, disgusting workaround for PR5866. We need to rework how we keep track of friends within templates, which will provide a real for PR5866. For now, this makes sure we don't do something entirely stupid with friends of specializations. llvm-svn: 92143
2009-12-25 04:56:24 +08:00
Decl *TemplateDeclInstantiator::VisitFunctionDecl(FunctionDecl *D,
Improve the internal representation and semantic analysis of friend function templates. This commit ensures that friend function templates are constructed as FunctionTemplateDecls rather than partial FunctionDecls (as they previously were). It then implements template instantiation for friend function templates, injecting the friend function template only when no previous declaration exists at the time of instantiation. Oh, and make sure that explicit specialization declarations are not friends. llvm-svn: 83970
2009-10-13 22:39:41 +08:00
TemplateParameterList *TemplateParams) {
Keep track of function template specializations, to eliminate redundant, implicit instantiations of function templates and provide a place where we can hang function template specializations. llvm-svn: 74454
2009-06-30 04:59:39 +08:00
// Check whether there is already a function template specialization for
// this declaration.
FunctionTemplateDecl *FunctionTemplate = D->getDescribedFunctionTemplate();
Implement method friends in class templates and fix a few related problems. llvm-svn: 99708
2010-03-27 13:57:59 +08:00
if (FunctionTemplate && !TemplateParams) {
ArrayRef'ize MultiLevelTemplateArgumentList::ArgList. Patch by Faisal Vali! llvm-svn: 181077
2013-05-04 07:46:09 +08:00
ArrayRef<TemplateArgument> Innermost = TemplateArgs.getInnermost();
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
void *InsertPos = nullptr;
Hide FunctionTemplateDecl's specializations folding set as implementation detail and introduce FunctionTemplateDecl::findSpecialization. Redeclarations of specializations will not cause the previous decl to be removed from the set, the set will keep the canonical decl. findSpecialization will return the most recent redeclaration. llvm-svn: 108834
2010-07-20 21:59:58 +08:00
FunctionDecl *SpecFunc
Convert some function arguments to use ArrayRef. llvm-svn: 211764
2014-06-26 12:58:53 +08:00
= FunctionTemplate->findSpecialization(Innermost, InsertPos);
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Keep track of function template specializations, to eliminate redundant, implicit instantiations of function templates and provide a place where we can hang function template specializations. llvm-svn: 74454
2009-06-30 04:59:39 +08:00
// If we already have a function template specialization, return it.
Hide FunctionTemplateDecl's specializations folding set as implementation detail and introduce FunctionTemplateDecl::findSpecialization. Redeclarations of specializations will not cause the previous decl to be removed from the set, the set will keep the canonical decl. findSpecialization will return the most recent redeclaration. llvm-svn: 108834
2010-07-20 21:59:58 +08:00
if (SpecFunc)
return SpecFunc;
Keep track of function template specializations, to eliminate redundant, implicit instantiations of function templates and provide a place where we can hang function template specializations. llvm-svn: 74454
2009-06-30 04:59:39 +08:00
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Implement method friends in class templates and fix a few related problems. llvm-svn: 99708
2010-03-27 13:57:59 +08:00
bool isFriend;
if (FunctionTemplate)
isFriend = (FunctionTemplate->getFriendObjectKind() != Decl::FOK_None);
else
isFriend = (D->getFriendObjectKind() != Decl::FOK_None);
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
bool MergeWithParentScope = (TemplateParams != nullptr) ||
When instantiating a function declaration within a function template, be sure to merge its parameter scope with its parent's scope. Fixes PR7184. llvm-svn: 104386
2010-05-22 05:25:08 +08:00
Owner->isFunctionOrMethod() ||
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
!(isa<Decl>(Owner) &&
When we are instantiating a member function of a local class, be sure to merge the local instantiation scope with the outer local instantiation scope, so that we can instantiate declarations from the function owning the local class. Fixes an assert while instantiating Boost.MPL's BOOST_MPL_ASSERT_MSG. llvm-svn: 93651
2010-01-17 04:21:20 +08:00
cast<Decl>(Owner)->isDefinedOutsideFunctionOrMethod());
Move more stuff out of Sema.h. llvm-svn: 112026
2010-08-25 13:32:35 +08:00
LocalInstantiationScope Scope(SemaRef, MergeWithParentScope);
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
remove unneeded llvm:: namespace qualifiers on some core types now that LLVM.h imports them into the clang namespace. llvm-svn: 135852
2011-07-23 18:55:15 +08:00
SmallVector<ParmVarDecl *, 4> Params;
Removing unused initialization. llvm-svn: 144264
2011-11-10 13:42:04 +08:00
TypeSourceInfo *TInfo = SubstFunctionType(D, Params);
Maintain type source information for functions through template instantiation. Based on a patch by Enea Zaffanella! I found a way to reduce some of the redundancy between TreeTransform's "standard" FunctionProtoType transformation and TemplateInstantiator's override, and I killed off the old SubstFunctionType by adding type source info for the last cases where we were creating FunctionDecls without TSI (at least that get passed through template instantiation). llvm-svn: 98252
2010-03-11 17:03:00 +08:00
if (!TInfo)
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
When we substitute into the type of a function based on the TypeSourceInfo, we may have lost some adjustments made to the type of that function due to declaration merging. Adjust the resulting type correspondingly. Fixes PR12948 / <rdar://problem/11552434>. llvm-svn: 163845
2012-09-14 05:56:43 +08:00
QualType T = adjustFunctionTypeForInstantiation(SemaRef.Context, D, TInfo);
Support friend declarations in templates and test that argdep lookup still works. llvm-svn: 78979
2009-08-14 10:03:10 +08:00
Use NestedNameSpecifierLoc within out-of-line variables, function, and tag definitions. Also, add support for template instantiation of NestedNameSpecifierLocs. llvm-svn: 126470
2011-02-25 10:25:35 +08:00
NestedNameSpecifierLoc QualifierLoc = D->getQualifierLoc();
if (QualifierLoc) {
QualifierLoc = SemaRef.SubstNestedNameSpecifierLoc(QualifierLoc,
TemplateArgs);
if (!QualifierLoc)
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Reapply r99596 with a fix: link an instantiated friend function to its pattern if it has a body. llvm-svn: 99610
2010-03-26 12:53:08 +08:00
}
Teach Sema how to instantiate a local function declaration properly. Fixes PR 5517. llvm-svn: 95470
2010-02-06 09:50:47 +08:00
// If we're instantiating a local function declaration, put the result
Switch the semantic DeclContext for a block-scope declaration of a function or variable from being the function to being the enclosing namespace scope (in C++) or the TU (in C). This allows us to fix a selection of related issues where we would build incorrect redeclaration chains for such declarations, and fail to notice type mismatches. Such declarations are put into a new IdentifierNamespace, IDNS_LocalExtern, which is only found when searching scopes, and not found when searching DeclContexts. Such a declaration is only made visible in its DeclContext if there are no non-LocalExtern declarations. llvm-svn: 191064
2013-09-20 09:15:31 +08:00
// in the enclosing namespace; otherwise we need to find the instantiated
// context.
Teach Sema how to instantiate a local function declaration properly. Fixes PR 5517. llvm-svn: 95470
2010-02-06 09:50:47 +08:00
DeclContext *DC;
Switch the semantic DeclContext for a block-scope declaration of a function or variable from being the function to being the enclosing namespace scope (in C++) or the TU (in C). This allows us to fix a selection of related issues where we would build incorrect redeclaration chains for such declarations, and fail to notice type mismatches. Such declarations are put into a new IdentifierNamespace, IDNS_LocalExtern, which is only found when searching scopes, and not found when searching DeclContexts. Such a declaration is only made visible in its DeclContext if there are no non-LocalExtern declarations. llvm-svn: 191064
2013-09-20 09:15:31 +08:00
if (D->isLocalExternDecl()) {
Teach Sema how to instantiate a local function declaration properly. Fixes PR 5517. llvm-svn: 95470
2010-02-06 09:50:47 +08:00
DC = Owner;
Switch the semantic DeclContext for a block-scope declaration of a function or variable from being the function to being the enclosing namespace scope (in C++) or the TU (in C). This allows us to fix a selection of related issues where we would build incorrect redeclaration chains for such declarations, and fail to notice type mismatches. Such declarations are put into a new IdentifierNamespace, IDNS_LocalExtern, which is only found when searching scopes, and not found when searching DeclContexts. Such a declaration is only made visible in its DeclContext if there are no non-LocalExtern declarations. llvm-svn: 191064
2013-09-20 09:15:31 +08:00
SemaRef.adjustContextForLocalExternDecl(DC);
} else if (isFriend && QualifierLoc) {
Reapply r99596 with a fix: link an instantiated friend function to its pattern if it has a body. llvm-svn: 99610
2010-03-26 12:53:08 +08:00
CXXScopeSpec SS;
Use NestedNameSpecifierLoc within out-of-line variables, function, and tag definitions. Also, add support for template instantiation of NestedNameSpecifierLocs. llvm-svn: 126470
2011-02-25 10:25:35 +08:00
SS.Adopt(QualifierLoc);
Reapply r99596 with a fix: link an instantiated friend function to its pattern if it has a body. llvm-svn: 99610
2010-03-26 12:53:08 +08:00
DC = SemaRef.computeDeclContext(SS);
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
if (!DC) return nullptr;
Reapply r99596 with a fix: link an instantiated friend function to its pattern if it has a body. llvm-svn: 99610
2010-03-26 12:53:08 +08:00
} else {
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
DC = SemaRef.FindInstantiatedContext(D->getLocation(), D->getDeclContext(),
When looking for the instantiated declaration that corresponds to a given declaration in a template, make sure that the context we're searching through is complete. Fixes PR6376. llvm-svn: 97444
2010-03-01 23:56:25 +08:00
TemplateArgs);
Reapply r99596 with a fix: link an instantiated friend function to its pattern if it has a body. llvm-svn: 99610
2010-03-26 12:53:08 +08:00
}
Teach Sema how to instantiate a local function declaration properly. Fixes PR 5517. llvm-svn: 95470
2010-02-06 09:50:47 +08:00
Add an explicit derived class of FunctionDecl to model deduction guides rather than just treating them as FunctionDecls with a funny name. No functionality change intended. llvm-svn: 295491
2017-02-18 04:05:37 +08:00
FunctionDecl *Function;
if (auto *DGuide = dyn_cast<CXXDeductionGuideDecl>(D))
Function = CXXDeductionGuideDecl::Create(
SemaRef.Context, DC, D->getInnerLocStart(), DGuide->isExplicit(),
D->getNameInfo(), T, TInfo, D->getSourceRange().getEnd());
else {
Function = FunctionDecl::Create(
SemaRef.Context, DC, D->getInnerLocStart(), D->getNameInfo(), T, TInfo,
D->getCanonicalDecl()->getStorageClass(), D->isInlineSpecified(),
D->hasWrittenPrototype(), D->isConstexpr());
Function->setRangeEnd(D->getSourceRange().getEnd());
}
Remember declaration scope qualifiers in the AST. Imposes no memory overhead on unqualified declarations. Patch by Enea Zaffanella! Minimal adjustments: allocate the ExtInfo nodes with the ASTContext and delete them during Destroy(). I audited a bunch of Destroy methods at the same time, to ensure that the correct teardown was being done. llvm-svn: 98540
2010-03-15 18:12:16 +08:00
Clean up: since we have FunctionDecl::IsInline, make it store the right value for template instantiations, and use it to simplify the implementation of FunctionDecl::isInlined(). This incidentally changes the result of isInlined on a declared-but-not-defined non-inline member function from true to false. This is sort of a bug fix, but currently isInlined is only called on function definitions, so it has no visible effects. llvm-svn: 173397
2013-01-25 08:08:28 +08:00
if (D->isInlined())
Function->setImplicitlyInline();
Use NestedNameSpecifierLoc within out-of-line variables, function, and tag definitions. Also, add support for template instantiation of NestedNameSpecifierLocs. llvm-svn: 126470
2011-02-25 10:25:35 +08:00
if (QualifierLoc)
Function->setQualifierInfo(QualifierLoc);
Remember declaration scope qualifiers in the AST. Imposes no memory overhead on unqualified declarations. Patch by Enea Zaffanella! Minimal adjustments: allocate the ExtInfo nodes with the ASTContext and delete them during Destroy(). I audited a bunch of Destroy methods at the same time, to ensure that the correct teardown was being done. llvm-svn: 98540
2010-03-15 18:12:16 +08:00
Switch the semantic DeclContext for a block-scope declaration of a function or variable from being the function to being the enclosing namespace scope (in C++) or the TU (in C). This allows us to fix a selection of related issues where we would build incorrect redeclaration chains for such declarations, and fail to notice type mismatches. Such declarations are put into a new IdentifierNamespace, IDNS_LocalExtern, which is only found when searching scopes, and not found when searching DeclContexts. Such a declaration is only made visible in its DeclContext if there are no non-LocalExtern declarations. llvm-svn: 191064
2013-09-20 09:15:31 +08:00
if (D->isLocalExternDecl())
Function->setLocalExternDecl();
Put function templates instantiated from friend declarations in the correct lexical context. This is required for ADL to work properly; fixes PR6716. llvm-svn: 99665
2010-03-27 07:10:15 +08:00
DeclContext *LexicalDC = Owner;
Switch the semantic DeclContext for a block-scope declaration of a function or variable from being the function to being the enclosing namespace scope (in C++) or the TU (in C). This allows us to fix a selection of related issues where we would build incorrect redeclaration chains for such declarations, and fail to notice type mismatches. Such declarations are put into a new IdentifierNamespace, IDNS_LocalExtern, which is only found when searching scopes, and not found when searching DeclContexts. Such a declaration is only made visible in its DeclContext if there are no non-LocalExtern declarations. llvm-svn: 191064
2013-09-20 09:15:31 +08:00
if (!isFriend && D->isOutOfLine() && !D->isLocalExternDecl()) {
Put function templates instantiated from friend declarations in the correct lexical context. This is required for ADL to work properly; fixes PR6716. llvm-svn: 99665
2010-03-27 07:10:15 +08:00
assert(D->getDeclContext()->isFileContext());
LexicalDC = D->getDeclContext();
}
Function->setLexicalDeclContext(LexicalDC);
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Improved semantic analysis and AST respresentation for function templates. For example, this now type-checks (but does not instantiate the body of deref<int>): template<typename T> T& deref(T* t) { return *t; } void test(int *ip) { int &ir = deref(ip); } Specific changes/additions: * Template argument deduction from a call to a function template. * Instantiation of a function template specializations (just the declarations) from the template arguments deduced from a call. * FunctionTemplateDecls are stored directly in declaration contexts and found via name lookup (all forms), rather than finding the FunctionDecl and then realizing it is a template. This is responsible for most of the churn, since some of the core declaration matching and lookup code assumes that all functions are FunctionDecls. llvm-svn: 74213
2009-06-26 06:08:12 +08:00
// Attach the parameters
Fix declaring class template methods with an attributed typedef This change unifies the logic for template instantiation of methods and functions declared with typedefs. It ensures that SubstFunctionType() always fills the Params out param with non-null ParmVarDecls or returns null. Reviewers: rsmith Differential Revision: http://llvm-reviews.chandlerc.com/D1135 llvm-svn: 187528
2013-08-01 05:00:18 +08:00
for (unsigned P = 0; P < Params.size(); ++P)
if (Params[P])
Params[P]->setOwningFunction(Function);
ArrayRef-ifying Function/BlockDecl's setParams llvm-svn: 140268
2011-09-22 02:16:56 +08:00
Function->setParams(Params);
Omnibus friend decl refactoring. Instead of cloning AST classes for friend declarations of same, introduce a single AST class and add appropriate bits (encoded in the namespace) for whether a decl is "real" or not. Much hackery about previously-declared / not-previously-declared, but it's essentially mandated by the standard that friends alter lookup, and this is at least fairly non-intrusive. Refactor the Sema methods specific to friends for cleaner flow and less nesting. Incidentally solve a few bugs, but I remain confident that we can put them back. llvm-svn: 80353
2009-08-28 15:59:38 +08:00
C++98/03 [temp.friend]p4 requires that inline function definitions within class templates be instantiated along with each class template specialization, even if the functions are not used. Do so, as a baby step toward PR6952. llvm-svn: 103943
2010-05-18 00:38:00 +08:00
SourceLocation InstantiateAtPOI;
Improve the internal representation and semantic analysis of friend function templates. This commit ensures that friend function templates are constructed as FunctionTemplateDecls rather than partial FunctionDecls (as they previously were). It then implements template instantiation for friend function templates, injecting the friend function template only when no previous declaration exists at the time of instantiation. Oh, and make sure that explicit specialization declarations are not friends. llvm-svn: 83970
2009-10-13 22:39:41 +08:00
if (TemplateParams) {
// Our resulting instantiation is actually a function template, since we
// are substituting only the outer template parameters. For example, given
//
// template<typename T>
// struct X {
// template<typename U> friend void f(T, U);
// };
//
// X<int> x;
//
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
// We are instantiating the friend function template "f" within X<int>,
Improve the internal representation and semantic analysis of friend function templates. This commit ensures that friend function templates are constructed as FunctionTemplateDecls rather than partial FunctionDecls (as they previously were). It then implements template instantiation for friend function templates, injecting the friend function template only when no previous declaration exists at the time of instantiation. Oh, and make sure that explicit specialization declarations are not friends. llvm-svn: 83970
2009-10-13 22:39:41 +08:00
// which means substituting int for T, but leaving "f" as a friend function
// template.
// Build the function template itself.
Reapply r99596 with a fix: link an instantiated friend function to its pattern if it has a body. llvm-svn: 99610
2010-03-26 12:53:08 +08:00
FunctionTemplate = FunctionTemplateDecl::Create(SemaRef.Context, DC,
Improve the internal representation and semantic analysis of friend function templates. This commit ensures that friend function templates are constructed as FunctionTemplateDecls rather than partial FunctionDecls (as they previously were). It then implements template instantiation for friend function templates, injecting the friend function template only when no previous declaration exists at the time of instantiation. Oh, and make sure that explicit specialization declarations are not friends. llvm-svn: 83970
2009-10-13 22:39:41 +08:00
Function->getLocation(),
Function->getDeclName(),
TemplateParams, Function);
Function->setDescribedFunctionTemplate(FunctionTemplate);
Put function templates instantiated from friend declarations in the correct lexical context. This is required for ADL to work properly; fixes PR6716. llvm-svn: 99665
2010-03-27 07:10:15 +08:00
FunctionTemplate->setLexicalDeclContext(LexicalDC);
Reapply r99596 with a fix: link an instantiated friend function to its pattern if it has a body. llvm-svn: 99610
2010-03-26 12:53:08 +08:00
if (isFriend && D->isThisDeclarationADefinition()) {
FunctionTemplate->setInstantiatedFromMemberTemplate(
D->getDescribedFunctionTemplate());
}
If we attempt to add a constructor template specialization that looks like a copy constructor to the overload set, just ignore it. This ensures that we don't try to use such a constructor as a copy constructor *without* triggering diagnostics at the point of declaration. Note that we *do* diagnose such copy constructors when explicitly written by the user (e.g., as an explicit specialization). llvm-svn: 88733
2009-11-14 09:20:54 +08:00
} else if (FunctionTemplate) {
// Record this function template specialization.
ArrayRef'ize MultiLevelTemplateArgumentList::ArgList. Patch by Faisal Vali! llvm-svn: 181077
2013-05-04 07:46:09 +08:00
ArrayRef<TemplateArgument> Innermost = TemplateArgs.getInnermost();
Eliminate a bunch of unnecessary ASTContexts from members functions of Decl subclasses. No functionality change. llvm-svn: 95841
2010-02-11 09:19:42 +08:00
Function->setFunctionTemplateSpecialization(FunctionTemplate,
Remove broken support for variadic templates, along with the various abstractions (e.g., TemplateArgumentListBuilder) that were designed to support variadic templates. Only a few remnants of variadic templates remain, in the parser (parsing template type parameter packs), AST (template type parameter pack bits and TemplateArgument::Pack), and Sema; these are expected to be used in a future implementation of variadic templates. But don't get too excited about that happening now. llvm-svn: 118385
2010-11-08 07:05:16 +08:00
TemplateArgumentList::CreateCopy(SemaRef.Context,
[AST] Use ArrayRef in more interfaces ArrayRef is a little better than passing around a pointer/length pair. No functional change is intended. llvm-svn: 274475
2016-07-04 05:17:51 +08:00
Innermost),
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
/*InsertPos=*/nullptr);
Switch the template specialization kind for a non-defining declaration of a non-template function instantiated from a friend declaration in a class template from TSK_ImplicitInstantiation to TSK_Undeclared. It doesn't make sense for a non-template function to be flagged as being instantiated from a template; that property really belongs to the entity as a whole and not an individual declaration of it. There's some history here: * r137934 started marking these functions as instantiations in order to work around an issue where we might instantiate a class template while we're still parsing its member definitions, and would otherwise fail to instantiate the friend definition * r177003 fixed the same issue but for friend templates, but did so by making the friends claim to be definitions even before we'd parsed their actual bodies; this made the r137934 change redundant * r293558 worked around a problem caused by the marking of a non-template function as a template instantiation in r137934 This change reverts the code changes from r293358 and r137934 and retains all the tests. llvm-svn: 293367
2017-01-28 10:56:07 +08:00
} else if (isFriend && D->isThisDeclarationADefinition()) {
// Do not connect the friend to the template unless it's actually a
// definition. We don't want non-template functions to be marked as being
// template instantiations.
Reapply r99596 with a fix: link an instantiated friend function to its pattern if it has a body. llvm-svn: 99610
2010-03-26 12:53:08 +08:00
Function->setInstantiationOfMemberFunction(D, TSK_ImplicitInstantiation);
Omnibus friend decl refactoring. Instead of cloning AST classes for friend declarations of same, introduce a single AST class and add appropriate bits (encoded in the namespace) for whether a decl is "real" or not. Much hackery about previously-declared / not-previously-declared, but it's essentially mandated by the standard that friends alter lookup, and this is at least fairly non-intrusive. Refactor the Sema methods specific to friends for cleaner flow and less nesting. Incidentally solve a few bugs, but I remain confident that we can put them back. llvm-svn: 80353
2009-08-28 15:59:38 +08:00
}
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Improved semantic analysis and AST respresentation for function templates. For example, this now type-checks (but does not instantiate the body of deref<int>): template<typename T> T& deref(T* t) { return *t; } void test(int *ip) { int &ir = deref(ip); } Specific changes/additions: * Template argument deduction from a call to a function template. * Instantiation of a function template specializations (just the declarations) from the template arguments deduced from a call. * FunctionTemplateDecls are stored directly in declaration contexts and found via name lookup (all forms), rather than finding the FunctionDecl and then realizing it is a template. This is responsible for most of the churn, since some of the core declaration matching and lookup code assumes that all functions are FunctionDecls. llvm-svn: 74213
2009-06-26 06:08:12 +08:00
if (InitFunctionInstantiation(Function, D))
Function->setInvalidDecl();
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Implement dependent friend function template specializations. llvm-svn: 100753
2010-04-08 17:05:18 +08:00
bool isExplicitSpecialization = false;
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Switch the semantic DeclContext for a block-scope declaration of a function or variable from being the function to being the enclosing namespace scope (in C++) or the TU (in C). This allows us to fix a selection of related issues where we would build incorrect redeclaration chains for such declarations, and fail to notice type mismatches. Such declarations are put into a new IdentifierNamespace, IDNS_LocalExtern, which is only found when searching scopes, and not found when searching DeclContexts. Such a declaration is only made visible in its DeclContext if there are no non-LocalExtern declarations. llvm-svn: 191064
2013-09-20 09:15:31 +08:00
LookupResult Previous(
SemaRef, Function->getDeclName(), SourceLocation(),
D->isLocalExternDecl() ? Sema::LookupRedeclarationWithLinkage
: Sema::LookupOrdinaryName,
Sema::ForRedeclaration);
Overhaul previous-declaration and overload checking to work on lookup results rather than NamedDecl*. This is a major step towards eliminating OverloadedFunctionDecl. llvm-svn: 89263
2009-11-19 06:49:29 +08:00
Implement dependent friend function template specializations. llvm-svn: 100753
2010-04-08 17:05:18 +08:00
if (DependentFunctionTemplateSpecializationInfo *Info
= D->getDependentSpecializationInfo()) {
assert(isFriend && "non-friend has dependent specialization info?");
// This needs to be set now for future sanity.
Reinstate r186040, with additional fixes and more test coverage (reverted in r186331). Original commit log: If we friend a declaration twice, that should not make it visible to name lookup in the surrounding context. Slightly rework how we handle friend declarations to inherit the visibility of the prior declaration, rather than setting a friend declaration to be visible whenever there was a prior declaration. llvm-svn: 186546
2013-07-18 07:53:16 +08:00
Function->setObjectOfFriendDecl();
Implement dependent friend function template specializations. llvm-svn: 100753
2010-04-08 17:05:18 +08:00
// Instantiate the explicit template arguments.
TemplateArgumentListInfo ExplicitArgs(Info->getLAngleLoc(),
Info->getRAngleLoc());
Implement template argument deduction for pack expansions whose pattern is a template argument, which involves repeatedly deducing template arguments using the pattern of the pack expansion, then bundling the resulting deductions into an argument pack. We can now handle a variety of simple list-handling metaprograms using variadic templates. See, e.g., the new "count" metaprogram. llvm-svn: 122439
2010-12-23 05:19:48 +08:00
if (SemaRef.Subst(Info->getTemplateArgs(), Info->getNumTemplateArgs(),
ExplicitArgs, TemplateArgs))
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Implement dependent friend function template specializations. llvm-svn: 100753
2010-04-08 17:05:18 +08:00
// Map the candidate templates to their instantiations.
for (unsigned I = 0, E = Info->getNumTemplates(); I != E; ++I) {
Decl *Temp = SemaRef.FindInstantiatedDecl(D->getLocation(),
Info->getTemplate(I),
TemplateArgs);
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
if (!Temp) return nullptr;
Implement dependent friend function template specializations. llvm-svn: 100753
2010-04-08 17:05:18 +08:00
Previous.addDecl(cast<FunctionTemplateDecl>(Temp));
}
if (SemaRef.CheckFunctionTemplateSpecialization(Function,
&ExplicitArgs,
Previous))
Function->setInvalidDecl();
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Implement dependent friend function template specializations. llvm-svn: 100753
2010-04-08 17:05:18 +08:00
isExplicitSpecialization = true;
} else if (TemplateParams || !FunctionTemplate) {
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
// Look only into the namespace where the friend would be declared to
// find a previous declaration. This is the innermost enclosing namespace,
Improve the internal representation and semantic analysis of friend function templates. This commit ensures that friend function templates are constructed as FunctionTemplateDecls rather than partial FunctionDecls (as they previously were). It then implements template instantiation for friend function templates, injecting the friend function template only when no previous declaration exists at the time of instantiation. Oh, and make sure that explicit specialization declarations are not friends. llvm-svn: 83970
2009-10-13 22:39:41 +08:00
// as described in ActOnFriendFunctionDecl.
Overhaul previous-declaration and overload checking to work on lookup results rather than NamedDecl*. This is a major step towards eliminating OverloadedFunctionDecl. llvm-svn: 89263
2009-11-19 06:49:29 +08:00
SemaRef.LookupQualifiedName(Previous, DC);
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Improve the internal representation and semantic analysis of friend function templates. This commit ensures that friend function templates are constructed as FunctionTemplateDecls rather than partial FunctionDecls (as they previously were). It then implements template instantiation for friend function templates, injecting the friend function template only when no previous declaration exists at the time of instantiation. Oh, and make sure that explicit specialization declarations are not friends. llvm-svn: 83970
2009-10-13 22:39:41 +08:00
// In C++, the previous declaration we find might be a tag type
// (class or enum). In this case, the new declaration will hide the
// tag type. Note that this does does not apply if we're declaring a
// typedef (C++ [dcl.typedef]p4).
Overhaul previous-declaration and overload checking to work on lookup results rather than NamedDecl*. This is a major step towards eliminating OverloadedFunctionDecl. llvm-svn: 89263
2009-11-19 06:49:29 +08:00
if (Previous.isSingleTagDecl())
Previous.clear();
Improve the internal representation and semantic analysis of friend function templates. This commit ensures that friend function templates are constructed as FunctionTemplateDecls rather than partial FunctionDecls (as they previously were). It then implements template instantiation for friend function templates, injecting the friend function template only when no previous declaration exists at the time of instantiation. Oh, and make sure that explicit specialization declarations are not friends. llvm-svn: 83970
2009-10-13 22:39:41 +08:00
}
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Function with unparsed body is a definition While a function body is being parsed, the function declaration is not considered as a definition because it does not have a body yet. In some cases it leads to incorrect interpretation, the case is presented in https://bugs.llvm.org/show_bug.cgi?id=14785: ``` template<typename T> struct Somewhat { void internal() const {} friend void operator+(int const &, Somewhat<T> const &) {} }; void operator+(int const &, Somewhat<char> const &x) { x.internal(); } ``` When statement `x.internal()` in the body of global `operator+` is parsed, the type of `x` must be completed, so the instantiation of `Somewhat<char>` is started. It instantiates the declaration of `operator+` defined inline, and makes a check for redefinition. The check does not detect another definition because the declaration of `operator+` is still not defining as does not have a body yet. To solves this problem the function `isThisDeclarationADefinition` considers a function declaration as a definition if it has flag `WillHaveBody` set. This change fixes PR14785. Differential Revision: https://reviews.llvm.org/D30375 llvm-svn: 305379
2017-06-14 18:07:02 +08:00
if (isFriend) {
Function->setObjectOfFriendDecl();
if (FunctionTemplate)
FunctionTemplate->setObjectOfFriendDecl();
}
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
SemaRef.CheckFunctionDeclaration(/*Scope*/ nullptr, Function, Previous,
Move some bool flags out of function parameter lists. llvm-svn: 141610
2011-10-11 08:28:45 +08:00
isExplicitSpecialization);
Improved semantic analysis and AST respresentation for function templates. For example, this now type-checks (but does not instantiate the body of deref<int>): template<typename T> T& deref(T* t) { return *t; } void test(int *ip) { int &ir = deref(ip); } Specific changes/additions: * Template argument deduction from a call to a function template. * Instantiation of a function template specializations (just the declarations) from the template arguments deduced from a call. * FunctionTemplateDecls are stored directly in declaration contexts and found via name lookup (all forms), rather than finding the FunctionDecl and then realizing it is a template. This is responsible for most of the churn, since some of the core declaration matching and lookup code assumes that all functions are FunctionDecls. llvm-svn: 74213
2009-06-26 06:08:12 +08:00
Recommit r102215, this time being more careful to only set the "principal declaration" (i.e. the only which will actually be looked up) to have the non-member-operator bit. llvm-svn: 102231
2010-04-24 09:30:58 +08:00
NamedDecl *PrincipalDecl = (TemplateParams
? cast<NamedDecl>(FunctionTemplate)
: Function);
Improve the internal representation and semantic analysis of friend function templates. This commit ensures that friend function templates are constructed as FunctionTemplateDecls rather than partial FunctionDecls (as they previously were). It then implements template instantiation for friend function templates, injecting the friend function template only when no previous declaration exists at the time of instantiation. Oh, and make sure that explicit specialization declarations are not friends. llvm-svn: 83970
2009-10-13 22:39:41 +08:00
// If the original function was part of a friend declaration,
// inherit its namespace state and add it to the owner.
Reapply r99596 with a fix: link an instantiated friend function to its pattern if it has a body. llvm-svn: 99610
2010-03-26 12:53:08 +08:00
if (isFriend) {
Fix PR10447: lazily building name lookup tables for DeclContexts was broken. The deferred lookup table building step couldn't accurately tell which Decls should be included in the lookup table, and consequently built different tables in some cases. Fix this by removing lazy building of DeclContext name lookup tables. In practice, the laziness was frequently not worthwhile in C++, because we performed lookup into most DeclContexts. In C, it had a bit more value, since there is no qualified lookup. In the place of lazy lookup table building, we simply don't build lookup tables for function DeclContexts at all. Such name lookup tables are not useful, since they don't capture the scoping information required to correctly perform name lookup in a function scope. The resulting performance delta is within the noise on my testing, but appears to be a very slight win for C++ and a very slight loss for C. The C performance can probably be recovered (if it is a measurable problem) by avoiding building the lookup table for the translation unit. llvm-svn: 152608
2012-03-13 11:12:56 +08:00
DC->makeDeclVisibleInContext(PrincipalDecl);
fix dual aspect of PR8007, namely when the friend function prototype is already used at the point of the template definition that is supposed to inject the friend function. Testcase verifies four scenarios. I would like receive some code review for this. llvm-svn: 112524
2010-08-31 05:10:05 +08:00
Implement DR329. We already did the right thing here in C++98 mode, but r104014 (which implemented the DR) was disabled in C++11. llvm-svn: 200673
2014-02-03 10:37:59 +08:00
bool QueuedInstantiation = false;
fix dual aspect of PR8007, namely when the friend function prototype is already used at the point of the template definition that is supposed to inject the friend function. Testcase verifies four scenarios. I would like receive some code review for this. llvm-svn: 112524
2010-08-31 05:10:05 +08:00
Implement DR329. We already did the right thing here in C++98 mode, but r104014 (which implemented the DR) was disabled in C++11. llvm-svn: 200673
2014-02-03 10:37:59 +08:00
// C++11 [temp.friend]p4 (DR329):
// When a function is defined in a friend function declaration in a class
// template, the function is instantiated when the function is odr-used.
// The same restrictions on multiple declarations and definitions that
// apply to non-template function declarations and definitions also apply
// to these implicit definitions.
if (D->isThisDeclarationADefinition()) {
I hate this commit. Revert much of the implementation of C++98/03 [temp.friend]p5 in r103943 and its follow-ons r103948 and r103952. While our implementation was technically correct, other compilers don't seem to implement this paragraph (which forces the instantiation of friend functions defined in a class template when a class template specialization is instantiated), and doing so broke a bunch of Boost libraries. Since this behavior has changed in C++0x (which instantiates the friend function definitions when they are used), we're going to skip the nowhere-implemented C++98/03 semantics and go straight to the C++0x semantics. This commit is a band-aid to get Boost up and running again. It doesn't really fix PR6952 (which this commit un-fixes), but it does deal with the way Boost.Units abuses this particular paragraph. llvm-svn: 104014
2010-05-18 13:45:02 +08:00
// Check for a function body.
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
const FunctionDecl *Definition = nullptr;
Modify some deleted function methods to better reflect reality: - New isDefined() function checks for deletedness - isThisDeclarationADefinition checks for deletedness - New doesThisDeclarationHaveABody() does what isThisDeclarationADefinition() used to do - The IsDeleted bit is not propagated across redeclarations - isDeleted() now checks the canoncial declaration - New isDeletedAsWritten() does what it says on the tin. - isUserProvided() now correct (thanks Richard!) This fixes the bug that we weren't catching void foo() = delete; void foo() {} as being a redefinition. llvm-svn: 131013
2011-05-07 04:44:56 +08:00
if (Function->isDefined(Definition) &&
I hate this commit. Revert much of the implementation of C++98/03 [temp.friend]p5 in r103943 and its follow-ons r103948 and r103952. While our implementation was technically correct, other compilers don't seem to implement this paragraph (which forces the instantiation of friend functions defined in a class template when a class template specialization is instantiated), and doing so broke a bunch of Boost libraries. Since this behavior has changed in C++0x (which instantiates the friend function definitions when they are used), we're going to skip the nowhere-implemented C++98/03 semantics and go straight to the C++0x semantics. This commit is a band-aid to get Boost up and running again. It doesn't really fix PR6952 (which this commit un-fixes), but it does deal with the way Boost.Units abuses this particular paragraph. llvm-svn: 104014
2010-05-18 13:45:02 +08:00
Definition->getTemplateSpecializationKind() == TSK_Undeclared) {
Implement DR329. We already did the right thing here in C++98 mode, but r104014 (which implemented the DR) was disabled in C++11. llvm-svn: 200673
2014-02-03 10:37:59 +08:00
SemaRef.Diag(Function->getLocation(), diag::err_redefinition)
<< Function->getDeclName();
I hate this commit. Revert much of the implementation of C++98/03 [temp.friend]p5 in r103943 and its follow-ons r103948 and r103952. While our implementation was technically correct, other compilers don't seem to implement this paragraph (which forces the instantiation of friend functions defined in a class template when a class template specialization is instantiated), and doing so broke a bunch of Boost libraries. Since this behavior has changed in C++0x (which instantiates the friend function definitions when they are used), we're going to skip the nowhere-implemented C++98/03 semantics and go straight to the C++0x semantics. This commit is a band-aid to get Boost up and running again. It doesn't really fix PR6952 (which this commit un-fixes), but it does deal with the way Boost.Units abuses this particular paragraph. llvm-svn: 104014
2010-05-18 13:45:02 +08:00
SemaRef.Diag(Definition->getLocation(), diag::note_previous_definition);
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
}
I hate this commit. Revert much of the implementation of C++98/03 [temp.friend]p5 in r103943 and its follow-ons r103948 and r103952. While our implementation was technically correct, other compilers don't seem to implement this paragraph (which forces the instantiation of friend functions defined in a class template when a class template specialization is instantiated), and doing so broke a bunch of Boost libraries. Since this behavior has changed in C++0x (which instantiates the friend function definitions when they are used), we're going to skip the nowhere-implemented C++98/03 semantics and go straight to the C++0x semantics. This commit is a band-aid to get Boost up and running again. It doesn't really fix PR6952 (which this commit un-fixes), but it does deal with the way Boost.Units abuses this particular paragraph. llvm-svn: 104014
2010-05-18 13:45:02 +08:00
// Check for redefinitions due to other instantiations of this or
// a similar friend function.
[C++11] Replacing iterators redecls_begin() and redecls_end() with iterator_range redecls(). Updating all of the usages of the iterators with range-based for loops, which allows the begin/end forms to be removed entirely. llvm-svn: 203179
2014-03-07 07:45:36 +08:00
else for (auto R : Function->redecls()) {
if (R == Function)
simplify llvm-svn: 112372
2010-08-28 23:42:30 +08:00
continue;
Implement DR329. We already did the right thing here in C++98 mode, but r104014 (which implemented the DR) was disabled in C++11. llvm-svn: 200673
2014-02-03 10:37:59 +08:00
// If some prior declaration of this function has been used, we need
// to instantiate its definition.
if (!QueuedInstantiation && R->isUsed(false)) {
if (MemberSpecializationInfo *MSInfo =
Function->getMemberSpecializationInfo()) {
if (MSInfo->getPointOfInstantiation().isInvalid()) {
SourceLocation Loc = R->getLocation(); // FIXME
MSInfo->setPointOfInstantiation(Loc);
SemaRef.PendingLocalImplicitInstantiations.push_back(
std::make_pair(Function, Loc));
QueuedInstantiation = true;
fix dual aspect of PR8007, namely when the friend function prototype is already used at the point of the template definition that is supposed to inject the friend function. Testcase verifies four scenarios. I would like receive some code review for this. llvm-svn: 112524
2010-08-31 05:10:05 +08:00
}
}
Implement DR329. We already did the right thing here in C++98 mode, but r104014 (which implemented the DR) was disabled in C++11. llvm-svn: 200673
2014-02-03 10:37:59 +08:00
}
// If some prior declaration of this function was a friend with an
// uninstantiated definition, reject it.
if (R->getFriendObjectKind()) {
if (const FunctionDecl *RPattern =
R->getTemplateInstantiationPattern()) {
Modify some deleted function methods to better reflect reality: - New isDefined() function checks for deletedness - isThisDeclarationADefinition checks for deletedness - New doesThisDeclarationHaveABody() does what isThisDeclarationADefinition() used to do - The IsDeleted bit is not propagated across redeclarations - isDeleted() now checks the canoncial declaration - New isDeletedAsWritten() does what it says on the tin. - isUserProvided() now correct (thanks Richard!) This fixes the bug that we weren't catching void foo() = delete; void foo() {} as being a redefinition. llvm-svn: 131013
2011-05-07 04:44:56 +08:00
if (RPattern->isDefined(RPattern)) {
Implement DR329. We already did the right thing here in C++98 mode, but r104014 (which implemented the DR) was disabled in C++11. llvm-svn: 200673
2014-02-03 10:37:59 +08:00
SemaRef.Diag(Function->getLocation(), diag::err_redefinition)
I hate this commit. Revert much of the implementation of C++98/03 [temp.friend]p5 in r103943 and its follow-ons r103948 and r103952. While our implementation was technically correct, other compilers don't seem to implement this paragraph (which forces the instantiation of friend functions defined in a class template when a class template specialization is instantiated), and doing so broke a bunch of Boost libraries. Since this behavior has changed in C++0x (which instantiates the friend function definitions when they are used), we're going to skip the nowhere-implemented C++98/03 semantics and go straight to the C++0x semantics. This commit is a band-aid to get Boost up and running again. It doesn't really fix PR6952 (which this commit un-fixes), but it does deal with the way Boost.Units abuses this particular paragraph. llvm-svn: 104014
2010-05-18 13:45:02 +08:00
<< Function->getDeclName();
simplify by relying on cascading operator-> llvm-svn: 112373
2010-08-28 23:46:56 +08:00
SemaRef.Diag(R->getLocation(), diag::note_previous_definition);
I hate this commit. Revert much of the implementation of C++98/03 [temp.friend]p5 in r103943 and its follow-ons r103948 and r103952. While our implementation was technically correct, other compilers don't seem to implement this paragraph (which forces the instantiation of friend functions defined in a class template when a class template specialization is instantiated), and doing so broke a bunch of Boost libraries. Since this behavior has changed in C++0x (which instantiates the friend function definitions when they are used), we're going to skip the nowhere-implemented C++98/03 semantics and go straight to the C++0x semantics. This commit is a band-aid to get Boost up and running again. It doesn't really fix PR6952 (which this commit un-fixes), but it does deal with the way Boost.Units abuses this particular paragraph. llvm-svn: 104014
2010-05-18 13:45:02 +08:00
break;
}
Implement DR329. We already did the right thing here in C++98 mode, but r104014 (which implemented the DR) was disabled in C++11. llvm-svn: 200673
2014-02-03 10:37:59 +08:00
}
I hate this commit. Revert much of the implementation of C++98/03 [temp.friend]p5 in r103943 and its follow-ons r103948 and r103952. While our implementation was technically correct, other compilers don't seem to implement this paragraph (which forces the instantiation of friend functions defined in a class template when a class template specialization is instantiated), and doing so broke a bunch of Boost libraries. Since this behavior has changed in C++0x (which instantiates the friend function definitions when they are used), we're going to skip the nowhere-implemented C++98/03 semantics and go straight to the C++0x semantics. This commit is a band-aid to get Boost up and running again. It doesn't really fix PR6952 (which this commit un-fixes), but it does deal with the way Boost.Units abuses this particular paragraph. llvm-svn: 104014
2010-05-18 13:45:02 +08:00
}
}
}
When instantiating a friend function template, don't forget to inherit default template arguments from other declarations. llvm-svn: 302603
2017-05-10 08:01:13 +08:00
// Check the template parameter list against the previous declaration. The
// goal here is to pick up default arguments added since the friend was
// declared; we know the template parameter lists match, since otherwise
// we would not have picked this template as the previous declaration.
if (TemplateParams && FunctionTemplate->getPreviousDecl()) {
SemaRef.CheckTemplateParameterList(
TemplateParams,
FunctionTemplate->getPreviousDecl()->getTemplateParameters(),
Function->isThisDeclarationADefinition()
? Sema::TPC_FriendFunctionTemplateDefinition
: Sema::TPC_FriendFunctionTemplate);
}
Improve the internal representation and semantic analysis of friend function templates. This commit ensures that friend function templates are constructed as FunctionTemplateDecls rather than partial FunctionDecls (as they previously were). It then implements template instantiation for friend function templates, injecting the friend function template only when no previous declaration exists at the time of instantiation. Oh, and make sure that explicit specialization declarations are not friends. llvm-svn: 83970
2009-10-13 22:39:41 +08:00
}
Switch the semantic DeclContext for a block-scope declaration of a function or variable from being the function to being the enclosing namespace scope (in C++) or the TU (in C). This allows us to fix a selection of related issues where we would build incorrect redeclaration chains for such declarations, and fail to notice type mismatches. Such declarations are put into a new IdentifierNamespace, IDNS_LocalExtern, which is only found when searching scopes, and not found when searching DeclContexts. Such a declaration is only made visible in its DeclContext if there are no non-LocalExtern declarations. llvm-svn: 191064
2013-09-20 09:15:31 +08:00
if (Function->isLocalExternDecl() && !Function->getPreviousDecl())
DC->makeDeclVisibleInContext(PrincipalDecl);
Recommit r102215, this time being more careful to only set the "principal declaration" (i.e. the only which will actually be looked up) to have the non-member-operator bit. llvm-svn: 102231
2010-04-24 09:30:58 +08:00
if (Function->isOverloadedOperator() && !DC->isRecord() &&
PrincipalDecl->isInIdentifierNamespace(Decl::IDNS_Ordinary))
PrincipalDecl->setNonMemberOperator();
Correctly propagate defaultedness across template instantiation. This fixes PR9965, but we're not out of the water yet, as we do not successfully handle out-of-line definitions, due to my utter misunderstanding of how we manage templates. llvm-svn: 131920
2011-05-24 05:07:59 +08:00
assert(!D->isDefaulted() && "only methods should be defaulted");
Improved semantic analysis and AST respresentation for function templates. For example, this now type-checks (but does not instantiate the body of deref<int>): template<typename T> T& deref(T* t) { return *t; } void test(int *ip) { int &ir = deref(ip); } Specific changes/additions: * Template argument deduction from a call to a function template. * Instantiation of a function template specializations (just the declarations) from the template arguments deduced from a call. * FunctionTemplateDecls are stored directly in declaration contexts and found via name lookup (all forms), rather than finding the FunctionDecl and then realizing it is a template. This is responsible for most of the churn, since some of the core declaration matching and lookup code assumes that all functions are FunctionDecls. llvm-svn: 74213
2009-06-26 06:08:12 +08:00
return Function;
}
Template instantiation for the declarations of member functions within a class template. At present, we can only instantiation normal methods, but not constructors, destructors, or conversion operators. As ever, this contains a bit of refactoring in Sema's type-checking. In particular: - Split ActOnFunctionDeclarator into ActOnFunctionDeclarator (handling the declarator itself) and CheckFunctionDeclaration (checking for the the function declaration), the latter of which is also used by template instantiation. - We were performing the adjustment of function parameter types in three places; collect those into a single new routine. - When the type of a parameter is adjusted, allocate an OriginalParmVarDecl to keep track of the type as it was written. - Eliminate a redundant check for out-of-line declarations of member functions; hide more C++-specific checks on function declarations behind if(getLangOptions().CPlusPlus). llvm-svn: 67575
2009-03-24 07:06:20 +08:00
Implement instantiation of the declarations of member function templates within class templates, producing a member function template of a class template specialization. If you can parse that, I'm sorry. Example: template<typename T> struct X { template<typename U> void f(T, U); }; When we instantiate X<int>, we now instantiate the declaration X<int>::f, which looks like this: template<typename U> void X<int>::f(int, U); The path this takes through TemplateDeclInstantiator::VisitCXXMethodDecl is convoluted and ugly, but I don't know how to improve it yet. I'm resting my hopes on the multi-level substitution required to instantiate definitions of nested templates, which may simplify this code as well. More testing to come... llvm-svn: 80252
2009-08-28 00:57:43 +08:00
Decl *
TemplateDeclInstantiator::VisitCXXMethodDecl(CXXMethodDecl *D,
Implement function template specialization at class scope extension in Microsoft mode. A new AST node is introduced: ClassScopeFunctionSpecialization. This node holds a FunctionDecl that is not yet specialized; then during the class template instantiation the ClassScopeFunctionSpecialization will spawn the actual function specialization. Example: template <class T> class A { public: template <class U> void f(U p) { } template <> void f(int p) { } // <== class scope specialization }; This extension is necessary to parse MSVC standard C++ headers, MFC and ATL code. BTW, with this feature in, clang can parse (-fsyntax-only) all the MSVC 2010 standard header files without any error. llvm-svn: 137573
2011-08-14 11:52:19 +08:00
TemplateParameterList *TemplateParams,
bool IsClassScopeSpecialization) {
Implement support for calling member function templates, which involves: - Allowing one to name a member function template within a class template and on the right-hand side of a member access expression. - Template argument deduction for calls to member function templates. - Registering specializations of member function templates (and finding them later). llvm-svn: 79581
2009-08-21 08:16:32 +08:00
FunctionTemplateDecl *FunctionTemplate = D->getDescribedFunctionTemplate();
Implement instantiation of the declarations of member function templates within class templates, producing a member function template of a class template specialization. If you can parse that, I'm sorry. Example: template<typename T> struct X { template<typename U> void f(T, U); }; When we instantiate X<int>, we now instantiate the declaration X<int>::f, which looks like this: template<typename U> void X<int>::f(int, U); The path this takes through TemplateDeclInstantiator::VisitCXXMethodDecl is convoluted and ugly, but I don't know how to improve it yet. I'm resting my hopes on the multi-level substitution required to instantiate definitions of nested templates, which may simplify this code as well. More testing to come... llvm-svn: 80252
2009-08-28 00:57:43 +08:00
if (FunctionTemplate && !TemplateParams) {
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
// We are creating a function template specialization from a function
// template. Check whether there is already a function template
Implement instantiation of the declarations of member function templates within class templates, producing a member function template of a class template specialization. If you can parse that, I'm sorry. Example: template<typename T> struct X { template<typename U> void f(T, U); }; When we instantiate X<int>, we now instantiate the declaration X<int>::f, which looks like this: template<typename U> void X<int>::f(int, U); The path this takes through TemplateDeclInstantiator::VisitCXXMethodDecl is convoluted and ugly, but I don't know how to improve it yet. I'm resting my hopes on the multi-level substitution required to instantiate definitions of nested templates, which may simplify this code as well. More testing to come... llvm-svn: 80252
2009-08-28 00:57:43 +08:00
// specialization for this particular set of template arguments.
ArrayRef'ize MultiLevelTemplateArgumentList::ArgList. Patch by Faisal Vali! llvm-svn: 181077
2013-05-04 07:46:09 +08:00
ArrayRef<TemplateArgument> Innermost = TemplateArgs.getInnermost();
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
void *InsertPos = nullptr;
Hide FunctionTemplateDecl's specializations folding set as implementation detail and introduce FunctionTemplateDecl::findSpecialization. Redeclarations of specializations will not cause the previous decl to be removed from the set, the set will keep the canonical decl. findSpecialization will return the most recent redeclaration. llvm-svn: 108834
2010-07-20 21:59:58 +08:00
FunctionDecl *SpecFunc
Convert some function arguments to use ArrayRef. llvm-svn: 211764
2014-06-26 12:58:53 +08:00
= FunctionTemplate->findSpecialization(Innermost, InsertPos);
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Implement support for calling member function templates, which involves: - Allowing one to name a member function template within a class template and on the right-hand side of a member access expression. - Template argument deduction for calls to member function templates. - Registering specializations of member function templates (and finding them later). llvm-svn: 79581
2009-08-21 08:16:32 +08:00
// If we already have a function template specialization, return it.
Hide FunctionTemplateDecl's specializations folding set as implementation detail and introduce FunctionTemplateDecl::findSpecialization. Redeclarations of specializations will not cause the previous decl to be removed from the set, the set will keep the canonical decl. findSpecialization will return the most recent redeclaration. llvm-svn: 108834
2010-07-20 21:59:58 +08:00
if (SpecFunc)
return SpecFunc;
Implement support for calling member function templates, which involves: - Allowing one to name a member function template within a class template and on the right-hand side of a member access expression. - Template argument deduction for calls to member function templates. - Registering specializations of member function templates (and finding them later). llvm-svn: 79581
2009-08-21 08:16:32 +08:00
}
Implement method friends in class templates and fix a few related problems. llvm-svn: 99708
2010-03-27 13:57:59 +08:00
bool isFriend;
if (FunctionTemplate)
isFriend = (FunctionTemplate->getFriendObjectKind() != Decl::FOK_None);
else
isFriend = (D->getFriendObjectKind() != Decl::FOK_None);
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
bool MergeWithParentScope = (TemplateParams != nullptr) ||
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
!(isa<Decl>(Owner) &&
When we are instantiating a member function of a local class, be sure to merge the local instantiation scope with the outer local instantiation scope, so that we can instantiate declarations from the function owning the local class. Fixes an assert while instantiating Boost.MPL's BOOST_MPL_ASSERT_MSG. llvm-svn: 93651
2010-01-17 04:21:20 +08:00
cast<Decl>(Owner)->isDefinedOutsideFunctionOrMethod());
Move more stuff out of Sema.h. llvm-svn: 112026
2010-08-25 13:32:35 +08:00
LocalInstantiationScope Scope(SemaRef, MergeWithParentScope);
Introduce a stack of instantiation scopes that are used to store the mapping from variable declarations that occur within templates to their instantiated counterparts llvm-svn: 71799
2009-05-15 05:44:34 +08:00
Instantiate enclosing template parameter lists when instantiating friends. llvm-svn: 116789
2010-10-19 10:26:41 +08:00
// Instantiate enclosing template arguments for friends.
remove unneeded llvm:: namespace qualifiers on some core types now that LLVM.h imports them into the clang namespace. llvm-svn: 135852
2011-07-23 18:55:15 +08:00
SmallVector<TemplateParameterList *, 4> TempParamLists;
Instantiate enclosing template parameter lists when instantiating friends. llvm-svn: 116789
2010-10-19 10:26:41 +08:00
unsigned NumTempParamLists = 0;
if (isFriend && (NumTempParamLists = D->getNumTemplateParameterLists())) {
[Sema] Allocate SmallVector to the right size. SmallVector::set_size does not reallocate the vector. Sadly I have no idea how to test this. The vector never has more than one member in all of the regression tests. Found by inspection. llvm-svn: 243987
2015-08-04 22:46:06 +08:00
TempParamLists.resize(NumTempParamLists);
Instantiate enclosing template parameter lists when instantiating friends. llvm-svn: 116789
2010-10-19 10:26:41 +08:00
for (unsigned I = 0; I != NumTempParamLists; ++I) {
TemplateParameterList *TempParams = D->getTemplateParameterList(I);
TemplateParameterList *InstParams = SubstTemplateParams(TempParams);
if (!InstParams)
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Instantiate enclosing template parameter lists when instantiating friends. llvm-svn: 116789
2010-10-19 10:26:41 +08:00
TempParamLists[I] = InstParams;
}
}
remove unneeded llvm:: namespace qualifiers on some core types now that LLVM.h imports them into the clang namespace. llvm-svn: 135852
2011-07-23 18:55:15 +08:00
SmallVector<ParmVarDecl *, 4> Params;
Remove unused variables. Found by clang's own static analyzer. llvm-svn: 148542
2012-01-20 22:42:32 +08:00
TypeSourceInfo *TInfo = SubstFunctionType(D, Params);
Maintain type source information for functions through template instantiation. Based on a patch by Enea Zaffanella! I found a way to reduce some of the redundancy between TreeTransform's "standard" FunctionProtoType transformation and TemplateInstantiator's override, and I killed off the old SubstFunctionType by adding type source info for the last cases where we were creating FunctionDecls without TSI (at least that get passed through template instantiation). llvm-svn: 98252
2010-03-11 17:03:00 +08:00
if (!TInfo)
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
When we substitute into the type of a function based on the TypeSourceInfo, we may have lost some adjustments made to the type of that function due to declaration merging. Adjust the resulting type correspondingly. Fixes PR12948 / <rdar://problem/11552434>. llvm-svn: 163845
2012-09-14 05:56:43 +08:00
QualType T = adjustFunctionTypeForInstantiation(SemaRef.Context, D, TInfo);
Template instantiation for the declarations of member functions within a class template. At present, we can only instantiation normal methods, but not constructors, destructors, or conversion operators. As ever, this contains a bit of refactoring in Sema's type-checking. In particular: - Split ActOnFunctionDeclarator into ActOnFunctionDeclarator (handling the declarator itself) and CheckFunctionDeclaration (checking for the the function declaration), the latter of which is also used by template instantiation. - We were performing the adjustment of function parameter types in three places; collect those into a single new routine. - When the type of a parameter is adjusted, allocate an OriginalParmVarDecl to keep track of the type as it was written. - Eliminate a redundant check for out-of-line declarations of member functions; hide more C++-specific checks on function declarations behind if(getLangOptions().CPlusPlus). llvm-svn: 67575
2009-03-24 07:06:20 +08:00
Use NestedNameSpecifierLoc within out-of-line variables, function, and tag definitions. Also, add support for template instantiation of NestedNameSpecifierLocs. llvm-svn: 126470
2011-02-25 10:25:35 +08:00
NestedNameSpecifierLoc QualifierLoc = D->getQualifierLoc();
if (QualifierLoc) {
QualifierLoc = SemaRef.SubstNestedNameSpecifierLoc(QualifierLoc,
Implement method friends in class templates and fix a few related problems. llvm-svn: 99708
2010-03-27 13:57:59 +08:00
TemplateArgs);
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
if (!QualifierLoc)
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Implement method friends in class templates and fix a few related problems. llvm-svn: 99708
2010-03-27 13:57:59 +08:00
}
DeclContext *DC = Owner;
if (isFriend) {
Use NestedNameSpecifierLoc within out-of-line variables, function, and tag definitions. Also, add support for template instantiation of NestedNameSpecifierLocs. llvm-svn: 126470
2011-02-25 10:25:35 +08:00
if (QualifierLoc) {
Implement method friends in class templates and fix a few related problems. llvm-svn: 99708
2010-03-27 13:57:59 +08:00
CXXScopeSpec SS;
Use NestedNameSpecifierLoc within out-of-line variables, function, and tag definitions. Also, add support for template instantiation of NestedNameSpecifierLocs. llvm-svn: 126470
2011-02-25 10:25:35 +08:00
SS.Adopt(QualifierLoc);
Implement method friends in class templates and fix a few related problems. llvm-svn: 99708
2010-03-27 13:57:59 +08:00
DC = SemaRef.computeDeclContext(SS);
When instantiating a dependently-scoped friend function declaration, we may need to complete the type before looking into it. llvm-svn: 116795
2010-10-19 13:01:53 +08:00
if (DC && SemaRef.RequireCompleteDeclContext(SS, DC))
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Implement method friends in class templates and fix a few related problems. llvm-svn: 99708
2010-03-27 13:57:59 +08:00
} else {
DC = SemaRef.FindInstantiatedContext(D->getLocation(),
D->getDeclContext(),
TemplateArgs);
}
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
if (!DC) return nullptr;
Implement method friends in class templates and fix a few related problems. llvm-svn: 99708
2010-03-27 13:57:59 +08:00
}
Template instantiation for the declarations of member functions within a class template. At present, we can only instantiation normal methods, but not constructors, destructors, or conversion operators. As ever, this contains a bit of refactoring in Sema's type-checking. In particular: - Split ActOnFunctionDeclarator into ActOnFunctionDeclarator (handling the declarator itself) and CheckFunctionDeclaration (checking for the the function declaration), the latter of which is also used by template instantiation. - We were performing the adjustment of function parameter types in three places; collect those into a single new routine. - When the type of a parameter is adjusted, allocate an OriginalParmVarDecl to keep track of the type as it was written. - Eliminate a redundant check for out-of-line declarations of member functions; hide more C++-specific checks on function declarations behind if(getLangOptions().CPlusPlus). llvm-svn: 67575
2009-03-24 07:06:20 +08:00
// Build the instantiated method declaration.
Implement method friends in class templates and fix a few related problems. llvm-svn: 99708
2010-03-27 13:57:59 +08:00
CXXRecordDecl *Record = cast<CXXRecordDecl>(DC);
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
CXXMethodDecl *Method = nullptr;
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Fixed source range for all DeclaratorDecl's. llvm-svn: 127225
2011-03-08 16:55:46 +08:00
SourceLocation StartLoc = D->getInnerLocStart();
Added locations and type source info for DeclarationName. llvm-svn: 110860
2010-08-12 06:01:17 +08:00
DeclarationNameInfo NameInfo
= SemaRef.SubstDeclarationNameInfo(D->getNameInfo(), TemplateArgs);
Refactor instantiation of destructors to use the common CXXMethodDecl code, fixing a problem where instantiations of out-of-line destructor definitions would had the wrong lexical context. Introduce tests for out-of-line definitions of the constructors, destructors, and conversion functions of a class template partial specialization. llvm-svn: 79682
2009-08-22 06:43:28 +08:00
if (CXXConstructorDecl *Constructor = dyn_cast<CXXConstructorDecl>(D)) {
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Method = CXXConstructorDecl::Create(SemaRef.Context, Record,
Fixed source range for all DeclaratorDecl's. llvm-svn: 127225
2011-03-08 16:55:46 +08:00
StartLoc, NameInfo, T, TInfo,
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Constructor->isExplicit(),
Revert "Mark instantiated function decls as inline specified if any pattern is" It breaks down on this test case: void foo(); template <typename T> class C { friend void foo(); }; inline void foo() {} C<int> c; We shouldn't be marking the instantiation of the friend decl of foo as inline-specified. It may be possible to fix this by determining if the full definition is part of the current template, but it seems better to rever tot green until we come up with a full solution. This reverts commit r233817, as well as follow-ups r233820 and r233821. llvm-svn: 234355
2015-04-08 04:46:51 +08:00
Constructor->isInlineSpecified(),
Update constexpr implementation to match CWG's chosen approach for core issues 1358, 1360, 1452 and 1453. - Instantiations of constexpr functions are always constexpr. This removes the need for separate declaration/definition checking, which is now gone. - This makes it possible for a constexpr function to be virtual, if they are only dependently virtual. Virtual calls to such functions are not constant expressions. - Likewise, it's now possible for a literal type to have virtual base classes. A constexpr constructor for such a type cannot actually produce a constant expression, though, so add a special-case diagnostic for a constructor call to such a type rather than trying to evaluate it. - Classes with trivial default constructors (for which value initialization can produce a fully-initialized value) are considered literal types. - Classes with volatile members are not literal types. - constexpr constructors can be members of non-literal types. We do not yet use static initialization for global objects constructed in this way. llvm-svn: 150359
2012-02-13 11:54:03 +08:00
false, Constructor->isConstexpr());
[Sema] Set range end of constructors and destructors in template instantiations Summary: clang-tidy checks frequently use source ranges of functions. The source range of constructors and destructors in template instantiations is currently a single token. The factory method for constructors and destructors does not allow the end source location to be specified. Set end location manually after creating instantiation. Reviewers: aaron.ballman, rsmith, arphaman Subscribers: arphaman, cfe-commits Differential Revision: https://reviews.llvm.org/D26849 llvm-svn: 288025
2016-11-28 19:11:34 +08:00
Method->setRangeEnd(Constructor->getLocEnd());
Refactor instantiation of destructors to use the common CXXMethodDecl code, fixing a problem where instantiations of out-of-line destructor definitions would had the wrong lexical context. Introduce tests for out-of-line definitions of the constructors, destructors, and conversion functions of a class template partial specialization. llvm-svn: 79682
2009-08-22 06:43:28 +08:00
} else if (CXXDestructorDecl *Destructor = dyn_cast<CXXDestructorDecl>(D)) {
Method = CXXDestructorDecl::Create(SemaRef.Context, Record,
Fixed source range for all DeclaratorDecl's. llvm-svn: 127225
2011-03-08 16:55:46 +08:00
StartLoc, NameInfo, T, TInfo,
Revert "Mark instantiated function decls as inline specified if any pattern is" It breaks down on this test case: void foo(); template <typename T> class C { friend void foo(); }; inline void foo() {} C<int> c; We shouldn't be marking the instantiation of the friend decl of foo as inline-specified. It may be possible to fix this by determining if the full definition is part of the current template, but it seems better to rever tot green until we come up with a full solution. This reverts commit r233817, as well as follow-ups r233820 and r233821. llvm-svn: 234355
2015-04-08 04:46:51 +08:00
Destructor->isInlineSpecified(),
Keep track of the actual storage specifier written on a variable or function declaration, since it may end up being changed (e.g., "extern" can become "static" if a prior declaration was static). Patch by Enea Zaffanella and Paolo Bolzoni. llvm-svn: 101826
2010-04-20 06:54:31 +08:00
false);
[Sema] Set range end of constructors and destructors in template instantiations Summary: clang-tidy checks frequently use source ranges of functions. The source range of constructors and destructors in template instantiations is currently a single token. The factory method for constructors and destructors does not allow the end source location to be specified. Set end location manually after creating instantiation. Reviewers: aaron.ballman, rsmith, arphaman Subscribers: arphaman, cfe-commits Differential Revision: https://reviews.llvm.org/D26849 llvm-svn: 288025
2016-11-28 19:11:34 +08:00
Method->setRangeEnd(Destructor->getLocEnd());
Implement conversion function templates, along with the ability to use template argument deduction from a conversion function (C++ [temp.deduct.conv]) with implicit conversions. llvm-svn: 79693
2009-08-22 07:19:43 +08:00
} else if (CXXConversionDecl *Conversion = dyn_cast<CXXConversionDecl>(D)) {
Method = CXXConversionDecl::Create(SemaRef.Context, Record,
Fixed source range for all DeclaratorDecl's. llvm-svn: 127225
2011-03-08 16:55:46 +08:00
StartLoc, NameInfo, T, TInfo,
Revert "Mark instantiated function decls as inline specified if any pattern is" It breaks down on this test case: void foo(); template <typename T> class C { friend void foo(); }; inline void foo() {} C<int> c; We shouldn't be marking the instantiation of the friend decl of foo as inline-specified. It may be possible to fix this by determining if the full definition is part of the current template, but it seems better to rever tot green until we come up with a full solution. This reverts commit r233817, as well as follow-ups r233820 and r233821. llvm-svn: 234355
2015-04-08 04:46:51 +08:00
Conversion->isInlineSpecified(),
Teach libclang's token-annotation logic about context-sensitive keywords for Objective-C+ and C++0x. llvm-svn: 127253
2011-03-09 01:10:18 +08:00
Conversion->isExplicit(),
Update constexpr implementation to match CWG's chosen approach for core issues 1358, 1360, 1452 and 1453. - Instantiations of constexpr functions are always constexpr. This removes the need for separate declaration/definition checking, which is now gone. - This makes it possible for a constexpr function to be virtual, if they are only dependently virtual. Virtual calls to such functions are not constant expressions. - Likewise, it's now possible for a literal type to have virtual base classes. A constexpr constructor for such a type cannot actually produce a constant expression, though, so add a special-case diagnostic for a constructor call to such a type rather than trying to evaluate it. - Classes with trivial default constructors (for which value initialization can produce a fully-initialized value) are considered literal types. - Classes with volatile members are not literal types. - constexpr constructors can be members of non-literal types. We do not yet use static initialization for global objects constructed in this way. llvm-svn: 150359
2012-02-13 11:54:03 +08:00
Conversion->isConstexpr(),
constexpr: semantic checking for constexpr functions and constructors. Based in part on patches by Peter Collingbourne. We diverge from the C++11 standard in a few areas, mostly related to checking constexpr function declarations, and not just definitions. See WG21 paper N3308=11-0078 for details. Function invocation substitution is not available in this patch; constexpr functions cannot yet be used from within constant expressions. llvm-svn: 140926
2011-10-01 10:31:28 +08:00
Conversion->getLocEnd());
Introduce support for constructor templates, which can now be declared and will participate in overload resolution. Unify the instantiation of CXXMethodDecls and CXXConstructorDecls, which had already gotten out-of-sync. llvm-svn: 79658
2009-08-22 02:42:58 +08:00
} else {
Fix the storage class of method instantiations. We keep the "as written" storage class, but that is a fuzzy concept for instantiations. With this patch instantiations of methods of class templates now get a storage class that is based on the semantics of isStatic(). With this can simplify isStatic() itself. llvm-svn: 179521
2013-04-15 20:38:20 +08:00
StorageClass SC = D->isStatic() ? SC_Static : SC_None;
Added locations and type source info for DeclarationName. llvm-svn: 110860
2010-08-12 06:01:17 +08:00
Method = CXXMethodDecl::Create(SemaRef.Context, Record,
Fixed source range for all DeclaratorDecl's. llvm-svn: 127225
2011-03-08 16:55:46 +08:00
StartLoc, NameInfo, T, TInfo,
Revert "Mark instantiated function decls as inline specified if any pattern is" It breaks down on this test case: void foo(); template <typename T> class C { friend void foo(); }; inline void foo() {} C<int> c; We shouldn't be marking the instantiation of the friend decl of foo as inline-specified. It may be possible to fix this by determining if the full definition is part of the current template, but it seems better to rever tot green until we come up with a full solution. This reverts commit r233817, as well as follow-ups r233820 and r233821. llvm-svn: 234355
2015-04-08 04:46:51 +08:00
SC, D->isInlineSpecified(),
Update constexpr implementation to match CWG's chosen approach for core issues 1358, 1360, 1452 and 1453. - Instantiations of constexpr functions are always constexpr. This removes the need for separate declaration/definition checking, which is now gone. - This makes it possible for a constexpr function to be virtual, if they are only dependently virtual. Virtual calls to such functions are not constant expressions. - Likewise, it's now possible for a literal type to have virtual base classes. A constexpr constructor for such a type cannot actually produce a constant expression, though, so add a special-case diagnostic for a constructor call to such a type rather than trying to evaluate it. - Classes with trivial default constructors (for which value initialization can produce a fully-initialized value) are considered literal types. - Classes with volatile members are not literal types. - constexpr constructors can be members of non-literal types. We do not yet use static initialization for global objects constructed in this way. llvm-svn: 150359
2012-02-13 11:54:03 +08:00
D->isConstexpr(), D->getLocEnd());
Introduce support for constructor templates, which can now be declared and will participate in overload resolution. Unify the instantiation of CXXMethodDecls and CXXConstructorDecls, which had already gotten out-of-sync. llvm-svn: 79658
2009-08-22 02:42:58 +08:00
}
Implement support for calling member function templates, which involves: - Allowing one to name a member function template within a class template and on the right-hand side of a member access expression. - Template argument deduction for calls to member function templates. - Registering specializations of member function templates (and finding them later). llvm-svn: 79581
2009-08-21 08:16:32 +08:00
Clean up: since we have FunctionDecl::IsInline, make it store the right value for template instantiations, and use it to simplify the implementation of FunctionDecl::isInlined(). This incidentally changes the result of isInlined on a declared-but-not-defined non-inline member function from true to false. This is sort of a bug fix, but currently isInlined is only called on function definitions, so it has no visible effects. llvm-svn: 173397
2013-01-25 08:08:28 +08:00
if (D->isInlined())
Method->setImplicitlyInline();
Use NestedNameSpecifierLoc within out-of-line variables, function, and tag definitions. Also, add support for template instantiation of NestedNameSpecifierLocs. llvm-svn: 126470
2011-02-25 10:25:35 +08:00
if (QualifierLoc)
Method->setQualifierInfo(QualifierLoc);
Remember declaration scope qualifiers in the AST. Imposes no memory overhead on unqualified declarations. Patch by Enea Zaffanella! Minimal adjustments: allocate the ExtInfo nodes with the ASTContext and delete them during Destroy(). I audited a bunch of Destroy methods at the same time, to ensure that the correct teardown was being done. llvm-svn: 98540
2010-03-15 18:12:16 +08:00
Implement instantiation of the declarations of member function templates within class templates, producing a member function template of a class template specialization. If you can parse that, I'm sorry. Example: template<typename T> struct X { template<typename U> void f(T, U); }; When we instantiate X<int>, we now instantiate the declaration X<int>::f, which looks like this: template<typename U> void X<int>::f(int, U); The path this takes through TemplateDeclInstantiator::VisitCXXMethodDecl is convoluted and ugly, but I don't know how to improve it yet. I'm resting my hopes on the multi-level substitution required to instantiate definitions of nested templates, which may simplify this code as well. More testing to come... llvm-svn: 80252
2009-08-28 00:57:43 +08:00
if (TemplateParams) {
// Our resulting instantiation is actually a function template, since we
// are substituting only the outer template parameters. For example, given
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
//
Implement instantiation of the declarations of member function templates within class templates, producing a member function template of a class template specialization. If you can parse that, I'm sorry. Example: template<typename T> struct X { template<typename U> void f(T, U); }; When we instantiate X<int>, we now instantiate the declaration X<int>::f, which looks like this: template<typename U> void X<int>::f(int, U); The path this takes through TemplateDeclInstantiator::VisitCXXMethodDecl is convoluted and ugly, but I don't know how to improve it yet. I'm resting my hopes on the multi-level substitution required to instantiate definitions of nested templates, which may simplify this code as well. More testing to come... llvm-svn: 80252
2009-08-28 00:57:43 +08:00
// template<typename T>
// struct X {
// template<typename U> void f(T, U);
// };
//
// X<int> x;
//
// We are instantiating the member template "f" within X<int>, which means
// substituting int for T, but leaving "f" as a member function template.
// Build the function template itself.
FunctionTemplate = FunctionTemplateDecl::Create(SemaRef.Context, Record,
Method->getLocation(),
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Method->getDeclName(),
Implement instantiation of the declarations of member function templates within class templates, producing a member function template of a class template specialization. If you can parse that, I'm sorry. Example: template<typename T> struct X { template<typename U> void f(T, U); }; When we instantiate X<int>, we now instantiate the declaration X<int>::f, which looks like this: template<typename U> void X<int>::f(int, U); The path this takes through TemplateDeclInstantiator::VisitCXXMethodDecl is convoluted and ugly, but I don't know how to improve it yet. I'm resting my hopes on the multi-level substitution required to instantiate definitions of nested templates, which may simplify this code as well. More testing to come... llvm-svn: 80252
2009-08-28 00:57:43 +08:00
TemplateParams, Method);
Implement method friends in class templates and fix a few related problems. llvm-svn: 99708
2010-03-27 13:57:59 +08:00
if (isFriend) {
FunctionTemplate->setLexicalDeclContext(Owner);
Reinstate r186040, with additional fixes and more test coverage (reverted in r186331). Original commit log: If we friend a declaration twice, that should not make it visible to name lookup in the surrounding context. Slightly rework how we handle friend declarations to inherit the visibility of the prior declaration, rather than setting a friend declaration to be visible whenever there was a prior declaration. llvm-svn: 186546
2013-07-18 07:53:16 +08:00
FunctionTemplate->setObjectOfFriendDecl();
Implement method friends in class templates and fix a few related problems. llvm-svn: 99708
2010-03-27 13:57:59 +08:00
} else if (D->isOutOfLine())
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
FunctionTemplate->setLexicalDeclContext(D->getLexicalDeclContext());
Implement instantiation of the declarations of member function templates within class templates, producing a member function template of a class template specialization. If you can parse that, I'm sorry. Example: template<typename T> struct X { template<typename U> void f(T, U); }; When we instantiate X<int>, we now instantiate the declaration X<int>::f, which looks like this: template<typename U> void X<int>::f(int, U); The path this takes through TemplateDeclInstantiator::VisitCXXMethodDecl is convoluted and ugly, but I don't know how to improve it yet. I'm resting my hopes on the multi-level substitution required to instantiate definitions of nested templates, which may simplify this code as well. More testing to come... llvm-svn: 80252
2009-08-28 00:57:43 +08:00
Method->setDescribedFunctionTemplate(FunctionTemplate);
If we attempt to add a constructor template specialization that looks like a copy constructor to the overload set, just ignore it. This ensures that we don't try to use such a constructor as a copy constructor *without* triggering diagnostics at the point of declaration. Note that we *do* diagnose such copy constructors when explicitly written by the user (e.g., as an explicit specialization). llvm-svn: 88733
2009-11-14 09:20:54 +08:00
} else if (FunctionTemplate) {
// Record this function template specialization.
ArrayRef'ize MultiLevelTemplateArgumentList::ArgList. Patch by Faisal Vali! llvm-svn: 181077
2013-05-04 07:46:09 +08:00
ArrayRef<TemplateArgument> Innermost = TemplateArgs.getInnermost();
Eliminate a bunch of unnecessary ASTContexts from members functions of Decl subclasses. No functionality change. llvm-svn: 95841
2010-02-11 09:19:42 +08:00
Method->setFunctionTemplateSpecialization(FunctionTemplate,
Remove broken support for variadic templates, along with the various abstractions (e.g., TemplateArgumentListBuilder) that were designed to support variadic templates. Only a few remnants of variadic templates remain, in the parser (parsing template type parameter packs), AST (template type parameter pack bits and TemplateArgument::Pack), and Sema; these are expected to be used in a future implementation of variadic templates. But don't get too excited about that happening now. llvm-svn: 118385
2010-11-08 07:05:16 +08:00
TemplateArgumentList::CreateCopy(SemaRef.Context,
[AST] Use ArrayRef in more interfaces ArrayRef is a little better than passing around a pointer/length pair. No functional change is intended. llvm-svn: 274475
2016-07-04 05:17:51 +08:00
Innermost),
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
/*InsertPos=*/nullptr);
Implement method friends in class templates and fix a few related problems. llvm-svn: 99708
2010-03-27 13:57:59 +08:00
} else if (!isFriend) {
If we attempt to add a constructor template specialization that looks like a copy constructor to the overload set, just ignore it. This ensures that we don't try to use such a constructor as a copy constructor *without* triggering diagnostics at the point of declaration. Note that we *do* diagnose such copy constructors when explicitly written by the user (e.g., as an explicit specialization). llvm-svn: 88733
2009-11-14 09:20:54 +08:00
// Record that this is an instantiation of a member function.
Keep track of whether a member function instantiated from a member function of a class template was implicitly instantiated, explicitly instantiated (declaration or definition), or explicitly specialized. The same MemberSpecializationInfo structure will be used for static data members and member classes as well. llvm-svn: 83509
2009-10-08 07:56:10 +08:00
Method->setInstantiationOfMemberFunction(D, TSK_ImplicitInstantiation);
If we attempt to add a constructor template specialization that looks like a copy constructor to the overload set, just ignore it. This ensures that we don't try to use such a constructor as a copy constructor *without* triggering diagnostics at the point of declaration. Note that we *do* diagnose such copy constructors when explicitly written by the user (e.g., as an explicit specialization). llvm-svn: 88733
2009-11-14 09:20:54 +08:00
}
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
// If we are instantiating a member function defined
Template instantiation for static data members that are defined out-of-line. Note that this also fixes a bug that affects non-template code, where we were not treating out-of-line static data members are "file-scope" variables, and therefore not checking their initializers. llvm-svn: 77002
2009-07-25 04:34:43 +08:00
// out-of-line, the instantiation will have the same lexical
// context (which will be a namespace scope) as the template.
Implement method friends in class templates and fix a few related problems. llvm-svn: 99708
2010-03-27 13:57:59 +08:00
if (isFriend) {
Instantiate enclosing template parameter lists when instantiating friends. llvm-svn: 116789
2010-10-19 10:26:41 +08:00
if (NumTempParamLists)
[AST] ArrayRefize template param list info setters. No functionality change intended. llvm-svn: 244028
2015-08-05 17:40:49 +08:00
Method->setTemplateParameterListsInfo(
SemaRef.Context,
llvm::makeArrayRef(TempParamLists.data(), NumTempParamLists));
Instantiate enclosing template parameter lists when instantiating friends. llvm-svn: 116789
2010-10-19 10:26:41 +08:00
Implement method friends in class templates and fix a few related problems. llvm-svn: 99708
2010-03-27 13:57:59 +08:00
Method->setLexicalDeclContext(Owner);
Reinstate r186040, with additional fixes and more test coverage (reverted in r186331). Original commit log: If we friend a declaration twice, that should not make it visible to name lookup in the surrounding context. Slightly rework how we handle friend declarations to inherit the visibility of the prior declaration, rather than setting a friend declaration to be visible whenever there was a prior declaration. llvm-svn: 186546
2013-07-18 07:53:16 +08:00
Method->setObjectOfFriendDecl();
Implement method friends in class templates and fix a few related problems. llvm-svn: 99708
2010-03-27 13:57:59 +08:00
} else if (D->isOutOfLine())
Template instantiation for static data members that are defined out-of-line. Note that this also fixes a bug that affects non-template code, where we were not treating out-of-line static data members are "file-scope" variables, and therefore not checking their initializers. llvm-svn: 77002
2009-07-25 04:34:43 +08:00
Method->setLexicalDeclContext(D->getLexicalDeclContext());
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Cleanup template instantiation for methods, destructors llvm-svn: 67585
2009-03-24 08:38:23 +08:00
// Attach the parameters
for (unsigned P = 0; P < Params.size(); ++P)
Params[P]->setOwningFunction(Method);
ArrayRef-ifying Function/BlockDecl's setParams llvm-svn: 140268
2011-09-22 02:16:56 +08:00
Method->setParams(Params);
Cleanup template instantiation for methods, destructors llvm-svn: 67585
2009-03-24 08:38:23 +08:00
if (InitMethodInstantiation(Method, D))
Method->setInvalidDecl();
Template instantiation for the declarations of member functions within a class template. At present, we can only instantiation normal methods, but not constructors, destructors, or conversion operators. As ever, this contains a bit of refactoring in Sema's type-checking. In particular: - Split ActOnFunctionDeclarator into ActOnFunctionDeclarator (handling the declarator itself) and CheckFunctionDeclaration (checking for the the function declaration), the latter of which is also used by template instantiation. - We were performing the adjustment of function parameter types in three places; collect those into a single new routine. - When the type of a parameter is adjusted, allocate an OriginalParmVarDecl to keep track of the type as it was written. - Eliminate a redundant check for out-of-line declarations of member functions; hide more C++-specific checks on function declarations behind if(getLangOptions().CPlusPlus). llvm-svn: 67575
2009-03-24 07:06:20 +08:00
Added locations and type source info for DeclarationName. llvm-svn: 110860
2010-08-12 06:01:17 +08:00
LookupResult Previous(SemaRef, NameInfo, Sema::LookupOrdinaryName,
Sema::ForRedeclaration);
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Implement method friends in class templates and fix a few related problems. llvm-svn: 99708
2010-03-27 13:57:59 +08:00
if (!FunctionTemplate || TemplateParams || isFriend) {
SemaRef.LookupQualifiedName(Previous, Record);
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Introduce support for constructor templates, which can now be declared and will participate in overload resolution. Unify the instantiation of CXXMethodDecls and CXXConstructorDecls, which had already gotten out-of-sync. llvm-svn: 79658
2009-08-22 02:42:58 +08:00
// In C++, the previous declaration we find might be a tag type
// (class or enum). In this case, the new declaration will hide the
// tag type. Note that this does does not apply if we're declaring a
// typedef (C++ [dcl.typedef]p4).
Overhaul previous-declaration and overload checking to work on lookup results rather than NamedDecl*. This is a major step towards eliminating OverloadedFunctionDecl. llvm-svn: 89263
2009-11-19 06:49:29 +08:00
if (Previous.isSingleTagDecl())
Previous.clear();
Introduce support for constructor templates, which can now be declared and will participate in overload resolution. Unify the instantiation of CXXMethodDecls and CXXConstructorDecls, which had already gotten out-of-sync. llvm-svn: 79658
2009-08-22 02:42:58 +08:00
}
Template instantiation for the declarations of member functions within a class template. At present, we can only instantiation normal methods, but not constructors, destructors, or conversion operators. As ever, this contains a bit of refactoring in Sema's type-checking. In particular: - Split ActOnFunctionDeclarator into ActOnFunctionDeclarator (handling the declarator itself) and CheckFunctionDeclaration (checking for the the function declaration), the latter of which is also used by template instantiation. - We were performing the adjustment of function parameter types in three places; collect those into a single new routine. - When the type of a parameter is adjusted, allocate an OriginalParmVarDecl to keep track of the type as it was written. - Eliminate a redundant check for out-of-line declarations of member functions; hide more C++-specific checks on function declarations behind if(getLangOptions().CPlusPlus). llvm-svn: 67575
2009-03-24 07:06:20 +08:00
Implement function template specialization at class scope extension in Microsoft mode. A new AST node is introduced: ClassScopeFunctionSpecialization. This node holds a FunctionDecl that is not yet specialized; then during the class template instantiation the ClassScopeFunctionSpecialization will spawn the actual function specialization. Example: template <class T> class A { public: template <class U> void f(U p) { } template <> void f(int p) { } // <== class scope specialization }; This extension is necessary to parse MSVC standard C++ headers, MFC and ATL code. BTW, with this feature in, clang can parse (-fsyntax-only) all the MSVC 2010 standard header files without any error. llvm-svn: 137573
2011-08-14 11:52:19 +08:00
if (!IsClassScopeSpecialization)
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
SemaRef.CheckFunctionDeclaration(nullptr, Method, Previous, false);
Implement conversion function templates, along with the ability to use template argument deduction from a conversion function (C++ [temp.deduct.conv]) with implicit conversions. llvm-svn: 79693
2009-08-22 07:19:43 +08:00
Move the checking of overridden virtual functions into the code path common to both parsing and template instantiation, so that we'll find overridden virtuals for member functions of class templates when they are instantiated. Additionally, factor out the checking for pure virtual functions, so that it will be executed both at parsing time and at template instantiation time. These changes fix PR5656 (for real), although one more tweak w.r.t. member function templates will be coming along shortly. llvm-svn: 90241
2009-12-02 01:24:26 +08:00
if (D->isPure())
SemaRef.CheckPureMethod(Method, SourceRange());
Check access to friend declarations. There's a number of different things going on here that were problematic: - We were missing the actual access check, or rather, it was suppressed on account of being a redeclaration lookup. - The access check would naturally happen during delay, which isn't appropriate in this case. - We weren't actually emitting dependent diagnostics associated with class templates, which was unfortunate. - Access was being propagated incorrectly for friend method declarations that couldn't be matched at parse-time. llvm-svn: 161652
2012-08-10 11:15:35 +08:00
// Propagate access. For a non-friend declaration, the access is
// whatever we're propagating from. For a friend, it should be the
// previous declaration we just found.
if (isFriend && Method->getPreviousDecl())
Method->setAccess(Method->getPreviousDecl()->getAccess());
else
Method->setAccess(D->getAccess());
if (FunctionTemplate)
FunctionTemplate->setAccess(Method->getAccess());
First pass at collecting access-specifier information along inheritance paths. Triggers lots of assertions about missing access information; fix them. Will actually consume this information soon. llvm-svn: 94038
2010-01-21 05:53:11 +08:00
When instantiating member functions, propagate whether the member function is marked 'final' and 'override'. Also, call CheckOverrideControl when instantiating member functions. llvm-svn: 123900
2011-01-20 14:52:44 +08:00
SemaRef.CheckOverrideControl(Method);
Compute whether a class is trivial correctly for template classes with an explicitly deleted or defaulted special member. PR11387. llvm-svn: 144715
2011-11-16 06:39:08 +08:00
// If a function is defined as defaulted or deleted, mark it as such now.
Properly compute triviality for explicitly-defaulted or deleted special members. Remove pre-standard restriction on explicitly-defaulted copy constructors with 'incorrect' parameter types, and instead just make those special members non-trivial as the standard requires. This required making CXXRecordDecl correctly handle classes which have both a trivial and a non-trivial special member of the same kind. This also fixes PR13217 by reimplementing DiagnoseNontrivial in terms of the new triviality computation technology. llvm-svn: 169667
2012-12-08 10:53:02 +08:00
if (D->isExplicitlyDefaulted())
SemaRef.SetDeclDefaulted(Method, Method->getLocation());
Compute whether a class is trivial correctly for template classes with an explicitly deleted or defaulted special member. PR11387. llvm-svn: 144715
2011-11-16 06:39:08 +08:00
if (D->isDeletedAsWritten())
Properly compute triviality for explicitly-defaulted or deleted special members. Remove pre-standard restriction on explicitly-defaulted copy constructors with 'incorrect' parameter types, and instead just make those special members non-trivial as the standard requires. This required making CXXRecordDecl correctly handle classes which have both a trivial and a non-trivial special member of the same kind. This also fixes PR13217 by reimplementing DiagnoseNontrivial in terms of the new triviality computation technology. llvm-svn: 169667
2012-12-08 10:53:02 +08:00
SemaRef.SetDeclDeleted(Method, Method->getLocation());
Compute whether a class is trivial correctly for template classes with an explicitly deleted or defaulted special member. PR11387. llvm-svn: 144715
2011-11-16 06:39:08 +08:00
Check access to friend declarations. There's a number of different things going on here that were problematic: - We were missing the actual access check, or rather, it was suppressed on account of being a redeclaration lookup. - The access check would naturally happen during delay, which isn't appropriate in this case. - We weren't actually emitting dependent diagnostics associated with class templates, which was unfortunate. - Access was being propagated incorrectly for friend method declarations that couldn't be matched at parse-time. llvm-svn: 161652
2012-08-10 11:15:35 +08:00
// If there's a function template, let our caller handle it.
Implement method friends in class templates and fix a few related problems. llvm-svn: 99708
2010-03-27 13:57:59 +08:00
if (FunctionTemplate) {
Check access to friend declarations. There's a number of different things going on here that were problematic: - We were missing the actual access check, or rather, it was suppressed on account of being a redeclaration lookup. - The access check would naturally happen during delay, which isn't appropriate in this case. - We weren't actually emitting dependent diagnostics associated with class templates, which was unfortunate. - Access was being propagated incorrectly for friend method declarations that couldn't be matched at parse-time. llvm-svn: 161652
2012-08-10 11:15:35 +08:00
// do nothing
// Don't hide a (potentially) valid declaration with an invalid one.
Implement method friends in class templates and fix a few related problems. llvm-svn: 99708
2010-03-27 13:57:59 +08:00
} else if (Method->isInvalidDecl() && !Previous.empty()) {
Check access to friend declarations. There's a number of different things going on here that were problematic: - We were missing the actual access check, or rather, it was suppressed on account of being a redeclaration lookup. - The access check would naturally happen during delay, which isn't appropriate in this case. - We weren't actually emitting dependent diagnostics associated with class templates, which was unfortunate. - Access was being propagated incorrectly for friend method declarations that couldn't be matched at parse-time. llvm-svn: 161652
2012-08-10 11:15:35 +08:00
// do nothing
// Otherwise, check access to friends and make them visible.
} else if (isFriend) {
// We only need to re-check access for methods which we didn't
// manage to match during parsing.
if (!D->getPreviousDecl())
SemaRef.CheckFriendAccess(Method);
Record->makeDeclVisibleInContext(Method);
// Otherwise, add the declaration. We don't need to do this for
// class-scope specializations because we'll have matched them with
// the appropriate template.
} else if (!IsClassScopeSpecialization) {
Owner->addDecl(Method);
Implement method friends in class templates and fix a few related problems. llvm-svn: 99708
2010-03-27 13:57:59 +08:00
}
Correctly propagate defaultedness across template instantiation. This fixes PR9965, but we're not out of the water yet, as we do not successfully handle out-of-line definitions, due to my utter misunderstanding of how we manage templates. llvm-svn: 131920
2011-05-24 05:07:59 +08:00
Template instantiation for the declarations of member functions within a class template. At present, we can only instantiation normal methods, but not constructors, destructors, or conversion operators. As ever, this contains a bit of refactoring in Sema's type-checking. In particular: - Split ActOnFunctionDeclarator into ActOnFunctionDeclarator (handling the declarator itself) and CheckFunctionDeclaration (checking for the the function declaration), the latter of which is also used by template instantiation. - We were performing the adjustment of function parameter types in three places; collect those into a single new routine. - When the type of a parameter is adjusted, allocate an OriginalParmVarDecl to keep track of the type as it was written. - Eliminate a redundant check for out-of-line declarations of member functions; hide more C++-specific checks on function declarations behind if(getLangOptions().CPlusPlus). llvm-svn: 67575
2009-03-24 07:06:20 +08:00
return Method;
}
Template instantiation for constructors llvm-svn: 67623
2009-03-25 00:43:20 +08:00
Decl *TemplateDeclInstantiator::VisitCXXConstructorDecl(CXXConstructorDecl *D) {
Introduce support for constructor templates, which can now be declared and will participate in overload resolution. Unify the instantiation of CXXMethodDecls and CXXConstructorDecls, which had already gotten out-of-sync. llvm-svn: 79658
2009-08-22 02:42:58 +08:00
return VisitCXXMethodDecl(D);
Template instantiation for constructors llvm-svn: 67623
2009-03-25 00:43:20 +08:00
}
Template instantiation for destructors. This is somewhat repetitive; eliminating the duplication is next on the list. llvm-svn: 67579
2009-03-24 08:15:49 +08:00
Decl *TemplateDeclInstantiator::VisitCXXDestructorDecl(CXXDestructorDecl *D) {
Refactor instantiation of destructors to use the common CXXMethodDecl code, fixing a problem where instantiations of out-of-line destructor definitions would had the wrong lexical context. Introduce tests for out-of-line definitions of the constructors, destructors, and conversion functions of a class template partial specialization. llvm-svn: 79682
2009-08-22 06:43:28 +08:00
return VisitCXXMethodDecl(D);
Template instantiation for destructors. This is somewhat repetitive; eliminating the duplication is next on the list. llvm-svn: 67579
2009-03-24 08:15:49 +08:00
}
Template instantiation for conversion functions llvm-svn: 67664
2009-03-25 08:34:44 +08:00
Decl *TemplateDeclInstantiator::VisitCXXConversionDecl(CXXConversionDecl *D) {
Implement conversion function templates, along with the ability to use template argument deduction from a conversion function (C++ [temp.deduct.conv]) with implicit conversions. llvm-svn: 79693
2009-08-22 07:19:43 +08:00
return VisitCXXMethodDecl(D);
Template instantiation for conversion functions llvm-svn: 67664
2009-03-25 08:34:44 +08:00
}
Switch Decl instantiation to DeclNodes.inc. This replaces a long list of declarations for visitor functions with a list generated from DeclNodes.inc. Nothing really interesting came out of it; we had comprehensive coverage anyway (excluding FriendTemplateDecls). llvm-svn: 185118
2013-06-28 07:21:55 +08:00
Decl *TemplateDeclInstantiator::VisitParmVarDecl(ParmVarDecl *D) {
Use None rather than Optional<T>() where possible. llvm-svn: 175705
2013-02-21 09:47:18 +08:00
return SemaRef.SubstParmVarDecl(D, TemplateArgs, /*indexAdjustment*/ 0, None,
/*ExpectParameterPack=*/ false);
Template instantiation for the declarations of member functions within a class template. At present, we can only instantiation normal methods, but not constructors, destructors, or conversion operators. As ever, this contains a bit of refactoring in Sema's type-checking. In particular: - Split ActOnFunctionDeclarator into ActOnFunctionDeclarator (handling the declarator itself) and CheckFunctionDeclaration (checking for the the function declaration), the latter of which is also used by template instantiation. - We were performing the adjustment of function parameter types in three places; collect those into a single new routine. - When the type of a parameter is adjusted, allocate an OriginalParmVarDecl to keep track of the type as it was written. - Eliminate a redundant check for out-of-line declarations of member functions; hide more C++-specific checks on function declarations behind if(getLangOptions().CPlusPlus). llvm-svn: 67575
2009-03-24 07:06:20 +08:00
}
Basic nested-template implementation. llvm-svn: 79504
2009-08-20 09:44:21 +08:00
Decl *TemplateDeclInstantiator::VisitTemplateTypeParmDecl(
TemplateTypeParmDecl *D) {
// TODO: don't always clone when decls are refcounted.
Re-applies the patch first applied way back in r106099, with accompanying fixes to make it work today. The core of this patch is to provide a link from a TemplateTypeParmType back to the TemplateTypeParmDecl node which declared it. This in turn provides much more precise information about the type, where it came from, and how it functions for AST consumers. To make the patch work almost a year after its first attempt, it needed serialization support, and it now retains the old getName() interface. Finally, it requires us to not attempt to instantiate the type in an unsupported friend decl -- specifically those coming from template friend decls but which refer to a specific type through a dependent name. A cleaner representation of the last item would be to build FriendTemplateDecl nodes for these, storing their template parameters etc, and to perform proper instantation of them like any other template declaration. They can still be flagged as unsupported for the purpose of access checking, etc. This passed an asserts-enabled bootstrap for me, and the reduced test case mentioned in the original review thread no longer causes issues, likely fixed at somewhere amidst the 24k revisions that have elapsed. llvm-svn: 130628
2011-05-01 08:51:33 +08:00
assert(D->getTypeForDecl()->isTemplateTypeParmType());
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
PR32010: Fix template argument depth mixup when forming implicit constructor template deduction guides for class template argument deduction. Ensure that we have a local instantiation scope for tracking the instantiated parameters. Additionally, unusually, we're substituting at depth 1 and leaving depth 0 alone; make sure that we don't reduce template parameter depth by 2 for inner parameters in the process. (This is probably also broken for alias templates in the case where they're expanded within a dependent context, but this patch doesn't fix that.) llvm-svn: 295696
2017-02-21 14:30:38 +08:00
TemplateTypeParmDecl *Inst = TemplateTypeParmDecl::Create(
SemaRef.Context, Owner, D->getLocStart(), D->getLocation(),
D->getDepth() - TemplateArgs.getNumSubstitutedLevels(), D->getIndex(),
D->getIdentifier(), D->wasDeclaredWithTypename(), D->isParameterPack());
Make sure to put template parameters into their owning template's DeclContext once we've created it. This mirrors what we do for function parameters, where the parameters start out with translation-unit context and then are adopted by the appropriate DeclContext when it is created. Also give template parameters public access and make sure that they don't show up for the purposes of name lookup. Fixes PR9400, a regression introduced by r126920, which implemented substitution of default template arguments provided in template template parameters (C++ core issue 150). How on earth could the DeclContext of a template parameter affect the handling of default template arguments? I'm so glad you asked! The link is Sema::getTemplateInstantiationArgs(), which determines the outer template argument lists that correspond to a given declaration. When we're instantiating a default template argument for a template template parameter within the body of a template definition (not it's instantiation, per core issue 150), we weren't getting any outer template arguments because the context of the template template parameter was the translation unit. Now that the context of the template template parameter is its owning template, we get the template arguments from the injected-class-name of the owning template, so substitution works as it should. llvm-svn: 127004
2011-03-05 01:52:15 +08:00
Inst->setAccess(AS_public);
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
[modules] Fix merging of default template arguments onto friend templates. Previously we'd complain about redefinition of default arguments when we instantiated a class with a friend template that inherits its default argument, because we propagate the default template arguemnt onto the friend when we reload the AST. llvm-svn: 239857
2015-06-17 05:57:05 +08:00
if (D->hasDefaultArgument() && !D->defaultArgumentWasInherited()) {
Sema: Subst type default template args earlier Summary: We would not perform substitution at an appropriate point, allowing strange results to appear. We would accepts things that we shouldn't or mangle things incorrectly. Note that this hasn't fixed the other cases like template-template parameters or non-type template parameters. Reviewers: doug.gregor, rjmccall, rsmith Reviewed By: rsmith CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1507 llvm-svn: 189540
2013-08-29 07:48:32 +08:00
TypeSourceInfo *InstantiatedDefaultArg =
SemaRef.SubstType(D->getDefaultArgumentInfo(), TemplateArgs,
D->getDefaultArgumentLoc(), D->getDeclName());
if (InstantiatedDefaultArg)
Refactor storage of default template arguments. This is just a preparatory step towards fixing visibility for default template arguments in modules builds. llvm-svn: 239447
2015-06-10 08:29:03 +08:00
Inst->setDefaultArgument(InstantiatedDefaultArg);
Sema: Subst type default template args earlier Summary: We would not perform substitution at an appropriate point, allowing strange results to appear. We would accepts things that we shouldn't or mangle things incorrectly. Note that this hasn't fixed the other cases like template-template parameters or non-type template parameters. Reviewers: doug.gregor, rjmccall, rsmith Reviewed By: rsmith CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1507 llvm-svn: 189540
2013-08-29 07:48:32 +08:00
}
Basic nested-template implementation. llvm-svn: 79504
2009-08-20 09:44:21 +08:00
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
// Introduce this template parameter's instantiation into the instantiation
Implement "incremental" template instantiation for non-type template parameters and template type parameters, which occurs when substituting into the declarations of member templates inside class templates. This eliminates errors about our inability to "reduce non-type template parameter depth", fixing PR5311. Also fixes a bug when instantiating a template type parameter declaration in a member template, where we weren't properly reducing the template parameter's depth. LLVM's StringSwitch header now parses. llvm-svn: 85669
2009-11-01 01:21:17 +08:00
// scope.
SemaRef.CurrentInstantiationScope->InstantiatedLocal(D, Inst);
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Basic nested-template implementation. llvm-svn: 79504
2009-08-20 09:44:21 +08:00
return Inst;
}
Implement template instantiation for non-type template parameters. Fixes PR5103. llvm-svn: 84979
2009-10-24 07:25:44 +08:00
Decl *TemplateDeclInstantiator::VisitNonTypeTemplateParmDecl(
NonTypeTemplateParmDecl *D) {
// Substitute into the type of the non-type template parameter.
Implement support for non-type template parameter packs whose type is a pack expansion, e.g., the parameter pack Values in: template<typename ...Types> struct Outer { template<Types ...Values> struct Inner; }; This new implementation approach introduces the notion of an "expanded" non-type template parameter pack, for which we have already expanded the types of the parameter pack (to, say, "int*, float*", for Outer<int*, float*>) but have not yet expanded the values. Aside from creating these expanded non-type template parameter packs, this patch updates template argument checking and non-type template parameter pack instantiation to make use of the appropriate types in the parameter pack. llvm-svn: 123845
2011-01-20 04:10:05 +08:00
TypeLoc TL = D->getTypeSourceInfo()->getTypeLoc();
remove unneeded llvm:: namespace qualifiers on some core types now that LLVM.h imports them into the clang namespace. llvm-svn: 135852
2011-07-23 18:55:15 +08:00
SmallVector<TypeSourceInfo *, 4> ExpandedParameterPackTypesAsWritten;
SmallVector<QualType, 4> ExpandedParameterPackTypes;
Implement support for non-type template parameter packs whose type is a pack expansion, e.g., the parameter pack Values in: template<typename ...Types> struct Outer { template<Types ...Values> struct Inner; }; This new implementation approach introduces the notion of an "expanded" non-type template parameter pack, for which we have already expanded the types of the parameter pack (to, say, "int*, float*", for Outer<int*, float*>) but have not yet expanded the values. Aside from creating these expanded non-type template parameter packs, this patch updates template argument checking and non-type template parameter pack instantiation to make use of the appropriate types in the parameter pack. llvm-svn: 123845
2011-01-20 04:10:05 +08:00
bool IsExpandedParameterPack = false;
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
TypeSourceInfo *DI;
Implement template instantiation for non-type template parameters. Fixes PR5103. llvm-svn: 84979
2009-10-24 07:25:44 +08:00
QualType T;
bool Invalid = false;
Implement support for non-type template parameter packs whose type is a pack expansion, e.g., the parameter pack Values in: template<typename ...Types> struct Outer { template<Types ...Values> struct Inner; }; This new implementation approach introduces the notion of an "expanded" non-type template parameter pack, for which we have already expanded the types of the parameter pack (to, say, "int*, float*", for Outer<int*, float*>) but have not yet expanded the values. Aside from creating these expanded non-type template parameter packs, this patch updates template argument checking and non-type template parameter pack instantiation to make use of the appropriate types in the parameter pack. llvm-svn: 123845
2011-01-20 04:10:05 +08:00
if (D->isExpandedParameterPack()) {
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
// The non-type template parameter pack is an already-expanded pack
Implement support for non-type template parameter packs whose type is a pack expansion, e.g., the parameter pack Values in: template<typename ...Types> struct Outer { template<Types ...Values> struct Inner; }; This new implementation approach introduces the notion of an "expanded" non-type template parameter pack, for which we have already expanded the types of the parameter pack (to, say, "int*, float*", for Outer<int*, float*>) but have not yet expanded the values. Aside from creating these expanded non-type template parameter packs, this patch updates template argument checking and non-type template parameter pack instantiation to make use of the appropriate types in the parameter pack. llvm-svn: 123845
2011-01-20 04:10:05 +08:00
// expansion of types. Substitute into each of the expanded types.
ExpandedParameterPackTypes.reserve(D->getNumExpansionTypes());
ExpandedParameterPackTypesAsWritten.reserve(D->getNumExpansionTypes());
for (unsigned I = 0, N = D->getNumExpansionTypes(); I != N; ++I) {
Mark 'auto' as dependent when instantiating the type of a non-type template parameter. Fixes failed deduction for 'auto' non-type template parameters nested within templates. llvm-svn: 290660
2016-12-28 14:27:18 +08:00
TypeSourceInfo *NewDI =
SemaRef.SubstType(D->getExpansionTypeSourceInfo(I), TemplateArgs,
D->getLocation(), D->getDeclName());
Implement support for non-type template parameter packs whose type is a pack expansion, e.g., the parameter pack Values in: template<typename ...Types> struct Outer { template<Types ...Values> struct Inner; }; This new implementation approach introduces the notion of an "expanded" non-type template parameter pack, for which we have already expanded the types of the parameter pack (to, say, "int*, float*", for Outer<int*, float*>) but have not yet expanded the values. Aside from creating these expanded non-type template parameter packs, this patch updates template argument checking and non-type template parameter pack instantiation to make use of the appropriate types in the parameter pack. llvm-svn: 123845
2011-01-20 04:10:05 +08:00
if (!NewDI)
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Mark 'auto' as dependent when instantiating the type of a non-type template parameter. Fixes failed deduction for 'auto' non-type template parameters nested within templates. llvm-svn: 290660
2016-12-28 14:27:18 +08:00
QualType NewT =
SemaRef.CheckNonTypeTemplateParameterType(NewDI, D->getLocation());
Implement support for non-type template parameter packs whose type is a pack expansion, e.g., the parameter pack Values in: template<typename ...Types> struct Outer { template<Types ...Values> struct Inner; }; This new implementation approach introduces the notion of an "expanded" non-type template parameter pack, for which we have already expanded the types of the parameter pack (to, say, "int*, float*", for Outer<int*, float*>) but have not yet expanded the values. Aside from creating these expanded non-type template parameter packs, this patch updates template argument checking and non-type template parameter pack instantiation to make use of the appropriate types in the parameter pack. llvm-svn: 123845
2011-01-20 04:10:05 +08:00
if (NewT.isNull())
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Mark 'auto' as dependent when instantiating the type of a non-type template parameter. Fixes failed deduction for 'auto' non-type template parameters nested within templates. llvm-svn: 290660
2016-12-28 14:27:18 +08:00
ExpandedParameterPackTypesAsWritten.push_back(NewDI);
Implement support for non-type template parameter packs whose type is a pack expansion, e.g., the parameter pack Values in: template<typename ...Types> struct Outer { template<Types ...Values> struct Inner; }; This new implementation approach introduces the notion of an "expanded" non-type template parameter pack, for which we have already expanded the types of the parameter pack (to, say, "int*, float*", for Outer<int*, float*>) but have not yet expanded the values. Aside from creating these expanded non-type template parameter packs, this patch updates template argument checking and non-type template parameter pack instantiation to make use of the appropriate types in the parameter pack. llvm-svn: 123845
2011-01-20 04:10:05 +08:00
ExpandedParameterPackTypes.push_back(NewT);
}
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Implement support for non-type template parameter packs whose type is a pack expansion, e.g., the parameter pack Values in: template<typename ...Types> struct Outer { template<Types ...Values> struct Inner; }; This new implementation approach introduces the notion of an "expanded" non-type template parameter pack, for which we have already expanded the types of the parameter pack (to, say, "int*, float*", for Outer<int*, float*>) but have not yet expanded the values. Aside from creating these expanded non-type template parameter packs, this patch updates template argument checking and non-type template parameter pack instantiation to make use of the appropriate types in the parameter pack. llvm-svn: 123845
2011-01-20 04:10:05 +08:00
IsExpandedParameterPack = true;
DI = D->getTypeSourceInfo();
T = DI->getType();
PR9023: A template template parameter whose template parameter list contains an unexpanded parameter pack is a pack expansion. Thus, as with a non-type template parameter which is a pack expansion, it needs to be expanded early into a fixed list of template parameters. Since the expanded list of template parameters is not itself a parameter pack, it is permitted to appear before the end of the template parameter list, so also remove that restriction (for both template template parameter pack expansions and non-type template parameter pack expansions). llvm-svn: 163369
2012-09-07 10:06:42 +08:00
} else if (D->isPackExpansion()) {
Implement support for non-type template parameter packs whose type is a pack expansion, e.g., the parameter pack Values in: template<typename ...Types> struct Outer { template<Types ...Values> struct Inner; }; This new implementation approach introduces the notion of an "expanded" non-type template parameter pack, for which we have already expanded the types of the parameter pack (to, say, "int*, float*", for Outer<int*, float*>) but have not yet expanded the values. Aside from creating these expanded non-type template parameter packs, this patch updates template argument checking and non-type template parameter pack instantiation to make use of the appropriate types in the parameter pack. llvm-svn: 123845
2011-01-20 04:10:05 +08:00
// The non-type template parameter pack's type is a pack expansion of types.
// Determine whether we need to expand this parameter pack into separate
// types.
Replace TypeLoc llvm::cast support to be well-defined. The TypeLoc hierarchy used the llvm::cast machinery to perform undefined behavior by casting pointers/references to TypeLoc objects to derived types and then using the derived copy constructors (or even returning pointers to derived types that actually point to the original TypeLoc object). Some context is in this thread: http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-December/056804.html Though it's spread over a few months which can be hard to read in the mail archive. llvm-svn: 175462
2013-02-19 06:06:02 +08:00
PackExpansionTypeLoc Expansion = TL.castAs<PackExpansionTypeLoc>();
Implement support for non-type template parameter packs whose type is a pack expansion, e.g., the parameter pack Values in: template<typename ...Types> struct Outer { template<Types ...Values> struct Inner; }; This new implementation approach introduces the notion of an "expanded" non-type template parameter pack, for which we have already expanded the types of the parameter pack (to, say, "int*, float*", for Outer<int*, float*>) but have not yet expanded the values. Aside from creating these expanded non-type template parameter packs, this patch updates template argument checking and non-type template parameter pack instantiation to make use of the appropriate types in the parameter pack. llvm-svn: 123845
2011-01-20 04:10:05 +08:00
TypeLoc Pattern = Expansion.getPatternLoc();
remove unneeded llvm:: namespace qualifiers on some core types now that LLVM.h imports them into the clang namespace. llvm-svn: 135852
2011-07-23 18:55:15 +08:00
SmallVector<UnexpandedParameterPack, 2> Unexpanded;
Implement support for non-type template parameter packs whose type is a pack expansion, e.g., the parameter pack Values in: template<typename ...Types> struct Outer { template<Types ...Values> struct Inner; }; This new implementation approach introduces the notion of an "expanded" non-type template parameter pack, for which we have already expanded the types of the parameter pack (to, say, "int*, float*", for Outer<int*, float*>) but have not yet expanded the values. Aside from creating these expanded non-type template parameter packs, this patch updates template argument checking and non-type template parameter pack instantiation to make use of the appropriate types in the parameter pack. llvm-svn: 123845
2011-01-20 04:10:05 +08:00
SemaRef.collectUnexpandedParameterPacks(Pattern, Unexpanded);
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Implement support for non-type template parameter packs whose type is a pack expansion, e.g., the parameter pack Values in: template<typename ...Types> struct Outer { template<Types ...Values> struct Inner; }; This new implementation approach introduces the notion of an "expanded" non-type template parameter pack, for which we have already expanded the types of the parameter pack (to, say, "int*, float*", for Outer<int*, float*>) but have not yet expanded the values. Aside from creating these expanded non-type template parameter packs, this patch updates template argument checking and non-type template parameter pack instantiation to make use of the appropriate types in the parameter pack. llvm-svn: 123845
2011-01-20 04:10:05 +08:00
// Determine whether the set of unexpanded parameter packs can and should
// be expanded.
bool Expand = true;
bool RetainExpansion = false;
Include llvm::Optional in clang/Basic/LLVM.h Post-commit CR feedback from Jordan Rose regarding r175594. llvm-svn: 175679
2013-02-21 06:23:23 +08:00
Optional<unsigned> OrigNumExpansions
Implement support for non-type template parameter packs whose type is a pack expansion, e.g., the parameter pack Values in: template<typename ...Types> struct Outer { template<Types ...Values> struct Inner; }; This new implementation approach introduces the notion of an "expanded" non-type template parameter pack, for which we have already expanded the types of the parameter pack (to, say, "int*, float*", for Outer<int*, float*>) but have not yet expanded the values. Aside from creating these expanded non-type template parameter packs, this patch updates template argument checking and non-type template parameter pack instantiation to make use of the appropriate types in the parameter pack. llvm-svn: 123845
2011-01-20 04:10:05 +08:00
= Expansion.getTypePtr()->getNumExpansions();
Include llvm::Optional in clang/Basic/LLVM.h Post-commit CR feedback from Jordan Rose regarding r175594. llvm-svn: 175679
2013-02-21 06:23:23 +08:00
Optional<unsigned> NumExpansions = OrigNumExpansions;
Implement support for non-type template parameter packs whose type is a pack expansion, e.g., the parameter pack Values in: template<typename ...Types> struct Outer { template<Types ...Values> struct Inner; }; This new implementation approach introduces the notion of an "expanded" non-type template parameter pack, for which we have already expanded the types of the parameter pack (to, say, "int*, float*", for Outer<int*, float*>) but have not yet expanded the values. Aside from creating these expanded non-type template parameter packs, this patch updates template argument checking and non-type template parameter pack instantiation to make use of the appropriate types in the parameter pack. llvm-svn: 123845
2011-01-20 04:10:05 +08:00
if (SemaRef.CheckParameterPacksForExpansion(Expansion.getEllipsisLoc(),
Pattern.getSourceRange(),
ArrayRef-ifying the UnexpandedParameterPacks passed to Sema::CheckParameterPacksForExpansion llvm-svn: 140290
2011-09-22 10:34:54 +08:00
Unexpanded,
Implement support for non-type template parameter packs whose type is a pack expansion, e.g., the parameter pack Values in: template<typename ...Types> struct Outer { template<Types ...Values> struct Inner; }; This new implementation approach introduces the notion of an "expanded" non-type template parameter pack, for which we have already expanded the types of the parameter pack (to, say, "int*, float*", for Outer<int*, float*>) but have not yet expanded the values. Aside from creating these expanded non-type template parameter packs, this patch updates template argument checking and non-type template parameter pack instantiation to make use of the appropriate types in the parameter pack. llvm-svn: 123845
2011-01-20 04:10:05 +08:00
TemplateArgs,
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Expand, RetainExpansion,
Implement support for non-type template parameter packs whose type is a pack expansion, e.g., the parameter pack Values in: template<typename ...Types> struct Outer { template<Types ...Values> struct Inner; }; This new implementation approach introduces the notion of an "expanded" non-type template parameter pack, for which we have already expanded the types of the parameter pack (to, say, "int*, float*", for Outer<int*, float*>) but have not yet expanded the values. Aside from creating these expanded non-type template parameter packs, this patch updates template argument checking and non-type template parameter pack instantiation to make use of the appropriate types in the parameter pack. llvm-svn: 123845
2011-01-20 04:10:05 +08:00
NumExpansions))
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Implement support for non-type template parameter packs whose type is a pack expansion, e.g., the parameter pack Values in: template<typename ...Types> struct Outer { template<Types ...Values> struct Inner; }; This new implementation approach introduces the notion of an "expanded" non-type template parameter pack, for which we have already expanded the types of the parameter pack (to, say, "int*, float*", for Outer<int*, float*>) but have not yet expanded the values. Aside from creating these expanded non-type template parameter packs, this patch updates template argument checking and non-type template parameter pack instantiation to make use of the appropriate types in the parameter pack. llvm-svn: 123845
2011-01-20 04:10:05 +08:00
if (Expand) {
for (unsigned I = 0; I != *NumExpansions; ++I) {
Sema::ArgumentPackSubstitutionIndexRAII SubstIndex(SemaRef, I);
TypeSourceInfo *NewDI = SemaRef.SubstType(Pattern, TemplateArgs,
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
D->getLocation(),
Implement support for non-type template parameter packs whose type is a pack expansion, e.g., the parameter pack Values in: template<typename ...Types> struct Outer { template<Types ...Values> struct Inner; }; This new implementation approach introduces the notion of an "expanded" non-type template parameter pack, for which we have already expanded the types of the parameter pack (to, say, "int*, float*", for Outer<int*, float*>) but have not yet expanded the values. Aside from creating these expanded non-type template parameter packs, this patch updates template argument checking and non-type template parameter pack instantiation to make use of the appropriate types in the parameter pack. llvm-svn: 123845
2011-01-20 04:10:05 +08:00
D->getDeclName());
if (!NewDI)
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Mark 'auto' as dependent when instantiating the type of a non-type template parameter. Fixes failed deduction for 'auto' non-type template parameters nested within templates. llvm-svn: 290660
2016-12-28 14:27:18 +08:00
QualType NewT =
SemaRef.CheckNonTypeTemplateParameterType(NewDI, D->getLocation());
Implement support for non-type template parameter packs whose type is a pack expansion, e.g., the parameter pack Values in: template<typename ...Types> struct Outer { template<Types ...Values> struct Inner; }; This new implementation approach introduces the notion of an "expanded" non-type template parameter pack, for which we have already expanded the types of the parameter pack (to, say, "int*, float*", for Outer<int*, float*>) but have not yet expanded the values. Aside from creating these expanded non-type template parameter packs, this patch updates template argument checking and non-type template parameter pack instantiation to make use of the appropriate types in the parameter pack. llvm-svn: 123845
2011-01-20 04:10:05 +08:00
if (NewT.isNull())
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Mark 'auto' as dependent when instantiating the type of a non-type template parameter. Fixes failed deduction for 'auto' non-type template parameters nested within templates. llvm-svn: 290660
2016-12-28 14:27:18 +08:00
ExpandedParameterPackTypesAsWritten.push_back(NewDI);
Implement support for non-type template parameter packs whose type is a pack expansion, e.g., the parameter pack Values in: template<typename ...Types> struct Outer { template<Types ...Values> struct Inner; }; This new implementation approach introduces the notion of an "expanded" non-type template parameter pack, for which we have already expanded the types of the parameter pack (to, say, "int*, float*", for Outer<int*, float*>) but have not yet expanded the values. Aside from creating these expanded non-type template parameter packs, this patch updates template argument checking and non-type template parameter pack instantiation to make use of the appropriate types in the parameter pack. llvm-svn: 123845
2011-01-20 04:10:05 +08:00
ExpandedParameterPackTypes.push_back(NewT);
}
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Implement support for non-type template parameter packs whose type is a pack expansion, e.g., the parameter pack Values in: template<typename ...Types> struct Outer { template<Types ...Values> struct Inner; }; This new implementation approach introduces the notion of an "expanded" non-type template parameter pack, for which we have already expanded the types of the parameter pack (to, say, "int*, float*", for Outer<int*, float*>) but have not yet expanded the values. Aside from creating these expanded non-type template parameter packs, this patch updates template argument checking and non-type template parameter pack instantiation to make use of the appropriate types in the parameter pack. llvm-svn: 123845
2011-01-20 04:10:05 +08:00
// Note that we have an expanded parameter pack. The "type" of this
// expanded parameter pack is the original expansion type, but callers
// will end up using the expanded parameter pack types for type-checking.
IsExpandedParameterPack = true;
DI = D->getTypeSourceInfo();
T = DI->getType();
} else {
// We cannot fully expand the pack expansion now, so substitute into the
// pattern and create a new pack expansion type.
Sema::ArgumentPackSubstitutionIndexRAII SubstIndex(SemaRef, -1);
TypeSourceInfo *NewPattern = SemaRef.SubstType(Pattern, TemplateArgs,
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
D->getLocation(),
Implement support for non-type template parameter packs whose type is a pack expansion, e.g., the parameter pack Values in: template<typename ...Types> struct Outer { template<Types ...Values> struct Inner; }; This new implementation approach introduces the notion of an "expanded" non-type template parameter pack, for which we have already expanded the types of the parameter pack (to, say, "int*, float*", for Outer<int*, float*>) but have not yet expanded the values. Aside from creating these expanded non-type template parameter packs, this patch updates template argument checking and non-type template parameter pack instantiation to make use of the appropriate types in the parameter pack. llvm-svn: 123845
2011-01-20 04:10:05 +08:00
D->getDeclName());
if (!NewPattern)
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Mark 'auto' as dependent when instantiating the type of a non-type template parameter. Fixes failed deduction for 'auto' non-type template parameters nested within templates. llvm-svn: 290660
2016-12-28 14:27:18 +08:00
SemaRef.CheckNonTypeTemplateParameterType(NewPattern, D->getLocation());
Implement support for non-type template parameter packs whose type is a pack expansion, e.g., the parameter pack Values in: template<typename ...Types> struct Outer { template<Types ...Values> struct Inner; }; This new implementation approach introduces the notion of an "expanded" non-type template parameter pack, for which we have already expanded the types of the parameter pack (to, say, "int*, float*", for Outer<int*, float*>) but have not yet expanded the values. Aside from creating these expanded non-type template parameter packs, this patch updates template argument checking and non-type template parameter pack instantiation to make use of the appropriate types in the parameter pack. llvm-svn: 123845
2011-01-20 04:10:05 +08:00
DI = SemaRef.CheckPackExpansion(NewPattern, Expansion.getEllipsisLoc(),
NumExpansions);
if (!DI)
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Implement support for non-type template parameter packs whose type is a pack expansion, e.g., the parameter pack Values in: template<typename ...Types> struct Outer { template<Types ...Values> struct Inner; }; This new implementation approach introduces the notion of an "expanded" non-type template parameter pack, for which we have already expanded the types of the parameter pack (to, say, "int*, float*", for Outer<int*, float*>) but have not yet expanded the values. Aside from creating these expanded non-type template parameter packs, this patch updates template argument checking and non-type template parameter pack instantiation to make use of the appropriate types in the parameter pack. llvm-svn: 123845
2011-01-20 04:10:05 +08:00
T = DI->getType();
}
} else {
// Simple case: substitution into a parameter that is not a parameter pack.
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
DI = SemaRef.SubstType(D->getTypeSourceInfo(), TemplateArgs,
Implement support for non-type template parameter packs whose type is a pack expansion, e.g., the parameter pack Values in: template<typename ...Types> struct Outer { template<Types ...Values> struct Inner; }; This new implementation approach introduces the notion of an "expanded" non-type template parameter pack, for which we have already expanded the types of the parameter pack (to, say, "int*, float*", for Outer<int*, float*>) but have not yet expanded the values. Aside from creating these expanded non-type template parameter packs, this patch updates template argument checking and non-type template parameter pack instantiation to make use of the appropriate types in the parameter pack. llvm-svn: 123845
2011-01-20 04:10:05 +08:00
D->getLocation(), D->getDeclName());
if (!DI)
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Implement support for non-type template parameter packs whose type is a pack expansion, e.g., the parameter pack Values in: template<typename ...Types> struct Outer { template<Types ...Values> struct Inner; }; This new implementation approach introduces the notion of an "expanded" non-type template parameter pack, for which we have already expanded the types of the parameter pack (to, say, "int*, float*", for Outer<int*, float*>) but have not yet expanded the values. Aside from creating these expanded non-type template parameter packs, this patch updates template argument checking and non-type template parameter pack instantiation to make use of the appropriate types in the parameter pack. llvm-svn: 123845
2011-01-20 04:10:05 +08:00
// Check that this type is acceptable for a non-type template parameter.
Mark 'auto' as dependent when instantiating the type of a non-type template parameter. Fixes failed deduction for 'auto' non-type template parameters nested within templates. llvm-svn: 290660
2016-12-28 14:27:18 +08:00
T = SemaRef.CheckNonTypeTemplateParameterType(DI, D->getLocation());
Implement support for non-type template parameter packs whose type is a pack expansion, e.g., the parameter pack Values in: template<typename ...Types> struct Outer { template<Types ...Values> struct Inner; }; This new implementation approach introduces the notion of an "expanded" non-type template parameter pack, for which we have already expanded the types of the parameter pack (to, say, "int*, float*", for Outer<int*, float*>) but have not yet expanded the values. Aside from creating these expanded non-type template parameter packs, this patch updates template argument checking and non-type template parameter pack instantiation to make use of the appropriate types in the parameter pack. llvm-svn: 123845
2011-01-20 04:10:05 +08:00
if (T.isNull()) {
T = SemaRef.Context.IntTy;
Invalid = true;
}
Implement template instantiation for non-type template parameters. Fixes PR5103. llvm-svn: 84979
2009-10-24 07:25:44 +08:00
}
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Implement support for non-type template parameter packs whose type is a pack expansion, e.g., the parameter pack Values in: template<typename ...Types> struct Outer { template<Types ...Values> struct Inner; }; This new implementation approach introduces the notion of an "expanded" non-type template parameter pack, for which we have already expanded the types of the parameter pack (to, say, "int*, float*", for Outer<int*, float*>) but have not yet expanded the values. Aside from creating these expanded non-type template parameter packs, this patch updates template argument checking and non-type template parameter pack instantiation to make use of the appropriate types in the parameter pack. llvm-svn: 123845
2011-01-20 04:10:05 +08:00
NonTypeTemplateParmDecl *Param;
if (IsExpandedParameterPack)
[AST] Use ArrayRef in more interfaces ArrayRef is a little better than passing around a pointer/length pair. No functional change is intended. llvm-svn: 274601
2016-07-06 12:19:16 +08:00
Param = NonTypeTemplateParmDecl::Create(
SemaRef.Context, Owner, D->getInnerLocStart(), D->getLocation(),
PR32010: Fix template argument depth mixup when forming implicit constructor template deduction guides for class template argument deduction. Ensure that we have a local instantiation scope for tracking the instantiated parameters. Additionally, unusually, we're substituting at depth 1 and leaving depth 0 alone; make sure that we don't reduce template parameter depth by 2 for inner parameters in the process. (This is probably also broken for alias templates in the case where they're expanded within a dependent context, but this patch doesn't fix that.) llvm-svn: 295696
2017-02-21 14:30:38 +08:00
D->getDepth() - TemplateArgs.getNumSubstitutedLevels(),
D->getPosition(), D->getIdentifier(), T, DI, ExpandedParameterPackTypes,
[AST] Use ArrayRef in more interfaces ArrayRef is a little better than passing around a pointer/length pair. No functional change is intended. llvm-svn: 274601
2016-07-06 12:19:16 +08:00
ExpandedParameterPackTypesAsWritten);
Implement support for non-type template parameter packs whose type is a pack expansion, e.g., the parameter pack Values in: template<typename ...Types> struct Outer { template<Types ...Values> struct Inner; }; This new implementation approach introduces the notion of an "expanded" non-type template parameter pack, for which we have already expanded the types of the parameter pack (to, say, "int*, float*", for Outer<int*, float*>) but have not yet expanded the values. Aside from creating these expanded non-type template parameter packs, this patch updates template argument checking and non-type template parameter pack instantiation to make use of the appropriate types in the parameter pack. llvm-svn: 123845
2011-01-20 04:10:05 +08:00
else
PR32010: Fix template argument depth mixup when forming implicit constructor template deduction guides for class template argument deduction. Ensure that we have a local instantiation scope for tracking the instantiated parameters. Additionally, unusually, we're substituting at depth 1 and leaving depth 0 alone; make sure that we don't reduce template parameter depth by 2 for inner parameters in the process. (This is probably also broken for alias templates in the case where they're expanded within a dependent context, but this patch doesn't fix that.) llvm-svn: 295696
2017-02-21 14:30:38 +08:00
Param = NonTypeTemplateParmDecl::Create(
SemaRef.Context, Owner, D->getInnerLocStart(), D->getLocation(),
D->getDepth() - TemplateArgs.getNumSubstitutedLevels(),
D->getPosition(), D->getIdentifier(), T, D->isParameterPack(), DI);
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Make sure to put template parameters into their owning template's DeclContext once we've created it. This mirrors what we do for function parameters, where the parameters start out with translation-unit context and then are adopted by the appropriate DeclContext when it is created. Also give template parameters public access and make sure that they don't show up for the purposes of name lookup. Fixes PR9400, a regression introduced by r126920, which implemented substitution of default template arguments provided in template template parameters (C++ core issue 150). How on earth could the DeclContext of a template parameter affect the handling of default template arguments? I'm so glad you asked! The link is Sema::getTemplateInstantiationArgs(), which determines the outer template argument lists that correspond to a given declaration. When we're instantiating a default template argument for a template template parameter within the body of a template definition (not it's instantiation, per core issue 150), we weren't getting any outer template arguments because the context of the template template parameter was the translation unit. Now that the context of the template template parameter is its owning template, we get the template arguments from the injected-class-name of the owning template, so substitution works as it should. llvm-svn: 127004
2011-03-05 01:52:15 +08:00
Param->setAccess(AS_public);
Implement template instantiation for non-type template parameters. Fixes PR5103. llvm-svn: 84979
2009-10-24 07:25:44 +08:00
if (Invalid)
Param->setInvalidDecl();
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
[modules] Fix merging of default template arguments onto friend templates. Previously we'd complain about redefinition of default arguments when we instantiated a class with a friend template that inherits its default argument, because we propagate the default template arguemnt onto the friend when we reload the AST. llvm-svn: 239857
2015-06-17 05:57:05 +08:00
if (D->hasDefaultArgument() && !D->defaultArgumentWasInherited()) {
[NFC, Scoped Enum] Convert Sema::ExpressionEvaluationContext into a scoped Enum - also replace direct equality checks against the ConstantEvaluated enumerator with isConstantEvaluted(), in anticipation of adding finer granularity to the various ConstantEvaluated contexts and reinstating certain restrictions on where lambda expressions can occur in C++17. - update the clang tablegen backend that uses these Enumerators, and add the relevant scope where needed. llvm-svn: 299316
2017-04-02 05:30:49 +08:00
EnterExpressionEvaluationContext ConstantEvaluated(
SemaRef, Sema::ExpressionEvaluationContext::ConstantEvaluated);
Sema: Subst type default template args earlier Summary: We would not perform substitution at an appropriate point, allowing strange results to appear. We would accepts things that we shouldn't or mangle things incorrectly. Note that this hasn't fixed the other cases like template-template parameters or non-type template parameters. Reviewers: doug.gregor, rjmccall, rsmith Reviewed By: rsmith CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1507 llvm-svn: 189540
2013-08-29 07:48:32 +08:00
ExprResult Value = SemaRef.SubstExpr(D->getDefaultArgument(), TemplateArgs);
if (!Value.isInvalid())
Refactor storage of default template arguments. This is just a preparatory step towards fixing visibility for default template arguments in modules builds. llvm-svn: 239447
2015-06-10 08:29:03 +08:00
Param->setDefaultArgument(Value.get());
Sema: Subst type default template args earlier Summary: We would not perform substitution at an appropriate point, allowing strange results to appear. We would accepts things that we shouldn't or mangle things incorrectly. Note that this hasn't fixed the other cases like template-template parameters or non-type template parameters. Reviewers: doug.gregor, rjmccall, rsmith Reviewed By: rsmith CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1507 llvm-svn: 189540
2013-08-29 07:48:32 +08:00
}
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
// Introduce this template parameter's instantiation into the instantiation
Implement "incremental" template instantiation for non-type template parameters and template type parameters, which occurs when substituting into the declarations of member templates inside class templates. This eliminates errors about our inability to "reduce non-type template parameter depth", fixing PR5311. Also fixes a bug when instantiating a template type parameter declaration in a member template, where we weren't properly reducing the template parameter's depth. LLVM's StringSwitch header now parses. llvm-svn: 85669
2009-11-01 01:21:17 +08:00
// scope.
SemaRef.CurrentInstantiationScope->InstantiatedLocal(D, Param);
Implement template instantiation for non-type template parameters. Fixes PR5103. llvm-svn: 84979
2009-10-24 07:25:44 +08:00
return Param;
}
PR9023: A template template parameter whose template parameter list contains an unexpanded parameter pack is a pack expansion. Thus, as with a non-type template parameter which is a pack expansion, it needs to be expanded early into a fixed list of template parameters. Since the expanded list of template parameters is not itself a parameter pack, it is permitted to appear before the end of the template parameter list, so also remove that restriction (for both template template parameter pack expansions and non-type template parameter pack expansions). llvm-svn: 163369
2012-09-07 10:06:42 +08:00
static void collectUnexpandedParameterPacks(
Sema &S,
TemplateParameterList *Params,
SmallVectorImpl<UnexpandedParameterPack> &Unexpanded) {
[Sema] Range-loopify SemaTemplateInstantiateDecl.cpp. NFC. llvm-svn: 241291
2015-07-03 03:20:11 +08:00
for (const auto &P : *Params) {
if (P->isTemplateParameterPack())
PR9023: A template template parameter whose template parameter list contains an unexpanded parameter pack is a pack expansion. Thus, as with a non-type template parameter which is a pack expansion, it needs to be expanded early into a fixed list of template parameters. Since the expanded list of template parameters is not itself a parameter pack, it is permitted to appear before the end of the template parameter list, so also remove that restriction (for both template template parameter pack expansions and non-type template parameter pack expansions). llvm-svn: 163369
2012-09-07 10:06:42 +08:00
continue;
[Sema] Range-loopify SemaTemplateInstantiateDecl.cpp. NFC. llvm-svn: 241291
2015-07-03 03:20:11 +08:00
if (NonTypeTemplateParmDecl *NTTP = dyn_cast<NonTypeTemplateParmDecl>(P))
PR9023: A template template parameter whose template parameter list contains an unexpanded parameter pack is a pack expansion. Thus, as with a non-type template parameter which is a pack expansion, it needs to be expanded early into a fixed list of template parameters. Since the expanded list of template parameters is not itself a parameter pack, it is permitted to appear before the end of the template parameter list, so also remove that restriction (for both template template parameter pack expansions and non-type template parameter pack expansions). llvm-svn: 163369
2012-09-07 10:06:42 +08:00
S.collectUnexpandedParameterPacks(NTTP->getTypeSourceInfo()->getTypeLoc(),
Unexpanded);
[Sema] Range-loopify SemaTemplateInstantiateDecl.cpp. NFC. llvm-svn: 241291
2015-07-03 03:20:11 +08:00
if (TemplateTemplateParmDecl *TTP = dyn_cast<TemplateTemplateParmDecl>(P))
PR9023: A template template parameter whose template parameter list contains an unexpanded parameter pack is a pack expansion. Thus, as with a non-type template parameter which is a pack expansion, it needs to be expanded early into a fixed list of template parameters. Since the expanded list of template parameters is not itself a parameter pack, it is permitted to appear before the end of the template parameter list, so also remove that restriction (for both template template parameter pack expansions and non-type template parameter pack expansions). llvm-svn: 163369
2012-09-07 10:06:42 +08:00
collectUnexpandedParameterPacks(S, TTP->getTemplateParameters(),
Unexpanded);
}
}
Instantiation of template template parameters for nested templates, e.g., template<typename T> struct X { template<template<T Value> class Y> struct Inner; }; llvm-svn: 86844
2009-11-12 00:58:32 +08:00
Decl *
TemplateDeclInstantiator::VisitTemplateTemplateParmDecl(
TemplateTemplateParmDecl *D) {
// Instantiate the template parameter list of the template template parameter.
TemplateParameterList *TempParams = D->getTemplateParameters();
TemplateParameterList *InstParams;
PR9023: A template template parameter whose template parameter list contains an unexpanded parameter pack is a pack expansion. Thus, as with a non-type template parameter which is a pack expansion, it needs to be expanded early into a fixed list of template parameters. Since the expanded list of template parameters is not itself a parameter pack, it is permitted to appear before the end of the template parameter list, so also remove that restriction (for both template template parameter pack expansions and non-type template parameter pack expansions). llvm-svn: 163369
2012-09-07 10:06:42 +08:00
SmallVector<TemplateParameterList*, 8> ExpandedParams;
bool IsExpandedParameterPack = false;
if (D->isExpandedParameterPack()) {
// The template template parameter pack is an already-expanded pack
// expansion of template parameters. Substitute into each of the expanded
// parameters.
ExpandedParams.reserve(D->getNumExpansionTemplateParameters());
for (unsigned I = 0, N = D->getNumExpansionTemplateParameters();
I != N; ++I) {
LocalInstantiationScope Scope(SemaRef);
TemplateParameterList *Expansion =
SubstTemplateParams(D->getExpansionTemplateParameters(I));
if (!Expansion)
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
PR9023: A template template parameter whose template parameter list contains an unexpanded parameter pack is a pack expansion. Thus, as with a non-type template parameter which is a pack expansion, it needs to be expanded early into a fixed list of template parameters. Since the expanded list of template parameters is not itself a parameter pack, it is permitted to appear before the end of the template parameter list, so also remove that restriction (for both template template parameter pack expansions and non-type template parameter pack expansions). llvm-svn: 163369
2012-09-07 10:06:42 +08:00
ExpandedParams.push_back(Expansion);
}
IsExpandedParameterPack = true;
InstParams = TempParams;
} else if (D->isPackExpansion()) {
// The template template parameter pack expands to a pack of template
// template parameters. Determine whether we need to expand this parameter
// pack into separate parameters.
SmallVector<UnexpandedParameterPack, 2> Unexpanded;
collectUnexpandedParameterPacks(SemaRef, D->getTemplateParameters(),
Unexpanded);
// Determine whether the set of unexpanded parameter packs can and should
// be expanded.
bool Expand = true;
bool RetainExpansion = false;
Include llvm::Optional in clang/Basic/LLVM.h Post-commit CR feedback from Jordan Rose regarding r175594. llvm-svn: 175679
2013-02-21 06:23:23 +08:00
Optional<unsigned> NumExpansions;
PR9023: A template template parameter whose template parameter list contains an unexpanded parameter pack is a pack expansion. Thus, as with a non-type template parameter which is a pack expansion, it needs to be expanded early into a fixed list of template parameters. Since the expanded list of template parameters is not itself a parameter pack, it is permitted to appear before the end of the template parameter list, so also remove that restriction (for both template template parameter pack expansions and non-type template parameter pack expansions). llvm-svn: 163369
2012-09-07 10:06:42 +08:00
if (SemaRef.CheckParameterPacksForExpansion(D->getLocation(),
TempParams->getSourceRange(),
Unexpanded,
TemplateArgs,
Expand, RetainExpansion,
NumExpansions))
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
PR9023: A template template parameter whose template parameter list contains an unexpanded parameter pack is a pack expansion. Thus, as with a non-type template parameter which is a pack expansion, it needs to be expanded early into a fixed list of template parameters. Since the expanded list of template parameters is not itself a parameter pack, it is permitted to appear before the end of the template parameter list, so also remove that restriction (for both template template parameter pack expansions and non-type template parameter pack expansions). llvm-svn: 163369
2012-09-07 10:06:42 +08:00
if (Expand) {
for (unsigned I = 0; I != *NumExpansions; ++I) {
Sema::ArgumentPackSubstitutionIndexRAII SubstIndex(SemaRef, I);
LocalInstantiationScope Scope(SemaRef);
TemplateParameterList *Expansion = SubstTemplateParams(TempParams);
if (!Expansion)
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
PR9023: A template template parameter whose template parameter list contains an unexpanded parameter pack is a pack expansion. Thus, as with a non-type template parameter which is a pack expansion, it needs to be expanded early into a fixed list of template parameters. Since the expanded list of template parameters is not itself a parameter pack, it is permitted to appear before the end of the template parameter list, so also remove that restriction (for both template template parameter pack expansions and non-type template parameter pack expansions). llvm-svn: 163369
2012-09-07 10:06:42 +08:00
ExpandedParams.push_back(Expansion);
}
// Note that we have an expanded parameter pack. The "type" of this
// expanded parameter pack is the original expansion type, but callers
// will end up using the expanded parameter pack types for type-checking.
IsExpandedParameterPack = true;
InstParams = TempParams;
} else {
// We cannot fully expand the pack expansion now, so just substitute
// into the pattern.
Sema::ArgumentPackSubstitutionIndexRAII SubstIndex(SemaRef, -1);
LocalInstantiationScope Scope(SemaRef);
InstParams = SubstTemplateParams(TempParams);
if (!InstParams)
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
PR9023: A template template parameter whose template parameter list contains an unexpanded parameter pack is a pack expansion. Thus, as with a non-type template parameter which is a pack expansion, it needs to be expanded early into a fixed list of template parameters. Since the expanded list of template parameters is not itself a parameter pack, it is permitted to appear before the end of the template parameter list, so also remove that restriction (for both template template parameter pack expansions and non-type template parameter pack expansions). llvm-svn: 163369
2012-09-07 10:06:42 +08:00
}
} else {
Instantiation of template template parameters for nested templates, e.g., template<typename T> struct X { template<template<T Value> class Y> struct Inner; }; llvm-svn: 86844
2009-11-12 00:58:32 +08:00
// Perform the actual substitution of template parameters within a new,
// local instantiation scope.
Move more stuff out of Sema.h. llvm-svn: 112026
2010-08-25 13:32:35 +08:00
LocalInstantiationScope Scope(SemaRef);
Instantiation of template template parameters for nested templates, e.g., template<typename T> struct X { template<template<T Value> class Y> struct Inner; }; llvm-svn: 86844
2009-11-12 00:58:32 +08:00
InstParams = SubstTemplateParams(TempParams);
if (!InstParams)
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
}
Instantiation of template template parameters for nested templates, e.g., template<typename T> struct X { template<template<T Value> class Y> struct Inner; }; llvm-svn: 86844
2009-11-12 00:58:32 +08:00
// Build the template template parameter.
PR9023: A template template parameter whose template parameter list contains an unexpanded parameter pack is a pack expansion. Thus, as with a non-type template parameter which is a pack expansion, it needs to be expanded early into a fixed list of template parameters. Since the expanded list of template parameters is not itself a parameter pack, it is permitted to appear before the end of the template parameter list, so also remove that restriction (for both template template parameter pack expansions and non-type template parameter pack expansions). llvm-svn: 163369
2012-09-07 10:06:42 +08:00
TemplateTemplateParmDecl *Param;
if (IsExpandedParameterPack)
PR32010: Fix template argument depth mixup when forming implicit constructor template deduction guides for class template argument deduction. Ensure that we have a local instantiation scope for tracking the instantiated parameters. Additionally, unusually, we're substituting at depth 1 and leaving depth 0 alone; make sure that we don't reduce template parameter depth by 2 for inner parameters in the process. (This is probably also broken for alias templates in the case where they're expanded within a dependent context, but this patch doesn't fix that.) llvm-svn: 295696
2017-02-21 14:30:38 +08:00
Param = TemplateTemplateParmDecl::Create(
SemaRef.Context, Owner, D->getLocation(),
D->getDepth() - TemplateArgs.getNumSubstitutedLevels(),
D->getPosition(), D->getIdentifier(), InstParams, ExpandedParams);
PR9023: A template template parameter whose template parameter list contains an unexpanded parameter pack is a pack expansion. Thus, as with a non-type template parameter which is a pack expansion, it needs to be expanded early into a fixed list of template parameters. Since the expanded list of template parameters is not itself a parameter pack, it is permitted to appear before the end of the template parameter list, so also remove that restriction (for both template template parameter pack expansions and non-type template parameter pack expansions). llvm-svn: 163369
2012-09-07 10:06:42 +08:00
else
PR32010: Fix template argument depth mixup when forming implicit constructor template deduction guides for class template argument deduction. Ensure that we have a local instantiation scope for tracking the instantiated parameters. Additionally, unusually, we're substituting at depth 1 and leaving depth 0 alone; make sure that we don't reduce template parameter depth by 2 for inner parameters in the process. (This is probably also broken for alias templates in the case where they're expanded within a dependent context, but this patch doesn't fix that.) llvm-svn: 295696
2017-02-21 14:30:38 +08:00
Param = TemplateTemplateParmDecl::Create(
SemaRef.Context, Owner, D->getLocation(),
D->getDepth() - TemplateArgs.getNumSubstitutedLevels(),
D->getPosition(), D->isParameterPack(), D->getIdentifier(), InstParams);
[modules] Fix merging of default template arguments onto friend templates. Previously we'd complain about redefinition of default arguments when we instantiated a class with a friend template that inherits its default argument, because we propagate the default template arguemnt onto the friend when we reload the AST. llvm-svn: 239857
2015-06-17 05:57:05 +08:00
if (D->hasDefaultArgument() && !D->defaultArgumentWasInherited()) {
Sema: Subst type default template args earlier Summary: We would not perform substitution at an appropriate point, allowing strange results to appear. We would accepts things that we shouldn't or mangle things incorrectly. Note that this hasn't fixed the other cases like template-template parameters or non-type template parameters. Reviewers: doug.gregor, rjmccall, rsmith Reviewed By: rsmith CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1507 llvm-svn: 189540
2013-08-29 07:48:32 +08:00
NestedNameSpecifierLoc QualifierLoc =
D->getDefaultArgument().getTemplateQualifierLoc();
QualifierLoc =
SemaRef.SubstNestedNameSpecifierLoc(QualifierLoc, TemplateArgs);
TemplateName TName = SemaRef.SubstTemplateName(
QualifierLoc, D->getDefaultArgument().getArgument().getAsTemplate(),
D->getDefaultArgument().getTemplateNameLoc(), TemplateArgs);
if (!TName.isNull())
Param->setDefaultArgument(
Refactor storage of default template arguments. This is just a preparatory step towards fixing visibility for default template arguments in modules builds. llvm-svn: 239447
2015-06-10 08:29:03 +08:00
SemaRef.Context,
Sema: Subst type default template args earlier Summary: We would not perform substitution at an appropriate point, allowing strange results to appear. We would accepts things that we shouldn't or mangle things incorrectly. Note that this hasn't fixed the other cases like template-template parameters or non-type template parameters. Reviewers: doug.gregor, rjmccall, rsmith Reviewed By: rsmith CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1507 llvm-svn: 189540
2013-08-29 07:48:32 +08:00
TemplateArgumentLoc(TemplateArgument(TName),
D->getDefaultArgument().getTemplateQualifierLoc(),
Refactor storage of default template arguments. This is just a preparatory step towards fixing visibility for default template arguments in modules builds. llvm-svn: 239447
2015-06-10 08:29:03 +08:00
D->getDefaultArgument().getTemplateNameLoc()));
Sema: Subst type default template args earlier Summary: We would not perform substitution at an appropriate point, allowing strange results to appear. We would accepts things that we shouldn't or mangle things incorrectly. Note that this hasn't fixed the other cases like template-template parameters or non-type template parameters. Reviewers: doug.gregor, rjmccall, rsmith Reviewed By: rsmith CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1507 llvm-svn: 189540
2013-08-29 07:48:32 +08:00
}
Make sure to put template parameters into their owning template's DeclContext once we've created it. This mirrors what we do for function parameters, where the parameters start out with translation-unit context and then are adopted by the appropriate DeclContext when it is created. Also give template parameters public access and make sure that they don't show up for the purposes of name lookup. Fixes PR9400, a regression introduced by r126920, which implemented substitution of default template arguments provided in template template parameters (C++ core issue 150). How on earth could the DeclContext of a template parameter affect the handling of default template arguments? I'm so glad you asked! The link is Sema::getTemplateInstantiationArgs(), which determines the outer template argument lists that correspond to a given declaration. When we're instantiating a default template argument for a template template parameter within the body of a template definition (not it's instantiation, per core issue 150), we weren't getting any outer template arguments because the context of the template template parameter was the translation unit. Now that the context of the template template parameter is its owning template, we get the template arguments from the injected-class-name of the owning template, so substitution works as it should. llvm-svn: 127004
2011-03-05 01:52:15 +08:00
Param->setAccess(AS_public);
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
// Introduce this template parameter's instantiation into the instantiation
Instantiation of template template parameters for nested templates, e.g., template<typename T> struct X { template<template<T Value> class Y> struct Inner; }; llvm-svn: 86844
2009-11-12 00:58:32 +08:00
// scope.
SemaRef.CurrentInstantiationScope->InstantiatedLocal(D, Param);
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Instantiation of template template parameters for nested templates, e.g., template<typename T> struct X { template<template<T Value> class Y> struct Inner; }; llvm-svn: 86844
2009-11-12 00:58:32 +08:00
return Param;
}
Implement template instantiation for using directives, which is dead simple. Also, make the "don't know how to instantiate a particular kind of declaration" diagnostic nicer, so we don't have to trap Clang in a debugger to figure out what went wrong. llvm-svn: 89050
2009-11-17 14:07:40 +08:00
Decl *TemplateDeclInstantiator::VisitUsingDirectiveDecl(UsingDirectiveDecl *D) {
Push nested-name-specifier source location information into using directives. llvm-svn: 126489
2011-02-26 00:33:46 +08:00
// Using directives are never dependent (and never contain any types or
// expressions), so they require no explicit instantiation work.
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Implement template instantiation for using directives, which is dead simple. Also, make the "don't know how to instantiate a particular kind of declaration" diagnostic nicer, so we don't have to trap Clang in a debugger to figure out what went wrong. llvm-svn: 89050
2009-11-17 14:07:40 +08:00
UsingDirectiveDecl *Inst
= UsingDirectiveDecl::Create(SemaRef.Context, Owner, D->getLocation(),
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
D->getNamespaceKeyLocation(),
Push nested-name-specifier source location information into using directives. llvm-svn: 126489
2011-02-26 00:33:46 +08:00
D->getQualifierLoc(),
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
D->getIdentLocation(),
D->getNominatedNamespace(),
Implement template instantiation for using directives, which is dead simple. Also, make the "don't know how to instantiate a particular kind of declaration" diagnostic nicer, so we don't have to trap Clang in a debugger to figure out what went wrong. llvm-svn: 89050
2009-11-17 14:07:40 +08:00
D->getCommonAncestor());
Do not add using directives to a function decl context when instantiating. llvm-svn: 163208
2012-09-05 17:55:10 +08:00
// Add the using directive to its declaration context
// only if this is not a function or method.
if (!Owner->isFunctionOrMethod())
Owner->addDecl(Inst);
Implement template instantiation for using directives, which is dead simple. Also, make the "don't know how to instantiate a particular kind of declaration" diagnostic nicer, so we don't have to trap Clang in a debugger to figure out what went wrong. llvm-svn: 89050
2009-11-17 14:07:40 +08:00
return Inst;
}
Fix "using typename" and the instantiation of non-dependent using declarations. llvm-svn: 90614
2009-12-05 06:46:56 +08:00
Decl *TemplateDeclInstantiator::VisitUsingDecl(UsingDecl *D) {
Fix handling of dependent nested namespace specifiers in UsingDecls during template instantiation, from Martin Vejnar! llvm-svn: 115051
2010-09-30 01:58:28 +08:00
// The nested name specifier may be dependent, for example
// template <typename T> struct t {
// struct s1 { T f1(); };
// struct s2 : s1 { using s1::f1; };
// };
// template struct t<int>;
// Here, in using s1::f1, s1 refers to t<T>::s1;
// we need to substitute for t<int>::s1.
Maintain nested-name-specifier source-location information through instantiation of using declarations (all three forms). llvm-svn: 126485
2011-02-25 23:54:31 +08:00
NestedNameSpecifierLoc QualifierLoc
= SemaRef.SubstNestedNameSpecifierLoc(D->getQualifierLoc(),
TemplateArgs);
if (!QualifierLoc)
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Fix handling of dependent nested namespace specifiers in UsingDecls during template instantiation, from Martin Vejnar! llvm-svn: 115051
2010-09-30 01:58:28 +08:00
P0136R1, DR1573, DR1645, DR1715, DR1736, DR1903, DR1941, DR1959, DR1991: Replace inheriting constructors implementation with new approach, voted into C++ last year as a DR against C++11. Instead of synthesizing a set of derived class constructors for each inherited base class constructor, we make the constructors of the base class visible to constructor lookup in the derived class, using the normal rules for using-declarations. For constructors, UsingShadowDecl now has a ConstructorUsingShadowDecl derived class that tracks the requisite additional information. We create shadow constructors (not found by name lookup) in the derived class to model the actual initialization, and have a new expression node, CXXInheritedCtorInitExpr, to model the initialization of a base class from such a constructor. (This initialization is special because it performs real perfect forwarding of arguments.) In cases where argument forwarding is not possible (for inalloca calls, variadic calls, and calls with callee parameter cleanup), the shadow inheriting constructor is not emitted and instead we directly emit the initialization code into the caller of the inherited constructor. Note that this new model is not perfectly compatible with the old model in some corner cases. In particular: * if B inherits a private constructor from A, and C uses that constructor to construct a B, then we previously required that A befriends B and B befriends C, but the new rules require A to befriend C directly, and * if a derived class has its own constructors (and so its implicit default constructor is suppressed), it may still inherit a default constructor from a base class llvm-svn: 274049
2016-06-29 03:03:57 +08:00
// For an inheriting constructor declaration, the name of the using
// declaration is the name of a constructor in this class, not in the
// base class.
Added locations and type source info for DeclarationName inside UsingDecl. llvm-svn: 110912
2010-08-12 19:46:03 +08:00
DeclarationNameInfo NameInfo = D->getNameInfo();
P0136R1, DR1573, DR1645, DR1715, DR1736, DR1903, DR1941, DR1959, DR1991: Replace inheriting constructors implementation with new approach, voted into C++ last year as a DR against C++11. Instead of synthesizing a set of derived class constructors for each inherited base class constructor, we make the constructors of the base class visible to constructor lookup in the derived class, using the normal rules for using-declarations. For constructors, UsingShadowDecl now has a ConstructorUsingShadowDecl derived class that tracks the requisite additional information. We create shadow constructors (not found by name lookup) in the derived class to model the actual initialization, and have a new expression node, CXXInheritedCtorInitExpr, to model the initialization of a base class from such a constructor. (This initialization is special because it performs real perfect forwarding of arguments.) In cases where argument forwarding is not possible (for inalloca calls, variadic calls, and calls with callee parameter cleanup), the shadow inheriting constructor is not emitted and instead we directly emit the initialization code into the caller of the inherited constructor. Note that this new model is not perfectly compatible with the old model in some corner cases. In particular: * if B inherits a private constructor from A, and C uses that constructor to construct a B, then we previously required that A befriends B and B befriends C, but the new rules require A to befriend C directly, and * if a derived class has its own constructors (and so its implicit default constructor is suppressed), it may still inherit a default constructor from a base class llvm-svn: 274049
2016-06-29 03:03:57 +08:00
if (NameInfo.getName().getNameKind() == DeclarationName::CXXConstructorName)
if (auto *RD = dyn_cast<CXXRecordDecl>(SemaRef.CurContext))
NameInfo.setName(SemaRef.Context.DeclarationNames.getCXXConstructorName(
SemaRef.Context.getCanonicalType(SemaRef.Context.getRecordType(RD))));
Fix "using typename" and the instantiation of non-dependent using declarations. llvm-svn: 90614
2009-12-05 06:46:56 +08:00
Implement redeclaration checking and hiding semantics for using declarations. There are a couple of O(n^2) operations in this, some analogous to the usual O(n^2) redeclaration problem and some not. In particular, retroactively removing shadow declarations when they're hidden by later decls is pretty unfortunate. I'm not yet convinced it's worse than the alternative, though. llvm-svn: 91045
2009-12-10 17:41:52 +08:00
// We only need to do redeclaration lookups if we're in a class
// scope (in fact, it's not really even possible in non-class
// scopes).
bool CheckRedeclaration = Owner->isRecord();
Added locations and type source info for DeclarationName inside UsingDecl. llvm-svn: 110912
2010-08-12 19:46:03 +08:00
LookupResult Prev(SemaRef, NameInfo, Sema::LookupUsingDeclName,
Sema::ForRedeclaration);
Implement redeclaration checking and hiding semantics for using declarations. There are a couple of O(n^2) operations in this, some analogous to the usual O(n^2) redeclaration problem and some not. In particular, retroactively removing shadow declarations when they're hidden by later decls is pretty unfortunate. I'm not yet convinced it's worse than the alternative, though. llvm-svn: 91045
2009-12-10 17:41:52 +08:00
Fix "using typename" and the instantiation of non-dependent using declarations. llvm-svn: 90614
2009-12-05 06:46:56 +08:00
UsingDecl *NewUD = UsingDecl::Create(SemaRef.Context, Owner,
Improve clarity/consistency of a few UsingDecl methods and related helpers. No functionality change. In Sema helper functions: * renamed isTypeName as HasTypenameKeyword In UsingDecl: * renamed get/setUsingLocation to get/setUsingLoc * renamed is/setTypeName as has/setTypename llvm-svn: 186816
2013-07-22 18:54:09 +08:00
D->getUsingLoc(),
Maintain nested-name-specifier source-location information through instantiation of using declarations (all three forms). llvm-svn: 126485
2011-02-25 23:54:31 +08:00
QualifierLoc,
Added locations and type source info for DeclarationName inside UsingDecl. llvm-svn: 110912
2010-08-12 19:46:03 +08:00
NameInfo,
Improve clarity/consistency of a few UsingDecl methods and related helpers. No functionality change. In Sema helper functions: * renamed isTypeName as HasTypenameKeyword In UsingDecl: * renamed get/setUsingLocation to get/setUsingLoc * renamed is/setTypeName as has/setTypename llvm-svn: 186816
2013-07-22 18:54:09 +08:00
D->hasTypename());
Fix "using typename" and the instantiation of non-dependent using declarations. llvm-svn: 90614
2009-12-05 06:46:56 +08:00
Maintain nested-name-specifier source-location information through instantiation of using declarations (all three forms). llvm-svn: 126485
2011-02-25 23:54:31 +08:00
CXXScopeSpec SS;
SS.Adopt(QualifierLoc);
Implement redeclaration checking and hiding semantics for using declarations. There are a couple of O(n^2) operations in this, some analogous to the usual O(n^2) redeclaration problem and some not. In particular, retroactively removing shadow declarations when they're hidden by later decls is pretty unfortunate. I'm not yet convinced it's worse than the alternative, though. llvm-svn: 91045
2009-12-10 17:41:52 +08:00
if (CheckRedeclaration) {
Prev.setHideTags(false);
SemaRef.LookupQualifiedName(Prev, Owner);
// Check for invalid redeclarations.
Improve clarity/consistency of a few UsingDecl methods and related helpers. No functionality change. In Sema helper functions: * renamed isTypeName as HasTypenameKeyword In UsingDecl: * renamed get/setUsingLocation to get/setUsingLoc * renamed is/setTypeName as has/setTypename llvm-svn: 186816
2013-07-22 18:54:09 +08:00
if (SemaRef.CheckUsingDeclRedeclaration(D->getUsingLoc(),
D->hasTypename(), SS,
Implement redeclaration checking and hiding semantics for using declarations. There are a couple of O(n^2) operations in this, some analogous to the usual O(n^2) redeclaration problem and some not. In particular, retroactively removing shadow declarations when they're hidden by later decls is pretty unfortunate. I'm not yet convinced it's worse than the alternative, though. llvm-svn: 91045
2009-12-10 17:41:52 +08:00
D->getLocation(), Prev))
NewUD->setInvalidDecl();
}
if (!NewUD->isInvalidDecl() &&
Fix some interactions between C++11 and C++14 features and using-declarations: * a dependent non-type using-declaration within a function template can be valid, as it can refer to an enumerator, so don't reject it in the template definition * we can partially substitute into a dependent using-declaration if it appears within a (local class in a) generic lambda within a function template, which means an UnresolvedUsing*Decl doesn't necessarily instantiate to a UsingDecl. llvm-svn: 290071
2016-12-19 05:39:37 +08:00
SemaRef.CheckUsingDeclQualifier(D->getUsingLoc(), D->hasTypename(),
SS, NameInfo, D->getLocation()))
Fix "using typename" and the instantiation of non-dependent using declarations. llvm-svn: 90614
2009-12-05 06:46:56 +08:00
NewUD->setInvalidDecl();
Implement redeclaration checking and hiding semantics for using declarations. There are a couple of O(n^2) operations in this, some analogous to the usual O(n^2) redeclaration problem and some not. In particular, retroactively removing shadow declarations when they're hidden by later decls is pretty unfortunate. I'm not yet convinced it's worse than the alternative, though. llvm-svn: 91045
2009-12-10 17:41:52 +08:00
Fix "using typename" and the instantiation of non-dependent using declarations. llvm-svn: 90614
2009-12-05 06:46:56 +08:00
SemaRef.Context.setInstantiatedFromUsingDecl(NewUD, D);
NewUD->setAccess(D->getAccess());
Owner->addDecl(NewUD);
Implement redeclaration checking and hiding semantics for using declarations. There are a couple of O(n^2) operations in this, some analogous to the usual O(n^2) redeclaration problem and some not. In particular, retroactively removing shadow declarations when they're hidden by later decls is pretty unfortunate. I'm not yet convinced it's worse than the alternative, though. llvm-svn: 91045
2009-12-10 17:41:52 +08:00
// Don't process the shadow decls for an invalid decl.
if (NewUD->isInvalidDecl())
return NewUD;
P0136R1, DR1573, DR1645, DR1715, DR1736, DR1903, DR1941, DR1959, DR1991: Replace inheriting constructors implementation with new approach, voted into C++ last year as a DR against C++11. Instead of synthesizing a set of derived class constructors for each inherited base class constructor, we make the constructors of the base class visible to constructor lookup in the derived class, using the normal rules for using-declarations. For constructors, UsingShadowDecl now has a ConstructorUsingShadowDecl derived class that tracks the requisite additional information. We create shadow constructors (not found by name lookup) in the derived class to model the actual initialization, and have a new expression node, CXXInheritedCtorInitExpr, to model the initialization of a base class from such a constructor. (This initialization is special because it performs real perfect forwarding of arguments.) In cases where argument forwarding is not possible (for inalloca calls, variadic calls, and calls with callee parameter cleanup), the shadow inheriting constructor is not emitted and instead we directly emit the initialization code into the caller of the inherited constructor. Note that this new model is not perfectly compatible with the old model in some corner cases. In particular: * if B inherits a private constructor from A, and C uses that constructor to construct a B, then we previously required that A befriends B and B befriends C, but the new rules require A to befriend C directly, and * if a derived class has its own constructors (and so its implicit default constructor is suppressed), it may still inherit a default constructor from a base class llvm-svn: 274049
2016-06-29 03:03:57 +08:00
if (NameInfo.getName().getNameKind() == DeclarationName::CXXConstructorName)
Make typo-correction of inheriting constructors work a bit better. Limit correction to direct base class members, and recover properly after we apply such a correction. llvm-svn: 207731
2014-05-01 08:35:04 +08:00
SemaRef.CheckInheritingConstructorUsingDecl(NewUD);
Basic semantic analysis support for inheriting constructor declarations in dependent contexts. llvm-svn: 153858
2012-04-02 09:30:27 +08:00
Add using shadow decls to the "instantiated locals" map, fixing PR5847. llvm-svn: 91928
2009-12-23 06:26:37 +08:00
bool isFunctionScope = Owner->isFunctionOrMethod();
Implement redeclaration checking and hiding semantics for using declarations. There are a couple of O(n^2) operations in this, some analogous to the usual O(n^2) redeclaration problem and some not. In particular, retroactively removing shadow declarations when they're hidden by later decls is pretty unfortunate. I'm not yet convinced it's worse than the alternative, though. llvm-svn: 91045
2009-12-10 17:41:52 +08:00
// Process the shadow decls.
[C++11] Replacing UsingDecl iterators shadow_begin() and shadow_end() with iterator_range shadows(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203825
2014-03-14 02:07:29 +08:00
for (auto *Shadow : D->shadows()) {
P0136R1, DR1573, DR1645, DR1715, DR1736, DR1903, DR1941, DR1959, DR1991: Replace inheriting constructors implementation with new approach, voted into C++ last year as a DR against C++11. Instead of synthesizing a set of derived class constructors for each inherited base class constructor, we make the constructors of the base class visible to constructor lookup in the derived class, using the normal rules for using-declarations. For constructors, UsingShadowDecl now has a ConstructorUsingShadowDecl derived class that tracks the requisite additional information. We create shadow constructors (not found by name lookup) in the derived class to model the actual initialization, and have a new expression node, CXXInheritedCtorInitExpr, to model the initialization of a base class from such a constructor. (This initialization is special because it performs real perfect forwarding of arguments.) In cases where argument forwarding is not possible (for inalloca calls, variadic calls, and calls with callee parameter cleanup), the shadow inheriting constructor is not emitted and instead we directly emit the initialization code into the caller of the inherited constructor. Note that this new model is not perfectly compatible with the old model in some corner cases. In particular: * if B inherits a private constructor from A, and C uses that constructor to construct a B, then we previously required that A befriends B and B befriends C, but the new rules require A to befriend C directly, and * if a derived class has its own constructors (and so its implicit default constructor is suppressed), it may still inherit a default constructor from a base class llvm-svn: 274049
2016-06-29 03:03:57 +08:00
// FIXME: UsingShadowDecl doesn't preserve its immediate target, so
// reconstruct it in the case where it matters.
NamedDecl *OldTarget = Shadow->getTargetDecl();
if (auto *CUSD = dyn_cast<ConstructorUsingShadowDecl>(Shadow))
if (auto *BaseShadow = CUSD->getNominatedBaseClassShadowDecl())
OldTarget = BaseShadow;
Implement redeclaration checking and hiding semantics for using declarations. There are a couple of O(n^2) operations in this, some analogous to the usual O(n^2) redeclaration problem and some not. In particular, retroactively removing shadow declarations when they're hidden by later decls is pretty unfortunate. I'm not yet convinced it's worse than the alternative, though. llvm-svn: 91045
2009-12-10 17:41:52 +08:00
NamedDecl *InstTarget =
Make UsingShadowDecls redeclarable. This fixes some visibility problems with modules. With this fixed, I no longer see any test regressions in the libc++ test suite when enabling a single-module module.map for libc++ (other than issues with my system headers). llvm-svn: 193219
2013-10-23 10:17:46 +08:00
cast_or_null<NamedDecl>(SemaRef.FindInstantiatedDecl(
P0136R1, DR1573, DR1645, DR1715, DR1736, DR1903, DR1941, DR1959, DR1991: Replace inheriting constructors implementation with new approach, voted into C++ last year as a DR against C++11. Instead of synthesizing a set of derived class constructors for each inherited base class constructor, we make the constructors of the base class visible to constructor lookup in the derived class, using the normal rules for using-declarations. For constructors, UsingShadowDecl now has a ConstructorUsingShadowDecl derived class that tracks the requisite additional information. We create shadow constructors (not found by name lookup) in the derived class to model the actual initialization, and have a new expression node, CXXInheritedCtorInitExpr, to model the initialization of a base class from such a constructor. (This initialization is special because it performs real perfect forwarding of arguments.) In cases where argument forwarding is not possible (for inalloca calls, variadic calls, and calls with callee parameter cleanup), the shadow inheriting constructor is not emitted and instead we directly emit the initialization code into the caller of the inherited constructor. Note that this new model is not perfectly compatible with the old model in some corner cases. In particular: * if B inherits a private constructor from A, and C uses that constructor to construct a B, then we previously required that A befriends B and B befriends C, but the new rules require A to befriend C directly, and * if a derived class has its own constructors (and so its implicit default constructor is suppressed), it may still inherit a default constructor from a base class llvm-svn: 274049
2016-06-29 03:03:57 +08:00
Shadow->getLocation(), OldTarget, TemplateArgs));
Patch up several Sema::FindInstantiatedDecl() callers, so that they'll properly cope with NULL return values. llvm-svn: 127024
2011-03-05 03:46:35 +08:00
if (!InstTarget)
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Implement redeclaration checking and hiding semantics for using declarations. There are a couple of O(n^2) operations in this, some analogous to the usual O(n^2) redeclaration problem and some not. In particular, retroactively removing shadow declarations when they're hidden by later decls is pretty unfortunate. I'm not yet convinced it's worse than the alternative, though. llvm-svn: 91045
2009-12-10 17:41:52 +08:00
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
UsingShadowDecl *PrevDecl = nullptr;
Make UsingShadowDecls redeclarable. This fixes some visibility problems with modules. With this fixed, I no longer see any test regressions in the libc++ test suite when enabling a single-module module.map for libc++ (other than issues with my system headers). llvm-svn: 193219
2013-10-23 10:17:46 +08:00
if (CheckRedeclaration) {
if (SemaRef.CheckUsingShadowDecl(NewUD, InstTarget, Prev, PrevDecl))
continue;
[modules] When instantiating a class member, don't expect to find the previous declaration in the instantiation if the previous declaration came from another definition of the class template that got merged into the pattern definition. llvm-svn: 219552
2014-10-11 08:37:16 +08:00
} else if (UsingShadowDecl *OldPrev =
getPreviousDeclForInstantiation(Shadow)) {
Make UsingShadowDecls redeclarable. This fixes some visibility problems with modules. With this fixed, I no longer see any test regressions in the libc++ test suite when enabling a single-module module.map for libc++ (other than issues with my system headers). llvm-svn: 193219
2013-10-23 10:17:46 +08:00
PrevDecl = cast_or_null<UsingShadowDecl>(SemaRef.FindInstantiatedDecl(
Shadow->getLocation(), OldPrev, TemplateArgs));
}
Implement redeclaration checking and hiding semantics for using declarations. There are a couple of O(n^2) operations in this, some analogous to the usual O(n^2) redeclaration problem and some not. In particular, retroactively removing shadow declarations when they're hidden by later decls is pretty unfortunate. I'm not yet convinced it's worse than the alternative, though. llvm-svn: 91045
2009-12-10 17:41:52 +08:00
Make UsingShadowDecls redeclarable. This fixes some visibility problems with modules. With this fixed, I no longer see any test regressions in the libc++ test suite when enabling a single-module module.map for libc++ (other than issues with my system headers). llvm-svn: 193219
2013-10-23 10:17:46 +08:00
UsingShadowDecl *InstShadow =
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
SemaRef.BuildUsingShadowDecl(/*Scope*/nullptr, NewUD, InstTarget,
PrevDecl);
Implement redeclaration checking and hiding semantics for using declarations. There are a couple of O(n^2) operations in this, some analogous to the usual O(n^2) redeclaration problem and some not. In particular, retroactively removing shadow declarations when they're hidden by later decls is pretty unfortunate. I'm not yet convinced it's worse than the alternative, though. llvm-svn: 91045
2009-12-10 17:41:52 +08:00
SemaRef.Context.setInstantiatedFromUsingShadowDecl(InstShadow, Shadow);
Add using shadow decls to the "instantiated locals" map, fixing PR5847. llvm-svn: 91928
2009-12-23 06:26:37 +08:00
if (isFunctionScope)
SemaRef.CurrentInstantiationScope->InstantiatedLocal(Shadow, InstShadow);
Implement redeclaration checking and hiding semantics for using declarations. There are a couple of O(n^2) operations in this, some analogous to the usual O(n^2) redeclaration problem and some not. In particular, retroactively removing shadow declarations when they're hidden by later decls is pretty unfortunate. I'm not yet convinced it's worse than the alternative, though. llvm-svn: 91045
2009-12-10 17:41:52 +08:00
}
Fix "using typename" and the instantiation of non-dependent using declarations. llvm-svn: 90614
2009-12-05 06:46:56 +08:00
return NewUD;
}
Decl *TemplateDeclInstantiator::VisitUsingShadowDecl(UsingShadowDecl *D) {
Implement redeclaration checking and hiding semantics for using declarations. There are a couple of O(n^2) operations in this, some analogous to the usual O(n^2) redeclaration problem and some not. In particular, retroactively removing shadow declarations when they're hidden by later decls is pretty unfortunate. I'm not yet convinced it's worse than the alternative, though. llvm-svn: 91045
2009-12-10 17:41:52 +08:00
// Ignore these; we handle them in bulk when processing the UsingDecl.
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Fix "using typename" and the instantiation of non-dependent using declarations. llvm-svn: 90614
2009-12-05 06:46:56 +08:00
}
P0136R1, DR1573, DR1645, DR1715, DR1736, DR1903, DR1941, DR1959, DR1991: Replace inheriting constructors implementation with new approach, voted into C++ last year as a DR against C++11. Instead of synthesizing a set of derived class constructors for each inherited base class constructor, we make the constructors of the base class visible to constructor lookup in the derived class, using the normal rules for using-declarations. For constructors, UsingShadowDecl now has a ConstructorUsingShadowDecl derived class that tracks the requisite additional information. We create shadow constructors (not found by name lookup) in the derived class to model the actual initialization, and have a new expression node, CXXInheritedCtorInitExpr, to model the initialization of a base class from such a constructor. (This initialization is special because it performs real perfect forwarding of arguments.) In cases where argument forwarding is not possible (for inalloca calls, variadic calls, and calls with callee parameter cleanup), the shadow inheriting constructor is not emitted and instead we directly emit the initialization code into the caller of the inherited constructor. Note that this new model is not perfectly compatible with the old model in some corner cases. In particular: * if B inherits a private constructor from A, and C uses that constructor to construct a B, then we previously required that A befriends B and B befriends C, but the new rules require A to befriend C directly, and * if a derived class has its own constructors (and so its implicit default constructor is suppressed), it may still inherit a default constructor from a base class llvm-svn: 274049
2016-06-29 03:03:57 +08:00
Decl *TemplateDeclInstantiator::VisitConstructorUsingShadowDecl(
ConstructorUsingShadowDecl *D) {
// Ignore these; we handle them in bulk when processing the UsingDecl.
return nullptr;
}
[c++1z] P0195R2: Support pack-expansion of using-declarations. This change introduces UsingPackDecl as a marker for the set of UsingDecls produced by pack expansion of a single (unresolved) using declaration. This is not strictly necessary (we just need to be able to map from the original using declaration to its expansions somehow), but it's useful to maintain the invariant that each declaration reference instantiates to refer to one declaration. This is a re-commit of r290080 (reverted in r290092) with a fix for a use-after-lifetime bug. llvm-svn: 290203
2016-12-21 05:35:28 +08:00
template <typename T>
Decl *TemplateDeclInstantiator::instantiateUnresolvedUsingDecl(
T *D, bool InstantiatingPackElement) {
// If this is a pack expansion, expand it now.
if (D->isPackExpansion() && !InstantiatingPackElement) {
SmallVector<UnexpandedParameterPack, 2> Unexpanded;
SemaRef.collectUnexpandedParameterPacks(D->getQualifierLoc(), Unexpanded);
SemaRef.collectUnexpandedParameterPacks(D->getNameInfo(), Unexpanded);
[c++1z] P0195R2: Support pack-expansion of using-declarations. This change introduces UsingPackDecl as a marker for the set of UsingDecls produced by pack expansion of a single (unresolved) using declaration. This is not strictly necessary (we just need to be able to map from the original using declaration to its expansions somehow), but it's useful to maintain the invariant that each declaration reference instantiates to refer to one declaration. llvm-svn: 290080
2016-12-19 12:08:53 +08:00
[c++1z] P0195R2: Support pack-expansion of using-declarations. This change introduces UsingPackDecl as a marker for the set of UsingDecls produced by pack expansion of a single (unresolved) using declaration. This is not strictly necessary (we just need to be able to map from the original using declaration to its expansions somehow), but it's useful to maintain the invariant that each declaration reference instantiates to refer to one declaration. This is a re-commit of r290080 (reverted in r290092) with a fix for a use-after-lifetime bug. llvm-svn: 290203
2016-12-21 05:35:28 +08:00
// Determine whether the set of unexpanded parameter packs can and should
// be expanded.
bool Expand = true;
bool RetainExpansion = false;
Optional<unsigned> NumExpansions;
if (SemaRef.CheckParameterPacksForExpansion(
D->getEllipsisLoc(), D->getSourceRange(), Unexpanded, TemplateArgs,
Expand, RetainExpansion, NumExpansions))
return nullptr;
[c++1z] P0195R2: Support pack-expansion of using-declarations. This change introduces UsingPackDecl as a marker for the set of UsingDecls produced by pack expansion of a single (unresolved) using declaration. This is not strictly necessary (we just need to be able to map from the original using declaration to its expansions somehow), but it's useful to maintain the invariant that each declaration reference instantiates to refer to one declaration. llvm-svn: 290080
2016-12-19 12:08:53 +08:00
[c++1z] P0195R2: Support pack-expansion of using-declarations. This change introduces UsingPackDecl as a marker for the set of UsingDecls produced by pack expansion of a single (unresolved) using declaration. This is not strictly necessary (we just need to be able to map from the original using declaration to its expansions somehow), but it's useful to maintain the invariant that each declaration reference instantiates to refer to one declaration. This is a re-commit of r290080 (reverted in r290092) with a fix for a use-after-lifetime bug. llvm-svn: 290203
2016-12-21 05:35:28 +08:00
// This declaration cannot appear within a function template signature,
// so we can't have a partial argument list for a parameter pack.
assert(!RetainExpansion &&
"should never need to retain an expansion for UsingPackDecl");
[c++1z] P0195R2: Support pack-expansion of using-declarations. This change introduces UsingPackDecl as a marker for the set of UsingDecls produced by pack expansion of a single (unresolved) using declaration. This is not strictly necessary (we just need to be able to map from the original using declaration to its expansions somehow), but it's useful to maintain the invariant that each declaration reference instantiates to refer to one declaration. llvm-svn: 290080
2016-12-19 12:08:53 +08:00
[c++1z] P0195R2: Support pack-expansion of using-declarations. This change introduces UsingPackDecl as a marker for the set of UsingDecls produced by pack expansion of a single (unresolved) using declaration. This is not strictly necessary (we just need to be able to map from the original using declaration to its expansions somehow), but it's useful to maintain the invariant that each declaration reference instantiates to refer to one declaration. This is a re-commit of r290080 (reverted in r290092) with a fix for a use-after-lifetime bug. llvm-svn: 290203
2016-12-21 05:35:28 +08:00
if (!Expand) {
// We cannot fully expand the pack expansion now, so substitute into the
// pattern and create a new pack expansion.
Sema::ArgumentPackSubstitutionIndexRAII SubstIndex(SemaRef, -1);
return instantiateUnresolvedUsingDecl(D, true);
}
// Within a function, we don't have any normal way to check for conflicts
// between shadow declarations from different using declarations in the
// same pack expansion, but this is always ill-formed because all expansions
// must produce (conflicting) enumerators.
//
// Sadly we can't just reject this in the template definition because it
// could be valid if the pack is empty or has exactly one expansion.
if (D->getDeclContext()->isFunctionOrMethod() && *NumExpansions > 1) {
SemaRef.Diag(D->getEllipsisLoc(),
diag::err_using_decl_redeclaration_expansion);
return nullptr;
}
// Instantiate the slices of this pack and build a UsingPackDecl.
SmallVector<NamedDecl*, 8> Expansions;
for (unsigned I = 0; I != *NumExpansions; ++I) {
Sema::ArgumentPackSubstitutionIndexRAII SubstIndex(SemaRef, I);
Decl *Slice = instantiateUnresolvedUsingDecl(D, true);
if (!Slice)
return nullptr;
// Note that we can still get unresolved using declarations here, if we
// had arguments for all packs but the pattern also contained other
// template arguments (this only happens during partial substitution, eg
// into the body of a generic lambda in a function template).
Expansions.push_back(cast<NamedDecl>(Slice));
}
auto *NewD = SemaRef.BuildUsingPackDecl(D, Expansions);
if (isDeclWithinFunction(D))
SemaRef.CurrentInstantiationScope->InstantiatedLocal(D, NewD);
return NewD;
}
UnresolvedUsingTypenameDecl *TD = dyn_cast<UnresolvedUsingTypenameDecl>(D);
SourceLocation TypenameLoc = TD ? TD->getTypenameLoc() : SourceLocation();
Incremental progress on using declarations. Split UnresolvedUsingDecl into two classes, one for typenames and one for values; this seems to have some support from Doug if not necessarily from the extremely-vague-on-this-point standard. Track the location of the 'typename' keyword in a using-typename decl. Make a new lookup result for unresolved values and deal with it in most places. llvm-svn: 89184
2009-11-18 10:36:19 +08:00
Maintain nested-name-specifier source-location information through instantiation of using declarations (all three forms). llvm-svn: 126485
2011-02-25 23:54:31 +08:00
NestedNameSpecifierLoc QualifierLoc
[c++1z] P0195R2: Support pack-expansion of using-declarations. This change introduces UsingPackDecl as a marker for the set of UsingDecls produced by pack expansion of a single (unresolved) using declaration. This is not strictly necessary (we just need to be able to map from the original using declaration to its expansions somehow), but it's useful to maintain the invariant that each declaration reference instantiates to refer to one declaration. This is a re-commit of r290080 (reverted in r290092) with a fix for a use-after-lifetime bug. llvm-svn: 290203
2016-12-21 05:35:28 +08:00
= SemaRef.SubstNestedNameSpecifierLoc(D->getQualifierLoc(),
TemplateArgs);
Maintain nested-name-specifier source-location information through instantiation of using declarations (all three forms). llvm-svn: 126485
2011-02-25 23:54:31 +08:00
if (!QualifierLoc)
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Instantiate unresolved using declarations. llvm-svn: 80366
2009-08-28 23:18:15 +08:00
CXXScopeSpec SS;
Maintain nested-name-specifier source-location information through instantiation of using declarations (all three forms). llvm-svn: 126485
2011-02-25 23:54:31 +08:00
SS.Adopt(QualifierLoc);
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Added locations and type source info for DeclarationName inside UsingDecl. llvm-svn: 110912
2010-08-12 19:46:03 +08:00
DeclarationNameInfo NameInfo
= SemaRef.SubstDeclarationNameInfo(D->getNameInfo(), TemplateArgs);
[c++1z] P0195R2: Support pack-expansion of using-declarations. This change introduces UsingPackDecl as a marker for the set of UsingDecls produced by pack expansion of a single (unresolved) using declaration. This is not strictly necessary (we just need to be able to map from the original using declaration to its expansions somehow), but it's useful to maintain the invariant that each declaration reference instantiates to refer to one declaration. This is a re-commit of r290080 (reverted in r290092) with a fix for a use-after-lifetime bug. llvm-svn: 290203
2016-12-21 05:35:28 +08:00
// Produce a pack expansion only if we're not instantiating a particular
// slice of a pack expansion.
bool InstantiatingSlice = D->getEllipsisLoc().isValid() &&
SemaRef.ArgumentPackSubstitutionIndex != -1;
SourceLocation EllipsisLoc =
InstantiatingSlice ? SourceLocation() : D->getEllipsisLoc();
NamedDecl *UD = SemaRef.BuildUsingDeclaration(
/*Scope*/ nullptr, D->getAccess(), D->getUsingLoc(),
/*HasTypename*/ TD, TypenameLoc, SS, NameInfo, EllipsisLoc, nullptr,
/*IsInstantiation*/ true);
Revert r104106; it's breaking linking of Boost.Serialization. llvm-svn: 104121
2010-05-20 01:02:24 +08:00
if (UD)
Fix some interactions between C++11 and C++14 features and using-declarations: * a dependent non-type using-declaration within a function template can be valid, as it can refer to an enumerator, so don't reject it in the template definition * we can partially substitute into a dependent using-declaration if it appears within a (local class in a) generic lambda within a function template, which means an UnresolvedUsing*Decl doesn't necessarily instantiate to a UsingDecl. llvm-svn: 290071
2016-12-19 05:39:37 +08:00
SemaRef.Context.setInstantiatedFromUsingDecl(UD, D);
Fix "using typename" and the instantiation of non-dependent using declarations. llvm-svn: 90614
2009-12-05 06:46:56 +08:00
Improve instantiation of UnresolvedUsingDecls. llvm-svn: 80434
2009-08-30 03:37:28 +08:00
return UD;
Instantiate unresolved using declarations. llvm-svn: 80366
2009-08-28 23:18:15 +08:00
}
[c++1z] P0195R2: Support pack-expansion of using-declarations. This change introduces UsingPackDecl as a marker for the set of UsingDecls produced by pack expansion of a single (unresolved) using declaration. This is not strictly necessary (we just need to be able to map from the original using declaration to its expansions somehow), but it's useful to maintain the invariant that each declaration reference instantiates to refer to one declaration. This is a re-commit of r290080 (reverted in r290092) with a fix for a use-after-lifetime bug. llvm-svn: 290203
2016-12-21 05:35:28 +08:00
Decl *TemplateDeclInstantiator::VisitUnresolvedUsingTypenameDecl(
UnresolvedUsingTypenameDecl *D) {
return instantiateUnresolvedUsingDecl(D);
}
Decl *TemplateDeclInstantiator::VisitUnresolvedUsingValueDecl(
UnresolvedUsingValueDecl *D) {
return instantiateUnresolvedUsingDecl(D);
}
Decl *TemplateDeclInstantiator::VisitUsingPackDecl(UsingPackDecl *D) {
SmallVector<NamedDecl*, 8> Expansions;
for (auto *UD : D->expansions()) {
if (auto *NewUD =
SemaRef.FindInstantiatedDecl(D->getLocation(), UD, TemplateArgs))
Expansions.push_back(cast<NamedDecl>(NewUD));
else
return nullptr;
}
auto *NewD = SemaRef.BuildUsingPackDecl(D, Expansions);
if (isDeclWithinFunction(D))
SemaRef.CurrentInstantiationScope->InstantiatedLocal(D, NewD);
return NewD;
}
Implement function template specialization at class scope extension in Microsoft mode. A new AST node is introduced: ClassScopeFunctionSpecialization. This node holds a FunctionDecl that is not yet specialized; then during the class template instantiation the ClassScopeFunctionSpecialization will spawn the actual function specialization. Example: template <class T> class A { public: template <class U> void f(U p) { } template <> void f(int p) { } // <== class scope specialization }; This extension is necessary to parse MSVC standard C++ headers, MFC and ATL code. BTW, with this feature in, clang can parse (-fsyntax-only) all the MSVC 2010 standard header files without any error. llvm-svn: 137573
2011-08-14 11:52:19 +08:00
Decl *TemplateDeclInstantiator::VisitClassScopeFunctionSpecializationDecl(
ClassScopeFunctionSpecializationDecl *Decl) {
CXXMethodDecl *OldFD = Decl->getSpecialization();
Instantiation of a CXXMethodDecl may fail when the parameter type cannot be instantiated. Do not crash in this case. Fixes PR22040! The FIXME in the test is caused by TemplateDeclInstantiator::VisitCXXRecordDecl returning a nullptr instead of creating an invalid decl. This is a common pattern across all of TemplateDeclInstantiator, so I'm not comfortable changing it. The reason it's not invalid in the class template is due to support for an MSVC extension, see r137573. llvm-svn: 225071
2015-01-02 09:33:12 +08:00
CXXMethodDecl *NewFD =
cast_or_null<CXXMethodDecl>(VisitCXXMethodDecl(OldFD, nullptr, true));
if (!NewFD)
return nullptr;
Implement function template specialization at class scope extension in Microsoft mode. A new AST node is introduced: ClassScopeFunctionSpecialization. This node holds a FunctionDecl that is not yet specialized; then during the class template instantiation the ClassScopeFunctionSpecialization will spawn the actual function specialization. Example: template <class T> class A { public: template <class U> void f(U p) { } template <> void f(int p) { } // <== class scope specialization }; This extension is necessary to parse MSVC standard C++ headers, MFC and ATL code. BTW, with this feature in, clang can parse (-fsyntax-only) all the MSVC 2010 standard header files without any error. llvm-svn: 137573
2011-08-14 11:52:19 +08:00
LookupResult Previous(SemaRef, NewFD->getNameInfo(), Sema::LookupOrdinaryName,
Sema::ForRedeclaration);
Make explicit specializations at class scope work for non-type template parameters in microsoft mode. PR12709. llvm-svn: 159147
2012-06-26 01:21:05 +08:00
TemplateArgumentListInfo TemplateArgs;
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
TemplateArgumentListInfo *TemplateArgsPtr = nullptr;
Make explicit specializations at class scope work for non-type template parameters in microsoft mode. PR12709. llvm-svn: 159147
2012-06-26 01:21:05 +08:00
if (Decl->hasExplicitTemplateArgs()) {
TemplateArgs = Decl->templateArgs();
TemplateArgsPtr = &TemplateArgs;
}
Implement function template specialization at class scope extension in Microsoft mode. A new AST node is introduced: ClassScopeFunctionSpecialization. This node holds a FunctionDecl that is not yet specialized; then during the class template instantiation the ClassScopeFunctionSpecialization will spawn the actual function specialization. Example: template <class T> class A { public: template <class U> void f(U p) { } template <> void f(int p) { } // <== class scope specialization }; This extension is necessary to parse MSVC standard C++ headers, MFC and ATL code. BTW, with this feature in, clang can parse (-fsyntax-only) all the MSVC 2010 standard header files without any error. llvm-svn: 137573
2011-08-14 11:52:19 +08:00
SemaRef.LookupQualifiedName(Previous, SemaRef.CurContext);
Make explicit specializations at class scope work for non-type template parameters in microsoft mode. PR12709. llvm-svn: 159147
2012-06-26 01:21:05 +08:00
if (SemaRef.CheckFunctionTemplateSpecialization(NewFD, TemplateArgsPtr,
Previous)) {
Implement function template specialization at class scope extension in Microsoft mode. A new AST node is introduced: ClassScopeFunctionSpecialization. This node holds a FunctionDecl that is not yet specialized; then during the class template instantiation the ClassScopeFunctionSpecialization will spawn the actual function specialization. Example: template <class T> class A { public: template <class U> void f(U p) { } template <> void f(int p) { } // <== class scope specialization }; This extension is necessary to parse MSVC standard C++ headers, MFC and ATL code. BTW, with this feature in, clang can parse (-fsyntax-only) all the MSVC 2010 standard header files without any error. llvm-svn: 137573
2011-08-14 11:52:19 +08:00
NewFD->setInvalidDecl();
return NewFD;
}
// Associate the specialization with the pattern.
FunctionDecl *Specialization = cast<FunctionDecl>(Previous.getFoundDecl());
assert(Specialization && "Class scope Specialization is null");
SemaRef.Context.setClassScopeSpecializationPattern(Specialization, OldFD);
return NewFD;
}
OpenMP threadprivate directive parsing and semantic analysis llvm-svn: 177705
2013-03-22 14:34:35 +08:00
Decl *TemplateDeclInstantiator::VisitOMPThreadPrivateDecl(
OMPThreadPrivateDecl *D) {
OpenMP threadprivate with qualified names. llvm-svn: 181683
2013-05-13 12:18:18 +08:00
SmallVector<Expr *, 5> Vars;
[C++11] Replacing OMPThreadPrivateDecl and OMPClause iterators varlist_begin() and varlist_end() with iterator_range varlists(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203937
2014-03-14 23:55:35 +08:00
for (auto *I : D->varlists()) {
Refactoring. Remove release and take methods from ActionResult. Rename takeAs to getAs. llvm-svn: 209800
2014-05-29 18:55:11 +08:00
Expr *Var = SemaRef.SubstExpr(I, TemplateArgs).get();
OpenMP threadprivate directive parsing and semantic analysis llvm-svn: 177705
2013-03-22 14:34:35 +08:00
assert(isa<DeclRefExpr>(Var) && "threadprivate arg is not a DeclRefExpr");
OpenMP threadprivate with qualified names. llvm-svn: 181683
2013-05-13 12:18:18 +08:00
Vars.push_back(Var);
OpenMP threadprivate directive parsing and semantic analysis llvm-svn: 177705
2013-03-22 14:34:35 +08:00
}
OMPThreadPrivateDecl *TD =
SemaRef.CheckOMPThreadPrivateDecl(D->getLocation(), Vars);
[OPENMP] Fix for threadprivate construct instantiatiation. llvm-svn: 203225
2014-03-07 17:46:29 +08:00
TD->setAccess(AS_public);
Owner->addDecl(TD);
OpenMP threadprivate directive parsing and semantic analysis llvm-svn: 177705
2013-03-22 14:34:35 +08:00
return TD;
}
[OPENMP 4.0] Initial support for 'omp declare reduction' construct. Add parsing, sema analysis and serialization/deserialization for 'declare reduction' construct. User-defined reductions are defined as #pragma omp declare reduction( reduction-identifier : typename-list : combiner ) [initializer ( initializer-expr )] These custom reductions may be used in 'reduction' clauses of OpenMP constructs. The combiner specifies how partial results can be combined into a single value. The combiner can use the special variable identifiers omp_in and omp_out that are of the type of the variables being reduced with this reduction-identifier. Each of them will denote one of the values to be combined before executing the combiner. It is assumed that the special omp_out identifier will refer to the storage that holds the resulting combined value after executing the combiner. As the initializer-expr value of a user-defined reduction is not known a priori the initializer-clause can be used to specify one. Then the contents of the initializer-clause will be used as the initializer for private copies of reduction list items where the omp_priv identifier will refer to the storage to be initialized. The special identifier omp_orig can also appear in the initializer-clause and it will refer to the storage of the original variable to be reduced. Differential Revision: http://reviews.llvm.org/D11182 llvm-svn: 262582
2016-03-03 13:21:39 +08:00
Decl *TemplateDeclInstantiator::VisitOMPDeclareReductionDecl(
OMPDeclareReductionDecl *D) {
// Instantiate type and check if it is allowed.
QualType SubstReductionType = SemaRef.ActOnOpenMPDeclareReductionType(
D->getLocation(),
ParsedType::make(SemaRef.SubstType(D->getType(), TemplateArgs,
D->getLocation(), DeclarationName())));
if (SubstReductionType.isNull())
return nullptr;
bool IsCorrect = !SubstReductionType.isNull();
// Create instantiated copy.
std::pair<QualType, SourceLocation> ReductionTypes[] = {
std::make_pair(SubstReductionType, D->getLocation())};
auto *PrevDeclInScope = D->getPrevDeclInScope();
if (PrevDeclInScope && !PrevDeclInScope->isInvalidDecl()) {
PrevDeclInScope = cast<OMPDeclareReductionDecl>(
SemaRef.CurrentInstantiationScope->findInstantiationOf(PrevDeclInScope)
->get<Decl *>());
}
auto DRD = SemaRef.ActOnOpenMPDeclareReductionDirectiveStart(
/*S=*/nullptr, Owner, D->getDeclName(), ReductionTypes, D->getAccess(),
PrevDeclInScope);
auto *NewDRD = cast<OMPDeclareReductionDecl>(DRD.get().getSingleDecl());
if (isDeclWithinFunction(NewDRD))
SemaRef.CurrentInstantiationScope->InstantiatedLocal(D, NewDRD);
Expr *SubstCombiner = nullptr;
Expr *SubstInitializer = nullptr;
// Combiners instantiation sequence.
if (D->getCombiner()) {
SemaRef.ActOnOpenMPDeclareReductionCombinerStart(
/*S=*/nullptr, NewDRD);
const char *Names[] = {"omp_in", "omp_out"};
for (auto &Name : Names) {
DeclarationName DN(&SemaRef.Context.Idents.get(Name));
auto OldLookup = D->lookup(DN);
auto Lookup = NewDRD->lookup(DN);
if (!OldLookup.empty() && !Lookup.empty()) {
assert(Lookup.size() == 1 && OldLookup.size() == 1);
SemaRef.CurrentInstantiationScope->InstantiatedLocal(OldLookup.front(),
Lookup.front());
}
}
SubstCombiner = SemaRef.SubstExpr(D->getCombiner(), TemplateArgs).get();
SemaRef.ActOnOpenMPDeclareReductionCombinerEnd(NewDRD, SubstCombiner);
// Initializers instantiation sequence.
if (D->getInitializer()) {
SemaRef.ActOnOpenMPDeclareReductionInitializerStart(
/*S=*/nullptr, NewDRD);
const char *Names[] = {"omp_orig", "omp_priv"};
for (auto &Name : Names) {
DeclarationName DN(&SemaRef.Context.Idents.get(Name));
auto OldLookup = D->lookup(DN);
auto Lookup = NewDRD->lookup(DN);
if (!OldLookup.empty() && !Lookup.empty()) {
assert(Lookup.size() == 1 && OldLookup.size() == 1);
SemaRef.CurrentInstantiationScope->InstantiatedLocal(
OldLookup.front(), Lookup.front());
}
}
SubstInitializer =
SemaRef.SubstExpr(D->getInitializer(), TemplateArgs).get();
SemaRef.ActOnOpenMPDeclareReductionInitializerEnd(NewDRD,
SubstInitializer);
}
IsCorrect = IsCorrect && SubstCombiner &&
(!D->getInitializer() || SubstInitializer);
} else
IsCorrect = false;
(void)SemaRef.ActOnOpenMPDeclareReductionDirectiveEnd(/*S=*/nullptr, DRD,
IsCorrect);
return NewDRD;
}
[OPENMP] Rename OMPCapturedFieldDecl to OMPCapturedExprDecl, NFC. OMPCapturedExprDecl allows caopturing not only of fielddecls, but also other expressions. It also allows to simplify codegen for several clauses. llvm-svn: 260492
2016-02-11 13:35:55 +08:00
Decl *TemplateDeclInstantiator::VisitOMPCapturedExprDecl(
OMPCapturedExprDecl * /*D*/) {
[OPENMP 4.5] Ccapture/codegen of private non-static data members. OpenMP 4.5 introduces privatization of non-static data members of current class in non-static member functions. To correctly handle such kind of privatization a new (pseudo)declaration VarDecl-based node is added. It allows to reuse an existing code for capturing variables in Lambdas/Block/Captured blocks of code for correct privatization and codegen. llvm-svn: 260077
2016-02-08 17:29:13 +08:00
llvm_unreachable("Should not be met in templates");
}
Switch Decl instantiation to DeclNodes.inc. This replaces a long list of declarations for visitor functions with a list generated from DeclNodes.inc. Nothing really interesting came out of it; we had comprehensive coverage anyway (excluding FriendTemplateDecls). llvm-svn: 185118
2013-06-28 07:21:55 +08:00
Decl *TemplateDeclInstantiator::VisitFunctionDecl(FunctionDecl *D) {
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return VisitFunctionDecl(D, nullptr);
Switch Decl instantiation to DeclNodes.inc. This replaces a long list of declarations for visitor functions with a list generated from DeclNodes.inc. Nothing really interesting came out of it; we had comprehensive coverage anyway (excluding FriendTemplateDecls). llvm-svn: 185118
2013-06-28 07:21:55 +08:00
}
Add an explicit derived class of FunctionDecl to model deduction guides rather than just treating them as FunctionDecls with a funny name. No functionality change intended. llvm-svn: 295491
2017-02-18 04:05:37 +08:00
Decl *
TemplateDeclInstantiator::VisitCXXDeductionGuideDecl(CXXDeductionGuideDecl *D) {
return VisitFunctionDecl(D, nullptr);
}
Switch Decl instantiation to DeclNodes.inc. This replaces a long list of declarations for visitor functions with a list generated from DeclNodes.inc. Nothing really interesting came out of it; we had comprehensive coverage anyway (excluding FriendTemplateDecls). llvm-svn: 185118
2013-06-28 07:21:55 +08:00
Decl *TemplateDeclInstantiator::VisitCXXMethodDecl(CXXMethodDecl *D) {
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return VisitCXXMethodDecl(D, nullptr);
Switch Decl instantiation to DeclNodes.inc. This replaces a long list of declarations for visitor functions with a list generated from DeclNodes.inc. Nothing really interesting came out of it; we had comprehensive coverage anyway (excluding FriendTemplateDecls). llvm-svn: 185118
2013-06-28 07:21:55 +08:00
}
Decl *TemplateDeclInstantiator::VisitRecordDecl(RecordDecl *D) {
llvm_unreachable("There are only CXXRecordDecls in C++");
}
Decl *
TemplateDeclInstantiator::VisitClassTemplateSpecializationDecl(
ClassTemplateSpecializationDecl *D) {
PR18232: implement instantiation for class-scope explicit specializations of class templates (a Microsoft extension). llvm-svn: 197298
2013-12-14 09:04:22 +08:00
// As a MS extension, we permit class-scope explicit specialization
// of member class templates.
ClassTemplateDecl *ClassTemplate = D->getSpecializedTemplate();
assert(ClassTemplate->getDeclContext()->isRecord() &&
D->getTemplateSpecializationKind() == TSK_ExplicitSpecialization &&
"can only instantiate an explicit specialization "
"for a member class template");
// Lookup the already-instantiated declaration in the instantiation
// of the class template. FIXME: Diagnose or assert if this fails?
DeclContext::lookup_result Found
= Owner->lookup(ClassTemplate->getDeclName());
if (Found.empty())
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
PR18232: implement instantiation for class-scope explicit specializations of class templates (a Microsoft extension). llvm-svn: 197298
2013-12-14 09:04:22 +08:00
ClassTemplateDecl *InstClassTemplate
= dyn_cast<ClassTemplateDecl>(Found.front());
if (!InstClassTemplate)
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
PR18232: implement instantiation for class-scope explicit specializations of class templates (a Microsoft extension). llvm-svn: 197298
2013-12-14 09:04:22 +08:00
// Substitute into the template arguments of the class template explicit
// specialization.
TemplateSpecializationTypeLoc Loc = D->getTypeAsWritten()->getTypeLoc().
castAs<TemplateSpecializationTypeLoc>();
TemplateArgumentListInfo InstTemplateArgs(Loc.getLAngleLoc(),
Loc.getRAngleLoc());
SmallVector<TemplateArgumentLoc, 4> ArgLocs;
for (unsigned I = 0; I != Loc.getNumArgs(); ++I)
ArgLocs.push_back(Loc.getArgLoc(I));
if (SemaRef.Subst(ArgLocs.data(), ArgLocs.size(),
InstTemplateArgs, TemplateArgs))
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
PR18232: implement instantiation for class-scope explicit specializations of class templates (a Microsoft extension). llvm-svn: 197298
2013-12-14 09:04:22 +08:00
// Check that the template argument list is well-formed for this
// class template.
SmallVector<TemplateArgument, 4> Converted;
if (SemaRef.CheckTemplateArgumentList(InstClassTemplate,
D->getLocation(),
InstTemplateArgs,
false,
Converted))
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
PR18232: implement instantiation for class-scope explicit specializations of class templates (a Microsoft extension). llvm-svn: 197298
2013-12-14 09:04:22 +08:00
// Figure out where to insert this class template explicit specialization
// in the member template's set of class template explicit specializations.
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
void *InsertPos = nullptr;
PR18232: implement instantiation for class-scope explicit specializations of class templates (a Microsoft extension). llvm-svn: 197298
2013-12-14 09:04:22 +08:00
ClassTemplateSpecializationDecl *PrevDecl =
Convert some function arguments to use ArrayRef. llvm-svn: 211764
2014-06-26 12:58:53 +08:00
InstClassTemplate->findSpecialization(Converted, InsertPos);
PR18232: implement instantiation for class-scope explicit specializations of class templates (a Microsoft extension). llvm-svn: 197298
2013-12-14 09:04:22 +08:00
// Check whether we've already seen a conflicting instantiation of this
// declaration (for instance, if there was a prior implicit instantiation).
bool Ignored;
if (PrevDecl &&
SemaRef.CheckSpecializationInstantiationRedecl(D->getLocation(),
D->getSpecializationKind(),
PrevDecl,
PrevDecl->getSpecializationKind(),
PrevDecl->getPointOfInstantiation(),
Ignored))
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
PR18232: implement instantiation for class-scope explicit specializations of class templates (a Microsoft extension). llvm-svn: 197298
2013-12-14 09:04:22 +08:00
// If PrevDecl was a definition and D is also a definition, diagnose.
// This happens in cases like:
//
// template<typename T, typename U>
// struct Outer {
// template<typename X> struct Inner;
// template<> struct Inner<T> {};
// template<> struct Inner<U> {};
// };
//
// Outer<int, int> outer; // error: the explicit specializations of Inner
// // have the same signature.
if (PrevDecl && PrevDecl->getDefinition() &&
D->isThisDeclarationADefinition()) {
SemaRef.Diag(D->getLocation(), diag::err_redefinition) << PrevDecl;
SemaRef.Diag(PrevDecl->getDefinition()->getLocation(),
diag::note_previous_definition);
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
PR18232: implement instantiation for class-scope explicit specializations of class templates (a Microsoft extension). llvm-svn: 197298
2013-12-14 09:04:22 +08:00
}
// Create the class template partial specialization declaration.
ClassTemplateSpecializationDecl *InstD
= ClassTemplateSpecializationDecl::Create(SemaRef.Context,
D->getTagKind(),
Owner,
D->getLocStart(),
D->getLocation(),
InstClassTemplate,
[AST] Use ArrayRef in more interfaces ArrayRef is a little better than passing around a pointer/length pair. No functional change is intended. llvm-svn: 274475
2016-07-04 05:17:51 +08:00
Converted,
PR18232: implement instantiation for class-scope explicit specializations of class templates (a Microsoft extension). llvm-svn: 197298
2013-12-14 09:04:22 +08:00
PrevDecl);
// Add this partial specialization to the set of class template partial
// specializations.
if (!PrevDecl)
InstClassTemplate->AddSpecialization(InstD, InsertPos);
// Substitute the nested name specifier, if any.
if (SubstQualifier(D, InstD))
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
PR18232: implement instantiation for class-scope explicit specializations of class templates (a Microsoft extension). llvm-svn: 197298
2013-12-14 09:04:22 +08:00
// Build the canonical type that describes the converted template
// arguments of the class template explicit specialization.
QualType CanonType = SemaRef.Context.getTemplateSpecializationType(
[AST] Use ArrayRef in more interfaces ArrayRef is a little better than passing around a pointer/length pair. No functional change is intended. llvm-svn: 274732
2016-07-07 12:43:07 +08:00
TemplateName(InstClassTemplate), Converted,
PR18232: implement instantiation for class-scope explicit specializations of class templates (a Microsoft extension). llvm-svn: 197298
2013-12-14 09:04:22 +08:00
SemaRef.Context.getRecordType(InstD));
// Build the fully-sugared type for this class template
// specialization as the user wrote in the specialization
// itself. This means that we'll pretty-print the type retrieved
// from the specialization's declaration the way that the user
// actually wrote the specialization, rather than formatting the
// name based on the "canonical" representation used to store the
// template arguments in the specialization.
TypeSourceInfo *WrittenTy = SemaRef.Context.getTemplateSpecializationTypeInfo(
TemplateName(InstClassTemplate), D->getLocation(), InstTemplateArgs,
CanonType);
InstD->setAccess(D->getAccess());
InstD->setInstantiationOfMemberClass(D, TSK_ImplicitInstantiation);
InstD->setSpecializationKind(D->getSpecializationKind());
InstD->setTypeAsWritten(WrittenTy);
InstD->setExternLoc(D->getExternLoc());
InstD->setTemplateKeywordLoc(D->getTemplateKeywordLoc());
Owner->addDecl(InstD);
// Instantiate the members of the class-scope explicit specialization eagerly.
// We don't have support for lazy instantiation of an explicit specialization
// yet, and MSVC eagerly instantiates in this case.
if (D->isThisDeclarationADefinition() &&
SemaRef.InstantiateClass(D->getLocation(), InstD, D, TemplateArgs,
TSK_ImplicitInstantiation,
/*Complain=*/true))
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
PR18232: implement instantiation for class-scope explicit specializations of class templates (a Microsoft extension). llvm-svn: 197298
2013-12-14 09:04:22 +08:00
return InstD;
Switch Decl instantiation to DeclNodes.inc. This replaces a long list of declarations for visitor functions with a list generated from DeclNodes.inc. Nothing really interesting came out of it; we had comprehensive coverage anyway (excluding FriendTemplateDecls). llvm-svn: 185118
2013-06-28 07:21:55 +08:00
}
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
Decl *TemplateDeclInstantiator::VisitVarTemplateSpecializationDecl(
VarTemplateSpecializationDecl *D) {
TemplateArgumentListInfo VarTemplateArgsInfo;
VarTemplateDecl *VarTemplate = D->getSpecializedTemplate();
assert(VarTemplate &&
"A template specialization without specialized template?");
// Substitute the current template arguments.
const TemplateArgumentListInfo &TemplateArgsInfo = D->getTemplateArgsInfo();
VarTemplateArgsInfo.setLAngleLoc(TemplateArgsInfo.getLAngleLoc());
VarTemplateArgsInfo.setRAngleLoc(TemplateArgsInfo.getRAngleLoc());
if (SemaRef.Subst(TemplateArgsInfo.getArgumentArray(),
TemplateArgsInfo.size(), VarTemplateArgsInfo, TemplateArgs))
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
// Check that the template argument list is well-formed for this template.
SmallVector<TemplateArgument, 4> Converted;
if (SemaRef.CheckTemplateArgumentList(
VarTemplate, VarTemplate->getLocStart(),
const_cast<TemplateArgumentListInfo &>(VarTemplateArgsInfo), false,
PR18401: Fix assert by implementing the current proposed direction of core issue 1430. Don't allow a pack expansion to be used as an argument to an alias template unless the corresponding parameter is a parameter pack. llvm-svn: 198833
2014-01-09 10:22:22 +08:00
Converted))
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
// Find the variable template specialization declaration that
// corresponds to these arguments.
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
void *InsertPos = nullptr;
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
if (VarTemplateSpecializationDecl *VarSpec = VarTemplate->findSpecialization(
Convert some function arguments to use ArrayRef. llvm-svn: 211764
2014-06-26 12:58:53 +08:00
Converted, InsertPos))
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
// If we already have a variable template specialization, return it.
return VarSpec;
return VisitVarTemplateSpecializationDecl(VarTemplate, D, InsertPos,
VarTemplateArgsInfo, Converted);
}
Decl *TemplateDeclInstantiator::VisitVarTemplateSpecializationDecl(
VarTemplateDecl *VarTemplate, VarDecl *D, void *InsertPos,
const TemplateArgumentListInfo &TemplateArgsInfo,
Remove llvm:: from uses of ArrayRef. llvm-svn: 211987
2014-06-29 07:22:23 +08:00
ArrayRef<TemplateArgument> Converted) {
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
// Do substitution on the type of the declaration
TypeSourceInfo *DI =
SemaRef.SubstType(D->getTypeSourceInfo(), TemplateArgs,
D->getTypeSpecStartLoc(), D->getDeclName());
if (!DI)
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
if (DI->getType()->isFunctionType()) {
SemaRef.Diag(D->getLocation(), diag::err_variable_instantiates_to_function)
<< D->isStaticDataMember() << DI->getType();
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
}
// Build the instantiated declaration
VarTemplateSpecializationDecl *Var = VarTemplateSpecializationDecl::Create(
SemaRef.Context, Owner, D->getInnerLocStart(), D->getLocation(),
[AST] Use ArrayRef in more interfaces ArrayRef is a little better than passing around a pointer/length pair. No functional change is intended. llvm-svn: 274475
2016-07-04 05:17:51 +08:00
VarTemplate, DI->getType(), DI, D->getStorageClass(), Converted);
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
Var->setTemplateArgsInfo(TemplateArgsInfo);
Variable templates: handle instantiation of static data member templates appropriately, especially when they appear within class templates. llvm-svn: 191548
2013-09-28 04:14:12 +08:00
if (InsertPos)
VarTemplate->AddSpecialization(Var, InsertPos);
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
// Substitute the nested name specifier, if any.
if (SubstQualifier(D, Var))
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
SemaRef.BuildVariableInstantiation(Var, D, TemplateArgs, LateAttrs,
Switch the semantic DeclContext for a block-scope declaration of a function or variable from being the function to being the enclosing namespace scope (in C++) or the TU (in C). This allows us to fix a selection of related issues where we would build incorrect redeclaration chains for such declarations, and fail to notice type mismatches. Such declarations are put into a new IdentifierNamespace, IDNS_LocalExtern, which is only found when searching scopes, and not found when searching DeclContexts. Such a declaration is only made visible in its DeclContext if there are no non-LocalExtern declarations. llvm-svn: 191064
2013-09-20 09:15:31 +08:00
Owner, StartingScope);
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
return Var;
}
Switch Decl instantiation to DeclNodes.inc. This replaces a long list of declarations for visitor functions with a list generated from DeclNodes.inc. Nothing really interesting came out of it; we had comprehensive coverage anyway (excluding FriendTemplateDecls). llvm-svn: 185118
2013-06-28 07:21:55 +08:00
Decl *TemplateDeclInstantiator::VisitObjCAtDefsFieldDecl(ObjCAtDefsFieldDecl *D) {
llvm_unreachable("@defs is not supported in Objective-C++");
}
Decl *TemplateDeclInstantiator::VisitFriendTemplateDecl(FriendTemplateDecl *D) {
// FIXME: We need to be able to instantiate FriendTemplateDecls.
unsigned DiagID = SemaRef.getDiagnostics().getCustomDiagID(
DiagnosticsEngine::Error,
"cannot instantiate %0 yet");
SemaRef.Diag(D->getLocation(), DiagID)
<< D->getDeclKindName();
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Switch Decl instantiation to DeclNodes.inc. This replaces a long list of declarations for visitor functions with a list generated from DeclNodes.inc. Nothing really interesting came out of it; we had comprehensive coverage anyway (excluding FriendTemplateDecls). llvm-svn: 185118
2013-06-28 07:21:55 +08:00
}
Decl *TemplateDeclInstantiator::VisitDecl(Decl *D) {
llvm_unreachable("Unexpected decl");
}
Clarify the difference between substitution and instantiation by renaming functions that don't instantiate definitions. llvm-svn: 80037
2009-08-26 06:02:44 +08:00
Decl *Sema::SubstDecl(Decl *D, DeclContext *Owner,
Implement template instantiation for member class templates. When performing template instantiation of the definitions of member templates (or members thereof), we build a data structure containing the template arguments from each "level" of template instantiation. During template instantiation, we substitute all levels of template arguments simultaneously. llvm-svn: 80389
2009-08-29 04:31:08 +08:00
const MultiLevelTemplateArgumentList &TemplateArgs) {
Encapsulate template arguments lists in a new class, TemplateArgumentList. This avoids the need to pass around pointer/length pairs of template arguments lists, and will eventually make it easier to introduce member templates and variadic templates. llvm-svn: 71517
2009-05-12 07:53:27 +08:00
TemplateDeclInstantiator Instantiator(*this, Owner, TemplateArgs);
Do not try to instantiate invalid declarations. It's a recipe for disaster. Fixes PR6161. llvm-svn: 96371
2010-02-17 03:28:15 +08:00
if (D->isInvalidDecl())
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Do not try to instantiate invalid declarations. It's a recipe for disaster. Fixes PR6161. llvm-svn: 96371
2010-02-17 03:28:15 +08:00
Refactor instantiation of declarations within a template into a much cleaner visitor framework. Added a visitor for declarations, which is quite similar to the visitor for statatements. llvm-svn: 67104
2009-03-18 05:15:40 +08:00
return Instantiator.Visit(D);
}
Basic nested-template implementation. llvm-svn: 79504
2009-08-20 09:44:21 +08:00
/// \brief Instantiates a nested template parameter list in the current
/// instantiation context.
///
/// \param L The parameter list to instantiate
///
/// \returns NULL if there was an error
TemplateParameterList *
Clarify the difference between substitution and instantiation by renaming functions that don't instantiate definitions. llvm-svn: 80037
2009-08-26 06:02:44 +08:00
TemplateDeclInstantiator::SubstTemplateParams(TemplateParameterList *L) {
Basic nested-template implementation. llvm-svn: 79504
2009-08-20 09:44:21 +08:00
// Get errors for all the parameters before bailing out.
bool Invalid = false;
unsigned N = L->size();
remove unneeded llvm:: namespace qualifiers on some core types now that LLVM.h imports them into the clang namespace. llvm-svn: 135852
2011-07-23 18:55:15 +08:00
typedef SmallVector<NamedDecl *, 8> ParamVector;
Basic nested-template implementation. llvm-svn: 79504
2009-08-20 09:44:21 +08:00
ParamVector Params;
Params.reserve(N);
[Sema] Range-loopify SemaTemplateInstantiateDecl.cpp. NFC. llvm-svn: 241291
2015-07-03 03:20:11 +08:00
for (auto &P : *L) {
NamedDecl *D = cast_or_null<NamedDecl>(Visit(P));
Basic nested-template implementation. llvm-svn: 79504
2009-08-20 09:44:21 +08:00
Params.push_back(D);
Before checking a template template argument against its corresponding template template parameter, substitute any prior template arguments into the template template parameter. This, for example, allows us to properly check the template template argument for a class such as: template<typename T, template<T Value> class X> struct Foo; The actual implementation of this feature was trivial; most of the change is dedicated to giving decent diagnostics when this substitution goes horribly wrong. We now get a note like: note: while substituting prior template arguments into template template parameter 'X' [with T = float] As part of this change, enabled some very pedantic checking when comparing template template parameter lists, which shook out a bug in our overly-eager checking of default arguments of template template parameters. We now perform only minimal checking of such default arguments when they are initially parsed. llvm-svn: 86864
2009-11-12 03:13:48 +08:00
Invalid = Invalid || !D || D->isInvalidDecl();
Basic nested-template implementation. llvm-svn: 79504
2009-08-20 09:44:21 +08:00
}
// Clean up if we had an error.
Remove the vast majority of the Destroy methods from the AST library, since we aren't going to be calling them ever. llvm-svn: 109377
2010-07-26 02:17:45 +08:00
if (Invalid)
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Basic nested-template implementation. llvm-svn: 79504
2009-08-20 09:44:21 +08:00
Reapply r276069 with workaround for MSVC 2013 llvm-svn: 277286
2016-07-31 06:33:34 +08:00
// Note: we substitute into associated constraints later
Expr *const UninstantiatedRequiresClause = L->getRequiresClause();
Basic nested-template implementation. llvm-svn: 79504
2009-08-20 09:44:21 +08:00
TemplateParameterList *InstL
= TemplateParameterList::Create(SemaRef.Context, L->getTemplateLoc(),
ArrayRef-ize TemplateParameterList. NFC llvm-svn: 256463
2015-12-27 15:16:27 +08:00
L->getLAngleLoc(), Params,
Reapply r276069 with workaround for MSVC 2013 llvm-svn: 277286
2016-07-31 06:33:34 +08:00
L->getRAngleLoc(),
UninstantiatedRequiresClause);
Basic nested-template implementation. llvm-svn: 79504
2009-08-20 09:44:21 +08:00
return InstL;
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
}
Basic nested-template implementation. llvm-svn: 79504
2009-08-20 09:44:21 +08:00
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
/// \brief Instantiate the declaration of a class template partial
Implement support for semantic checking and template instantiation of class template partial specializations of member templates. Also, fixes a silly little bug in the marking of "used" template parameters in member templates. Fixes PR5236. llvm-svn: 85447
2009-10-29 08:04:11 +08:00
/// specialization.
///
/// \param ClassTemplate the (instantiated) class template that is partially
// specialized by the instantiation of \p PartialSpec.
///
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
/// \param PartialSpec the (uninstantiated) class template partial
Implement support for semantic checking and template instantiation of class template partial specializations of member templates. Also, fixes a silly little bug in the marking of "used" template parameters in member templates. Fixes PR5236. llvm-svn: 85447
2009-10-29 08:04:11 +08:00
/// specialization that we are instantiating.
///
Instantiate class member template partial specialization declarations in the order they occur within the class template, delaying out-of-line member template partial specializations until after the class has been fully instantiated. This fixes a regression introduced by r118454 (itself a fix for PR8001). llvm-svn: 118704
2010-11-11 03:44:59 +08:00
/// \returns The instantiated partial specialization, if successful; otherwise,
/// NULL to indicate an error.
ClassTemplatePartialSpecializationDecl *
Implement support for semantic checking and template instantiation of class template partial specializations of member templates. Also, fixes a silly little bug in the marking of "used" template parameters in member templates. Fixes PR5236. llvm-svn: 85447
2009-10-29 08:04:11 +08:00
TemplateDeclInstantiator::InstantiateClassTemplatePartialSpecialization(
ClassTemplateDecl *ClassTemplate,
ClassTemplatePartialSpecializationDecl *PartialSpec) {
Implement "incremental" template instantiation for non-type template parameters and template type parameters, which occurs when substituting into the declarations of member templates inside class templates. This eliminates errors about our inability to "reduce non-type template parameter depth", fixing PR5311. Also fixes a bug when instantiating a template type parameter declaration in a member template, where we weren't properly reducing the template parameter's depth. LLVM's StringSwitch header now parses. llvm-svn: 85669
2009-11-01 01:21:17 +08:00
// Create a local instantiation scope for this class template partial
// specialization, which will contain the instantiations of the template
// parameters.
Move more stuff out of Sema.h. llvm-svn: 112026
2010-08-25 13:32:35 +08:00
LocalInstantiationScope Scope(SemaRef);
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Implement support for semantic checking and template instantiation of class template partial specializations of member templates. Also, fixes a silly little bug in the marking of "used" template parameters in member templates. Fixes PR5236. llvm-svn: 85447
2009-10-29 08:04:11 +08:00
// Substitute into the template parameters of the class template partial
// specialization.
TemplateParameterList *TempParams = PartialSpec->getTemplateParameters();
TemplateParameterList *InstParams = SubstTemplateParams(TempParams);
if (!InstParams)
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Implement support for semantic checking and template instantiation of class template partial specializations of member templates. Also, fixes a silly little bug in the marking of "used" template parameters in member templates. Fixes PR5236. llvm-svn: 85447
2009-10-29 08:04:11 +08:00
// Substitute into the template arguments of the class template partial
// specialization.
Added source locs for angled parentheses in class/var template partial specs. llvm-svn: 188134
2013-08-10 15:24:53 +08:00
const ASTTemplateArgumentListInfo *TemplArgInfo
= PartialSpec->getTemplateArgsAsWritten();
TemplateArgumentListInfo InstTemplateArgs(TemplArgInfo->LAngleLoc,
TemplArgInfo->RAngleLoc);
if (SemaRef.Subst(TemplArgInfo->getTemplateArgs(),
TemplArgInfo->NumTemplateArgs,
Implement template argument deduction for pack expansions whose pattern is a template argument, which involves repeatedly deducing template arguments using the pattern of the pack expansion, then bundling the resulting deductions into an argument pack. We can now handle a variety of simple list-handling metaprograms using variadic templates. See, e.g., the new "count" metaprogram. llvm-svn: 122439
2010-12-23 05:19:48 +08:00
InstTemplateArgs, TemplateArgs))
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Implement support for semantic checking and template instantiation of class template partial specializations of member templates. Also, fixes a silly little bug in the marking of "used" template parameters in member templates. Fixes PR5236. llvm-svn: 85447
2009-10-29 08:04:11 +08:00
// Check that the template argument list is well-formed for this
// class template.
remove unneeded llvm:: namespace qualifiers on some core types now that LLVM.h imports them into the clang namespace. llvm-svn: 135852
2011-07-23 18:55:15 +08:00
SmallVector<TemplateArgument, 4> Converted;
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
if (SemaRef.CheckTemplateArgumentList(ClassTemplate,
Implement support for semantic checking and template instantiation of class template partial specializations of member templates. Also, fixes a silly little bug in the marking of "used" template parameters in member templates. Fixes PR5236. llvm-svn: 85447
2009-10-29 08:04:11 +08:00
PartialSpec->getLocation(),
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
InstTemplateArgs,
Implement support for semantic checking and template instantiation of class template partial specializations of member templates. Also, fixes a silly little bug in the marking of "used" template parameters in member templates. Fixes PR5236. llvm-svn: 85447
2009-10-29 08:04:11 +08:00
false,
Converted))
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Implement support for semantic checking and template instantiation of class template partial specializations of member templates. Also, fixes a silly little bug in the marking of "used" template parameters in member templates. Fixes PR5236. llvm-svn: 85447
2009-10-29 08:04:11 +08:00
DR1315: a non-type template argument in a partial specialization is permitted to make reference to template parameters. This is only a partial implementation; we retain the restriction that the argument must not be type-dependent, since it's unclear how that would work given the existence of other language rules requiring an exact type match in this context, even for type-dependent cases (a question has been raised on the core reflector). llvm-svn: 290647
2016-12-28 10:37:25 +08:00
// Check these arguments are valid for a template partial specialization.
if (SemaRef.CheckTemplatePartialSpecializationArgs(
PartialSpec->getLocation(), ClassTemplate, InstTemplateArgs.size(),
Converted))
return nullptr;
Implement support for semantic checking and template instantiation of class template partial specializations of member templates. Also, fixes a silly little bug in the marking of "used" template parameters in member templates. Fixes PR5236. llvm-svn: 85447
2009-10-29 08:04:11 +08:00
// Figure out where to insert this class template partial specialization
// in the member template's set of class template partial specializations.
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
void *InsertPos = nullptr;
Implement support for semantic checking and template instantiation of class template partial specializations of member templates. Also, fixes a silly little bug in the marking of "used" template parameters in member templates. Fixes PR5236. llvm-svn: 85447
2009-10-29 08:04:11 +08:00
ClassTemplateSpecializationDecl *PrevDecl
Convert some function arguments to use ArrayRef. llvm-svn: 211764
2014-06-26 12:58:53 +08:00
= ClassTemplate->findPartialSpecialization(Converted, InsertPos);
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Implement support for semantic checking and template instantiation of class template partial specializations of member templates. Also, fixes a silly little bug in the marking of "used" template parameters in member templates. Fixes PR5236. llvm-svn: 85447
2009-10-29 08:04:11 +08:00
// Build the canonical type that describes the converted template
// arguments of the class template partial specialization.
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
QualType CanonType
Implement support for semantic checking and template instantiation of class template partial specializations of member templates. Also, fixes a silly little bug in the marking of "used" template parameters in member templates. Fixes PR5236. llvm-svn: 85447
2009-10-29 08:04:11 +08:00
= SemaRef.Context.getTemplateSpecializationType(TemplateName(ClassTemplate),
[AST] Use ArrayRef in more interfaces ArrayRef is a little better than passing around a pointer/length pair. No functional change is intended. llvm-svn: 274732
2016-07-07 12:43:07 +08:00
Converted);
Implement support for semantic checking and template instantiation of class template partial specializations of member templates. Also, fixes a silly little bug in the marking of "used" template parameters in member templates. Fixes PR5236. llvm-svn: 85447
2009-10-29 08:04:11 +08:00
// Build the fully-sugared type for this class template
// specialization as the user wrote in the specialization
// itself. This means that we'll pretty-print the type retrieved
// from the specialization's declaration the way that the user
// actually wrote the specialization, rather than formatting the
// name based on the "canonical" representation used to store the
// template arguments in the specialization.
Create a new InjectedClassNameType to represent bare-word references to the injected class name of a class template or class template partial specialization. This is a non-canonical type; the canonical type is still a template specialization type. This becomes the TypeForDecl of the pattern declaration, which cleans up some amount of code (and complicates some other parts, but whatever). Fixes PR6326 and probably a few others, primarily by re-establishing a few invariants about TypeLoc sizes. llvm-svn: 98134
2010-03-10 11:28:59 +08:00
TypeSourceInfo *WrittenTy
= SemaRef.Context.getTemplateSpecializationTypeInfo(
TemplateName(ClassTemplate),
PartialSpec->getLocation(),
Encapsulate "an array of TemplateArgumentLocs and two angle bracket locations" into a new class. Use it pervasively throughout Sema. My fingers hurt. llvm-svn: 89638
2009-11-23 09:53:49 +08:00
InstTemplateArgs,
Implement support for semantic checking and template instantiation of class template partial specializations of member templates. Also, fixes a silly little bug in the marking of "used" template parameters in member templates. Fixes PR5236. llvm-svn: 85447
2009-10-29 08:04:11 +08:00
CanonType);
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Implement support for semantic checking and template instantiation of class template partial specializations of member templates. Also, fixes a silly little bug in the marking of "used" template parameters in member templates. Fixes PR5236. llvm-svn: 85447
2009-10-29 08:04:11 +08:00
if (PrevDecl) {
// We've already seen a partial specialization with the same template
// parameters and template arguments. This can happen, for example, when
// substituting the outer template arguments ends up causing two
// class template partial specializations of a member class template
// to have identical forms, e.g.,
//
// template<typename T, typename U>
// struct Outer {
// template<typename X, typename Y> struct Inner;
// template<typename Y> struct Inner<T, Y>;
// template<typename Y> struct Inner<U, Y>;
// };
//
// Outer<int, int> outer; // error: the partial specializations of Inner
// // have the same signature.
SemaRef.Diag(PartialSpec->getLocation(), diag::err_partial_spec_redeclared)
Instantiate class member template partial specialization declarations in the order they occur within the class template, delaying out-of-line member template partial specializations until after the class has been fully instantiated. This fixes a regression introduced by r118454 (itself a fix for PR8001). llvm-svn: 118704
2010-11-11 03:44:59 +08:00
<< WrittenTy->getType();
Implement support for semantic checking and template instantiation of class template partial specializations of member templates. Also, fixes a silly little bug in the marking of "used" template parameters in member templates. Fixes PR5236. llvm-svn: 85447
2009-10-29 08:04:11 +08:00
SemaRef.Diag(PrevDecl->getLocation(), diag::note_prev_partial_spec_here)
<< SemaRef.Context.getTypeDeclType(PrevDecl);
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Implement support for semantic checking and template instantiation of class template partial specializations of member templates. Also, fixes a silly little bug in the marking of "used" template parameters in member templates. Fixes PR5236. llvm-svn: 85447
2009-10-29 08:04:11 +08:00
}
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Implement support for semantic checking and template instantiation of class template partial specializations of member templates. Also, fixes a silly little bug in the marking of "used" template parameters in member templates. Fixes PR5236. llvm-svn: 85447
2009-10-29 08:04:11 +08:00
// Create the class template partial specialization declaration.
ClassTemplatePartialSpecializationDecl *InstPartialSpec
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
= ClassTemplatePartialSpecializationDecl::Create(SemaRef.Context,
Partial and full specializations of a class template may have a different tag kind ("struct" vs. "class") than the primary template, which has an affect on access control. Should fix the last remaining Boost.Accumulors failure. llvm-svn: 103144
2010-05-06 08:28:52 +08:00
PartialSpec->getTagKind(),
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Owner,
Fixed InnerLocStart. llvm-svn: 127330
2011-03-09 22:09:51 +08:00
PartialSpec->getLocStart(),
PartialSpec->getLocation(),
Implement support for semantic checking and template instantiation of class template partial specializations of member templates. Also, fixes a silly little bug in the marking of "used" template parameters in member templates. Fixes PR5236. llvm-svn: 85447
2009-10-29 08:04:11 +08:00
InstParams,
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
ClassTemplate,
[AST] Use ArrayRef in more interfaces ArrayRef is a little better than passing around a pointer/length pair. No functional change is intended. llvm-svn: 274475
2016-07-04 05:17:51 +08:00
Converted,
Encapsulate "an array of TemplateArgumentLocs and two angle bracket locations" into a new class. Use it pervasively throughout Sema. My fingers hurt. llvm-svn: 89638
2009-11-23 09:53:49 +08:00
InstTemplateArgs,
Create a new InjectedClassNameType to represent bare-word references to the injected class name of a class template or class template partial specialization. This is a non-canonical type; the canonical type is still a template specialization type. This becomes the TypeForDecl of the pattern declaration, which cleans up some amount of code (and complicates some other parts, but whatever). Fixes PR6326 and probably a few others, primarily by re-establishing a few invariants about TypeLoc sizes. llvm-svn: 98134
2010-03-10 11:28:59 +08:00
CanonType,
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
nullptr);
Remember declaration scope qualifiers in the AST. Imposes no memory overhead on unqualified declarations. Patch by Enea Zaffanella! Minimal adjustments: allocate the ExtInfo nodes with the ASTContext and delete them during Destroy(). I audited a bunch of Destroy methods at the same time, to ensure that the correct teardown was being done. llvm-svn: 98540
2010-03-15 18:12:16 +08:00
// Substitute the nested name specifier, if any.
if (SubstQualifier(PartialSpec, InstPartialSpec))
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Remember declaration scope qualifiers in the AST. Imposes no memory overhead on unqualified declarations. Patch by Enea Zaffanella! Minimal adjustments: allocate the ExtInfo nodes with the ASTContext and delete them during Destroy(). I audited a bunch of Destroy methods at the same time, to ensure that the correct teardown was being done. llvm-svn: 98540
2010-03-15 18:12:16 +08:00
Implement support for semantic checking and template instantiation of class template partial specializations of member templates. Also, fixes a silly little bug in the marking of "used" template parameters in member templates. Fixes PR5236. llvm-svn: 85447
2009-10-29 08:04:11 +08:00
InstPartialSpec->setInstantiatedFromMember(PartialSpec);
Revert r104106; it's breaking linking of Boost.Serialization. llvm-svn: 104121
2010-05-20 01:02:24 +08:00
InstPartialSpec->setTypeAsWritten(WrittenTy);
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
DR1315: a non-type template argument in a partial specialization is permitted to make reference to template parameters. This is only a partial implementation; we retain the restriction that the argument must not be type-dependent, since it's unclear how that would work given the existence of other language rules requiring an exact type match in this context, even for type-dependent cases (a question has been raised on the core reflector). llvm-svn: 290647
2016-12-28 10:37:25 +08:00
// Check the completed partial specialization.
SemaRef.CheckTemplatePartialSpecialization(InstPartialSpec);
Implement support for semantic checking and template instantiation of class template partial specializations of member templates. Also, fixes a silly little bug in the marking of "used" template parameters in member templates. Fixes PR5236. llvm-svn: 85447
2009-10-29 08:04:11 +08:00
// Add this partial specialization to the set of class template partial
// specializations.
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
ClassTemplate->AddPartialSpecialization(InstPartialSpec,
/*InsertPos=*/nullptr);
Instantiate class member template partial specialization declarations in the order they occur within the class template, delaying out-of-line member template partial specializations until after the class has been fully instantiated. This fixes a regression introduced by r118454 (itself a fix for PR8001). llvm-svn: 118704
2010-11-11 03:44:59 +08:00
return InstPartialSpec;
Implement support for semantic checking and template instantiation of class template partial specializations of member templates. Also, fixes a silly little bug in the marking of "used" template parameters in member templates. Fixes PR5236. llvm-svn: 85447
2009-10-29 08:04:11 +08:00
}
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
/// \brief Instantiate the declaration of a variable template partial
/// specialization.
///
/// \param VarTemplate the (instantiated) variable template that is partially
/// specialized by the instantiation of \p PartialSpec.
///
/// \param PartialSpec the (uninstantiated) variable template partial
/// specialization that we are instantiating.
///
/// \returns The instantiated partial specialization, if successful; otherwise,
/// NULL to indicate an error.
VarTemplatePartialSpecializationDecl *
TemplateDeclInstantiator::InstantiateVarTemplatePartialSpecialization(
VarTemplateDecl *VarTemplate,
VarTemplatePartialSpecializationDecl *PartialSpec) {
// Create a local instantiation scope for this variable template partial
// specialization, which will contain the instantiations of the template
// parameters.
LocalInstantiationScope Scope(SemaRef);
// Substitute into the template parameters of the variable template partial
// specialization.
TemplateParameterList *TempParams = PartialSpec->getTemplateParameters();
TemplateParameterList *InstParams = SubstTemplateParams(TempParams);
if (!InstParams)
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
// Substitute into the template arguments of the variable template partial
// specialization.
Added source locs for angled parentheses in class/var template partial specs. llvm-svn: 188134
2013-08-10 15:24:53 +08:00
const ASTTemplateArgumentListInfo *TemplArgInfo
= PartialSpec->getTemplateArgsAsWritten();
TemplateArgumentListInfo InstTemplateArgs(TemplArgInfo->LAngleLoc,
TemplArgInfo->RAngleLoc);
if (SemaRef.Subst(TemplArgInfo->getTemplateArgs(),
TemplArgInfo->NumTemplateArgs,
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
InstTemplateArgs, TemplateArgs))
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
// Check that the template argument list is well-formed for this
// class template.
SmallVector<TemplateArgument, 4> Converted;
if (SemaRef.CheckTemplateArgumentList(VarTemplate, PartialSpec->getLocation(),
InstTemplateArgs, false, Converted))
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
DR1315: a non-type template argument in a partial specialization is permitted to make reference to template parameters. This is only a partial implementation; we retain the restriction that the argument must not be type-dependent, since it's unclear how that would work given the existence of other language rules requiring an exact type match in this context, even for type-dependent cases (a question has been raised on the core reflector). llvm-svn: 290647
2016-12-28 10:37:25 +08:00
// Check these arguments are valid for a template partial specialization.
if (SemaRef.CheckTemplatePartialSpecializationArgs(
PartialSpec->getLocation(), VarTemplate, InstTemplateArgs.size(),
Converted))
return nullptr;
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
// Figure out where to insert this variable template partial specialization
// in the member template's set of variable template partial specializations.
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
void *InsertPos = nullptr;
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
VarTemplateSpecializationDecl *PrevDecl =
Convert some function arguments to use ArrayRef. llvm-svn: 211764
2014-06-26 12:58:53 +08:00
VarTemplate->findPartialSpecialization(Converted, InsertPos);
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
// Build the canonical type that describes the converted template
// arguments of the variable template partial specialization.
QualType CanonType = SemaRef.Context.getTemplateSpecializationType(
[AST] Use ArrayRef in more interfaces ArrayRef is a little better than passing around a pointer/length pair. No functional change is intended. llvm-svn: 274732
2016-07-07 12:43:07 +08:00
TemplateName(VarTemplate), Converted);
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
// Build the fully-sugared type for this variable template
// specialization as the user wrote in the specialization
// itself. This means that we'll pretty-print the type retrieved
// from the specialization's declaration the way that the user
// actually wrote the specialization, rather than formatting the
// name based on the "canonical" representation used to store the
// template arguments in the specialization.
TypeSourceInfo *WrittenTy = SemaRef.Context.getTemplateSpecializationTypeInfo(
TemplateName(VarTemplate), PartialSpec->getLocation(), InstTemplateArgs,
CanonType);
if (PrevDecl) {
// We've already seen a partial specialization with the same template
// parameters and template arguments. This can happen, for example, when
// substituting the outer template arguments ends up causing two
// variable template partial specializations of a member variable template
// to have identical forms, e.g.,
//
// template<typename T, typename U>
// struct Outer {
// template<typename X, typename Y> pair<X,Y> p;
// template<typename Y> pair<T, Y> p;
// template<typename Y> pair<U, Y> p;
// };
//
// Outer<int, int> outer; // error: the partial specializations of Inner
// // have the same signature.
SemaRef.Diag(PartialSpec->getLocation(),
diag::err_var_partial_spec_redeclared)
<< WrittenTy->getType();
SemaRef.Diag(PrevDecl->getLocation(),
diag::note_var_prev_partial_spec_here);
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
}
// Do substitution on the type of the declaration
TypeSourceInfo *DI = SemaRef.SubstType(
PartialSpec->getTypeSourceInfo(), TemplateArgs,
PartialSpec->getTypeSpecStartLoc(), PartialSpec->getDeclName());
if (!DI)
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
if (DI->getType()->isFunctionType()) {
SemaRef.Diag(PartialSpec->getLocation(),
diag::err_variable_instantiates_to_function)
<< PartialSpec->isStaticDataMember() << DI->getType();
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
}
// Create the variable template partial specialization declaration.
VarTemplatePartialSpecializationDecl *InstPartialSpec =
VarTemplatePartialSpecializationDecl::Create(
SemaRef.Context, Owner, PartialSpec->getInnerLocStart(),
PartialSpec->getLocation(), InstParams, VarTemplate, DI->getType(),
[AST] Use ArrayRef in more interfaces ArrayRef is a little better than passing around a pointer/length pair. No functional change is intended. llvm-svn: 274475
2016-07-04 05:17:51 +08:00
DI, PartialSpec->getStorageClass(), Converted, InstTemplateArgs);
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
// Substitute the nested name specifier, if any.
if (SubstQualifier(PartialSpec, InstPartialSpec))
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
InstPartialSpec->setInstantiatedFromMember(PartialSpec);
InstPartialSpec->setTypeAsWritten(WrittenTy);
DR1315: a non-type template argument in a partial specialization is permitted to make reference to template parameters. This is only a partial implementation; we retain the restriction that the argument must not be type-dependent, since it's unclear how that would work given the existence of other language rules requiring an exact type match in this context, even for type-dependent cases (a question has been raised on the core reflector). llvm-svn: 290647
2016-12-28 10:37:25 +08:00
// Check the completed partial specialization.
SemaRef.CheckTemplatePartialSpecialization(InstPartialSpec);
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
// Add this partial specialization to the set of variable template partial
// specializations. The instantiation of the initializer is not necessary.
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
VarTemplate->AddPartialSpecialization(InstPartialSpec, /*InsertPos=*/nullptr);
Improve support for static data member templates. This revision still has at least one bug, as it does not respect the variable template specialization hierarchy well. llvm-svn: 188969
2013-08-22 08:28:27 +08:00
SemaRef.BuildVariableInstantiation(InstPartialSpec, PartialSpec, TemplateArgs,
Switch the semantic DeclContext for a block-scope declaration of a function or variable from being the function to being the enclosing namespace scope (in C++) or the TU (in C). This allows us to fix a selection of related issues where we would build incorrect redeclaration chains for such declarations, and fail to notice type mismatches. Such declarations are put into a new IdentifierNamespace, IDNS_LocalExtern, which is only found when searching scopes, and not found when searching DeclContexts. Such a declaration is only made visible in its DeclContext if there are no non-LocalExtern declarations. llvm-svn: 191064
2013-09-20 09:15:31 +08:00
LateAttrs, Owner, StartingScope);
Improve support for static data member templates. This revision still has at least one bug, as it does not respect the variable template specialization hierarchy well. llvm-svn: 188969
2013-08-22 08:28:27 +08:00
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
return InstPartialSpec;
}
Maintain type source information for functions through template instantiation. Based on a patch by Enea Zaffanella! I found a way to reduce some of the redundancy between TreeTransform's "standard" FunctionProtoType transformation and TemplateInstantiator's override, and I killed off the old SubstFunctionType by adding type source info for the last cases where we were creating FunctionDecls without TSI (at least that get passed through template instantiation). llvm-svn: 98252
2010-03-11 17:03:00 +08:00
TypeSourceInfo*
TemplateDeclInstantiator::SubstFunctionType(FunctionDecl *D,
remove unneeded llvm:: namespace qualifiers on some core types now that LLVM.h imports them into the clang namespace. llvm-svn: 135852
2011-07-23 18:55:15 +08:00
SmallVectorImpl<ParmVarDecl *> &Params) {
Maintain type source information for functions through template instantiation. Based on a patch by Enea Zaffanella! I found a way to reduce some of the redundancy between TreeTransform's "standard" FunctionProtoType transformation and TemplateInstantiator's override, and I killed off the old SubstFunctionType by adding type source info for the last cases where we were creating FunctionDecls without TSI (at least that get passed through template instantiation). llvm-svn: 98252
2010-03-11 17:03:00 +08:00
TypeSourceInfo *OldTInfo = D->getTypeSourceInfo();
assert(OldTInfo && "substituting function without type source info");
assert(Params.empty() && "parameter vector is non-empty at start");
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
CXXRecordDecl *ThisContext = nullptr;
Implement C++11 [expr.prim.general]p3, which permits the use of 'this' in the declaration of a non-static member function after the (optional) cv-qualifier-seq, which in practice means in the exception specification and late-specified return type. The new scheme here used to manage 'this' outside of a member function scope is more general than the Scope-based mechanism previously used for non-static data member initializers and late-parsesd attributes, because it can also handle the cv-qualifiers on the member function. Note, however, that a separate pass is required for static member functions to determine whether 'this' was used, because we might not know that we have a static function until after declaration matching. Finally, this introduces name mangling for 'this' and for the implicit 'this', which is intended to match GCC's mangling. Independent verification for the new mangling test case would be appreciated. Fixes PR10036 and PR12450. llvm-svn: 154799
2012-04-16 15:05:22 +08:00
unsigned ThisTypeQuals = 0;
if (CXXMethodDecl *Method = dyn_cast<CXXMethodDecl>(D)) {
PR16243: Use CXXThisOverride during template instantiation, and fix up the places which weren't setting it up properly. This allows us to get the right cv-qualifiers for 'this' when it appears outside a method body in a class template. llvm-svn: 183483
2013-06-07 10:33:37 +08:00
ThisContext = cast<CXXRecordDecl>(Owner);
Implement C++11 [expr.prim.general]p3, which permits the use of 'this' in the declaration of a non-static member function after the (optional) cv-qualifier-seq, which in practice means in the exception specification and late-specified return type. The new scheme here used to manage 'this' outside of a member function scope is more general than the Scope-based mechanism previously used for non-static data member initializers and late-parsesd attributes, because it can also handle the cv-qualifiers on the member function. Note, however, that a separate pass is required for static member functions to determine whether 'this' was used, because we might not know that we have a static function until after declaration matching. Finally, this introduces name mangling for 'this' and for the implicit 'this', which is intended to match GCC's mangling. Independent verification for the new mangling test case would be appreciated. Fixes PR10036 and PR12450. llvm-svn: 154799
2012-04-16 15:05:22 +08:00
ThisTypeQuals = Method->getTypeQualifiers();
}
Instantiate default argument expressions even if their associated parameter type isn't dependent. Fixes rdar://problem/7838962. llvm-svn: 100871
2010-04-10 01:38:44 +08:00
TypeSourceInfo *NewTInfo
= SemaRef.SubstFunctionDeclType(OldTInfo, TemplateArgs,
D->getTypeSpecStartLoc(),
Implement C++11 [expr.prim.general]p3, which permits the use of 'this' in the declaration of a non-static member function after the (optional) cv-qualifier-seq, which in practice means in the exception specification and late-specified return type. The new scheme here used to manage 'this' outside of a member function scope is more general than the Scope-based mechanism previously used for non-static data member initializers and late-parsesd attributes, because it can also handle the cv-qualifiers on the member function. Note, however, that a separate pass is required for static member functions to determine whether 'this' was used, because we might not know that we have a static function until after declaration matching. Finally, this introduces name mangling for 'this' and for the implicit 'this', which is intended to match GCC's mangling. Independent verification for the new mangling test case would be appreciated. Fixes PR10036 and PR12450. llvm-svn: 154799
2012-04-16 15:05:22 +08:00
D->getDeclName(),
ThisContext, ThisTypeQuals);
Maintain type source information for functions through template instantiation. Based on a patch by Enea Zaffanella! I found a way to reduce some of the redundancy between TreeTransform's "standard" FunctionProtoType transformation and TemplateInstantiator's override, and I killed off the old SubstFunctionType by adding type source info for the last cases where we were creating FunctionDecls without TSI (at least that get passed through template instantiation). llvm-svn: 98252
2010-03-11 17:03:00 +08:00
if (!NewTInfo)
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Cleanup template instantiation for methods, destructors llvm-svn: 67585
2009-03-24 08:38:23 +08:00
Fix declaring class template methods with an attributed typedef This change unifies the logic for template instantiation of methods and functions declared with typedefs. It ensures that SubstFunctionType() always fills the Params out param with non-null ParmVarDecls or returns null. Reviewers: rsmith Differential Revision: http://llvm-reviews.chandlerc.com/D1135 llvm-svn: 187528
2013-08-01 05:00:18 +08:00
TypeLoc OldTL = OldTInfo->getTypeLoc().IgnoreParens();
if (FunctionProtoTypeLoc OldProtoLoc = OldTL.getAs<FunctionProtoTypeLoc>()) {
if (NewTInfo != OldTInfo) {
// Get parameters from the new type info.
Skip ParenType on function instantiations. llvm-svn: 121720
2010-12-14 06:27:55 +08:00
TypeLoc NewTL = NewTInfo->getTypeLoc().IgnoreParens();
Replace TypeLoc llvm::cast support to be well-defined. The TypeLoc hierarchy used the llvm::cast machinery to perform undefined behavior by casting pointers/references to TypeLoc objects to derived types and then using the derived copy constructors (or even returning pointers to derived types that actually point to the original TypeLoc object). Some context is in this thread: http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-December/056804.html Though it's spread over a few months which can be hard to read in the mail archive. llvm-svn: 175462
2013-02-19 06:06:02 +08:00
FunctionProtoTypeLoc NewProtoLoc = NewTL.castAs<FunctionProtoTypeLoc>();
PR13386: When matching up parameters between a function template declaration and a function template instantiation, if there's a parameter pack in the declaration and one at the same place in the instantiation, don't assume that the pack wasn't expanded -- it may have expanded to nothing. Instead, go ahead and check whether the parameter pack was expandable. We can do this as a side-effect of the work we'd need to do anyway, to find how many parameters were produced. llvm-svn: 160416
2012-07-18 09:29:05 +08:00
unsigned NewIdx = 0;
Update FunctionTypeLoc and related names to match r199686 llvm-svn: 199699
2014-01-21 08:32:38 +08:00
for (unsigned OldIdx = 0, NumOldParams = OldProtoLoc.getNumParams();
Implement substitution of a function parameter pack for its set of instantiated function parameters, enabling instantiation of arbitrary pack expansions involving function parameter packs. At this point, we can now correctly compile a simple, variadic print() example: #include <iostream> #include <string> void print() {} template<typename Head, typename ...Tail> void print(const Head &head, const Tail &...tail) { std::cout << head; print(tail...); } int main() { std::string hello = "Hello"; print(hello, ", world!", " ", 2011, '\n'); } llvm-svn: 123000
2011-01-08 00:43:16 +08:00
OldIdx != NumOldParams; ++OldIdx) {
Update FunctionTypeLoc and related names to match r199686 llvm-svn: 199699
2014-01-21 08:32:38 +08:00
ParmVarDecl *OldParam = OldProtoLoc.getParam(OldIdx);
PR13386: When matching up parameters between a function template declaration and a function template instantiation, if there's a parameter pack in the declaration and one at the same place in the instantiation, don't assume that the pack wasn't expanded -- it may have expanded to nothing. Instead, go ahead and check whether the parameter pack was expandable. We can do this as a side-effect of the work we'd need to do anyway, to find how many parameters were produced. llvm-svn: 160416
2012-07-18 09:29:05 +08:00
LocalInstantiationScope *Scope = SemaRef.CurrentInstantiationScope;
Include llvm::Optional in clang/Basic/LLVM.h Post-commit CR feedback from Jordan Rose regarding r175594. llvm-svn: 175679
2013-02-21 06:23:23 +08:00
Optional<unsigned> NumArgumentsInExpansion;
PR13386: When matching up parameters between a function template declaration and a function template instantiation, if there's a parameter pack in the declaration and one at the same place in the instantiation, don't assume that the pack wasn't expanded -- it may have expanded to nothing. Instead, go ahead and check whether the parameter pack was expandable. We can do this as a side-effect of the work we'd need to do anyway, to find how many parameters were produced. llvm-svn: 160416
2012-07-18 09:29:05 +08:00
if (OldParam->isParameterPack())
NumArgumentsInExpansion =
SemaRef.getNumArgumentsInExpansion(OldParam->getType(),
TemplateArgs);
if (!NumArgumentsInExpansion) {
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
// Simple case: normal parameter, or a parameter pack that's
Implement substitution of a function parameter pack for its set of instantiated function parameters, enabling instantiation of arbitrary pack expansions involving function parameter packs. At this point, we can now correctly compile a simple, variadic print() example: #include <iostream> #include <string> void print() {} template<typename Head, typename ...Tail> void print(const Head &head, const Tail &...tail) { std::cout << head; print(tail...); } int main() { std::string hello = "Hello"; print(hello, ", world!", " ", 2011, '\n'); } llvm-svn: 123000
2011-01-08 00:43:16 +08:00
// instantiated to a (still-dependent) parameter pack.
Update FunctionTypeLoc and related names to match r199686 llvm-svn: 199699
2014-01-21 08:32:38 +08:00
ParmVarDecl *NewParam = NewProtoLoc.getParam(NewIdx++);
Implement substitution of a function parameter pack for its set of instantiated function parameters, enabling instantiation of arbitrary pack expansions involving function parameter packs. At this point, we can now correctly compile a simple, variadic print() example: #include <iostream> #include <string> void print() {} template<typename Head, typename ...Tail> void print(const Head &head, const Tail &...tail) { std::cout << head; print(tail...); } int main() { std::string hello = "Hello"; print(hello, ", world!", " ", 2011, '\n'); } llvm-svn: 123000
2011-01-08 00:43:16 +08:00
Params.push_back(NewParam);
PR13386: When matching up parameters between a function template declaration and a function template instantiation, if there's a parameter pack in the declaration and one at the same place in the instantiation, don't assume that the pack wasn't expanded -- it may have expanded to nothing. Instead, go ahead and check whether the parameter pack was expandable. We can do this as a side-effect of the work we'd need to do anyway, to find how many parameters were produced. llvm-svn: 160416
2012-07-18 09:29:05 +08:00
Scope->InstantiatedLocal(OldParam, NewParam);
} else {
// Parameter pack expansion: make the instantiation an argument pack.
Scope->MakeInstantiatedLocalArgPack(OldParam);
for (unsigned I = 0; I != *NumArgumentsInExpansion; ++I) {
Update FunctionTypeLoc and related names to match r199686 llvm-svn: 199699
2014-01-21 08:32:38 +08:00
ParmVarDecl *NewParam = NewProtoLoc.getParam(NewIdx++);
PR13386: When matching up parameters between a function template declaration and a function template instantiation, if there's a parameter pack in the declaration and one at the same place in the instantiation, don't assume that the pack wasn't expanded -- it may have expanded to nothing. Instead, go ahead and check whether the parameter pack was expandable. We can do this as a side-effect of the work we'd need to do anyway, to find how many parameters were produced. llvm-svn: 160416
2012-07-18 09:29:05 +08:00
Params.push_back(NewParam);
Scope->InstantiatedLocalPackArg(OldParam, NewParam);
}
Implement substitution of a function parameter pack for its set of instantiated function parameters, enabling instantiation of arbitrary pack expansions involving function parameter packs. At this point, we can now correctly compile a simple, variadic print() example: #include <iostream> #include <string> void print() {} template<typename Head, typename ...Tail> void print(const Head &head, const Tail &...tail) { std::cout << head; print(tail...); } int main() { std::string hello = "Hello"; print(hello, ", world!", " ", 2011, '\n'); } llvm-svn: 123000
2011-01-08 00:43:16 +08:00
}
When instantiating a member function declared via a typedef, don't try to enter the instantiated parameter declarations into the local instantiation scope; they can't be referenced anyway. Fixes PR7022. llvm-svn: 102914
2010-05-03 23:32:18 +08:00
}
Fix declaring class template methods with an attributed typedef This change unifies the logic for template instantiation of methods and functions declared with typedefs. It ensures that SubstFunctionType() always fills the Params out param with non-null ParmVarDecls or returns null. Reviewers: rsmith Differential Revision: http://llvm-reviews.chandlerc.com/D1135 llvm-svn: 187528
2013-08-01 05:00:18 +08:00
} else {
// The function type itself was not dependent and therefore no
// substitution occurred. However, we still need to instantiate
// the function parameters themselves.
const FunctionProtoType *OldProto =
cast<FunctionProtoType>(OldProtoLoc.getType());
Update FunctionTypeLoc and related names to match r199686 llvm-svn: 199699
2014-01-21 08:32:38 +08:00
for (unsigned i = 0, i_end = OldProtoLoc.getNumParams(); i != i_end;
++i) {
ParmVarDecl *OldParam = OldProtoLoc.getParam(i);
Fix declaring class template methods with an attributed typedef This change unifies the logic for template instantiation of methods and functions declared with typedefs. It ensures that SubstFunctionType() always fills the Params out param with non-null ParmVarDecls or returns null. Reviewers: rsmith Differential Revision: http://llvm-reviews.chandlerc.com/D1135 llvm-svn: 187528
2013-08-01 05:00:18 +08:00
if (!OldParam) {
Params.push_back(SemaRef.BuildParmVarDeclForTypedef(
Rename FunctionProtoType accessors from 'arguments' to 'parameters' Fix a perennial source of confusion in the clang type system: Declarations and function prototypes have parameters to which arguments are supplied, so calling these 'arguments' was a stretch even in C mode, let alone C++ where default arguments, templates and overloading make the distinction important to get right. Readability win across the board, especially in the casting, ADL and overloading implementations which make a lot more sense at a glance now. Will keep an eye on the builders and update dependent projects shortly. No functional change. llvm-svn: 199686
2014-01-21 04:26:09 +08:00
D, D->getLocation(), OldProto->getParamType(i)));
Fix declaring class template methods with an attributed typedef This change unifies the logic for template instantiation of methods and functions declared with typedefs. It ensures that SubstFunctionType() always fills the Params out param with non-null ParmVarDecls or returns null. Reviewers: rsmith Differential Revision: http://llvm-reviews.chandlerc.com/D1135 llvm-svn: 187528
2013-08-01 05:00:18 +08:00
continue;
}
Switch Decl instantiation to DeclNodes.inc. This replaces a long list of declarations for visitor functions with a list generated from DeclNodes.inc. Nothing really interesting came out of it; we had comprehensive coverage anyway (excluding FriendTemplateDecls). llvm-svn: 185118
2013-06-28 07:21:55 +08:00
ParmVarDecl *Parm =
Fix declaring class template methods with an attributed typedef This change unifies the logic for template instantiation of methods and functions declared with typedefs. It ensures that SubstFunctionType() always fills the Params out param with non-null ParmVarDecls or returns null. Reviewers: rsmith Differential Revision: http://llvm-reviews.chandlerc.com/D1135 llvm-svn: 187528
2013-08-01 05:00:18 +08:00
cast_or_null<ParmVarDecl>(VisitParmVarDecl(OldParam));
When instantiating a member function declared via a typedef, don't try to enter the instantiated parameter declarations into the local instantiation scope; they can't be referenced anyway. Fixes PR7022. llvm-svn: 102914
2010-05-03 23:32:18 +08:00
if (!Parm)
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
When instantiating a member function declared via a typedef, don't try to enter the instantiated parameter declarations into the local instantiation scope; they can't be referenced anyway. Fixes PR7022. llvm-svn: 102914
2010-05-03 23:32:18 +08:00
Params.push_back(Parm);
}
Be sure to instantiate the parameters of a function, even when the function's type is (strictly speaking) non-dependent. This ensures that, e.g., default function arguments get instantiated properly. And, since I couldn't resist, collapse the two implementations of function-parameter instantiation into calls to a single, new function (Sema::SubstParmVarDecl), since the two had nearly identical code (and each had bugs the other didn't!). More importantly, factored out the semantic analysis of a parameter declaration into Sema::CheckParameter, which is called both by Sema::ActOnParamDeclarator (when parameters are parsed) and when a parameter is instantiated. Previously, we were missing some Objective-C and address-space checks on instantiated function parameters. Fixes PR6733. llvm-svn: 101029
2010-04-12 15:48:19 +08:00
}
Fix declaring class template methods with an attributed typedef This change unifies the logic for template instantiation of methods and functions declared with typedefs. It ensures that SubstFunctionType() always fills the Params out param with non-null ParmVarDecls or returns null. Reviewers: rsmith Differential Revision: http://llvm-reviews.chandlerc.com/D1135 llvm-svn: 187528
2013-08-01 05:00:18 +08:00
} else {
// If the type of this function, after ignoring parentheses, is not
// *directly* a function type, then we're instantiating a function that
// was declared via a typedef or with attributes, e.g.,
//
// typedef int functype(int, int);
// functype func;
// int __cdecl meth(int, int);
//
// In this case, we'll just go instantiate the ParmVarDecls that we
// synthesized in the method declaration.
SmallVector<QualType, 4> ParamTypes;
Fix the template instantiation of ExtParameterInfos; tests to follow. llvm-svn: 262289
2016-03-01 10:09:25 +08:00
Sema::ExtParameterInfoBuilder ExtParamInfos;
Use more ArrayRefs No functional change is intended, just a small refactoring. llvm-svn: 273647
2016-06-24 12:05:48 +08:00
if (SemaRef.SubstParmTypes(D->getLocation(), D->parameters(), nullptr,
TemplateArgs, ParamTypes, &Params,
ExtParamInfos))
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Be sure to instantiate the parameters of a function, even when the function's type is (strictly speaking) non-dependent. This ensures that, e.g., default function arguments get instantiated properly. And, since I couldn't resist, collapse the two implementations of function-parameter instantiation into calls to a single, new function (Sema::SubstParmVarDecl), since the two had nearly identical code (and each had bugs the other didn't!). More importantly, factored out the semantic analysis of a parameter declaration into Sema::CheckParameter, which is called both by Sema::ActOnParamDeclarator (when parameters are parsed) and when a parameter is instantiated. Previously, we were missing some Objective-C and address-space checks on instantiated function parameters. Fixes PR6733. llvm-svn: 101029
2010-04-12 15:48:19 +08:00
}
Fix declaring class template methods with an attributed typedef This change unifies the logic for template instantiation of methods and functions declared with typedefs. It ensures that SubstFunctionType() always fills the Params out param with non-null ParmVarDecls or returns null. Reviewers: rsmith Differential Revision: http://llvm-reviews.chandlerc.com/D1135 llvm-svn: 187528
2013-08-01 05:00:18 +08:00
Maintain type source information for functions through template instantiation. Based on a patch by Enea Zaffanella! I found a way to reduce some of the redundancy between TreeTransform's "standard" FunctionProtoType transformation and TemplateInstantiator's override, and I killed off the old SubstFunctionType by adding type source info for the last cases where we were creating FunctionDecls without TSI (at least that get passed through template instantiation). llvm-svn: 98252
2010-03-11 17:03:00 +08:00
return NewTInfo;
Cleanup template instantiation for methods, destructors llvm-svn: 67585
2009-03-24 08:38:23 +08:00
}
Implement DR1330 in C++11 mode, to support libstdc++4.7 which uses it. We have a new flavor of exception specification, EST_Uninstantiated. A function type with this exception specification carries a pointer to a FunctionDecl, and the exception specification for that FunctionDecl is instantiated (if needed) and used in the place of the function type's exception specification. When a function template declaration with a non-trivial exception specification is instantiated, the specialization's exception specification is set to this new 'uninstantiated' kind rather than being instantiated immediately. Expr::CanThrow has migrated onto Sema, so it can instantiate exception specs on-demand. Also, any odr-use of a function triggers the instantiation of its exception specification (the exception specification could be needed by IRGen). In passing, fix two places where a DeclRefExpr was created but the corresponding function was not actually marked odr-used. We used to get away with this, but don't any more. Also fix a bug where instantiating an exception specification which refers to function parameters resulted in a crash. We still have the same bug in default arguments, which I'll be looking into next. This, plus a tiny patch to fix libstdc++'s common_type, is enough for clang to parse (and, in very limited testing, support) all of libstdc++4.7's standard headers. llvm-svn: 154886
2012-04-17 08:58:00 +08:00
/// Introduce the instantiated function parameters into the local
/// instantiation scope, and set the parameter names to those used
/// in the template.
Instantiate exception specifications when instantiating function types (other than the type of a function declaration). We previously didn't instantiate these at all! This also covers the pathological case where the only mention of a parameter pack is within the exception specification; this gives us a second way (other than alias templates) to reach the horrible state where a type contains an unexpanded pack, but its canonical type does not. This is a re-commit of r219977: r219977 was reverted in r220038 because it hit a wrong-code bug in GCC 4.7.2. (That's gcc.gnu.org/PR56135, and affects any implicit lambda-capture of 'this' within a template.) r219977 was a re-commit of r217995, r218011, and r218053: r217995 was reverted in r218058 because it hit a rejects-valid bug in MSVC. (Incorrect overload resolution in the presence of using-declarations.) It was re-committed in r219977 with a workaround for the MSVC rejects-valid. r218011 was a workaround for an MSVC parser bug. (Incorrect desugaring of unbraced range-based for loop). llvm-svn: 221750
2014-11-12 10:00:47 +08:00
static bool addInstantiatedParametersToScope(Sema &S, FunctionDecl *Function,
Implement DR1330 in C++11 mode, to support libstdc++4.7 which uses it. We have a new flavor of exception specification, EST_Uninstantiated. A function type with this exception specification carries a pointer to a FunctionDecl, and the exception specification for that FunctionDecl is instantiated (if needed) and used in the place of the function type's exception specification. When a function template declaration with a non-trivial exception specification is instantiated, the specialization's exception specification is set to this new 'uninstantiated' kind rather than being instantiated immediately. Expr::CanThrow has migrated onto Sema, so it can instantiate exception specs on-demand. Also, any odr-use of a function triggers the instantiation of its exception specification (the exception specification could be needed by IRGen). In passing, fix two places where a DeclRefExpr was created but the corresponding function was not actually marked odr-used. We used to get away with this, but don't any more. Also fix a bug where instantiating an exception specification which refers to function parameters resulted in a crash. We still have the same bug in default arguments, which I'll be looking into next. This, plus a tiny patch to fix libstdc++'s common_type, is enough for clang to parse (and, in very limited testing, support) all of libstdc++4.7's standard headers. llvm-svn: 154886
2012-04-17 08:58:00 +08:00
const FunctionDecl *PatternDecl,
LocalInstantiationScope &Scope,
const MultiLevelTemplateArgumentList &TemplateArgs) {
unsigned FParamIdx = 0;
for (unsigned I = 0, N = PatternDecl->getNumParams(); I != N; ++I) {
const ParmVarDecl *PatternParam = PatternDecl->getParamDecl(I);
if (!PatternParam->isParameterPack()) {
// Simple case: not a parameter pack.
assert(FParamIdx < Function->getNumParams());
ParmVarDecl *FunctionParam = Function->getParamDecl(FParamIdx);
Instantiate exception specifications when instantiating function types (other than the type of a function declaration). We previously didn't instantiate these at all! This also covers the pathological case where the only mention of a parameter pack is within the exception specification; this gives us a second way (other than alias templates) to reach the horrible state where a type contains an unexpanded pack, but its canonical type does not. This is a re-commit of r219977: r219977 was reverted in r220038 because it hit a wrong-code bug in GCC 4.7.2. (That's gcc.gnu.org/PR56135, and affects any implicit lambda-capture of 'this' within a template.) r219977 was a re-commit of r217995, r218011, and r218053: r217995 was reverted in r218058 because it hit a rejects-valid bug in MSVC. (Incorrect overload resolution in the presence of using-declarations.) It was re-committed in r219977 with a workaround for the MSVC rejects-valid. r218011 was a workaround for an MSVC parser bug. (Incorrect desugaring of unbraced range-based for loop). llvm-svn: 221750
2014-11-12 10:00:47 +08:00
FunctionParam->setDeclName(PatternParam->getDeclName());
PR18275: If a member function of a class template is declared with a const-qualified parameter type and the defined with a non-const-qualified parameter type, the parameter is not const inside its body. Ensure that the type we use when instantiating the body is the right one. Patch by suyog sarda! This is still rather unsatisfactory; it seems like it might be better to instantiate at least the function parameters, and maybe the complete function declaration, when we instantiate the definition for such a member function (instead of reusing the declaration from inside the instantiated class definition). llvm-svn: 203741
2014-03-13 08:28:45 +08:00
// If the parameter's type is not dependent, update it to match the type
// in the pattern. They can differ in top-level cv-qualifiers, and we want
// the pattern's type here. If the type is dependent, they can't differ,
Instantiate exception specifications when instantiating function types (other than the type of a function declaration). We previously didn't instantiate these at all! This also covers the pathological case where the only mention of a parameter pack is within the exception specification; this gives us a second way (other than alias templates) to reach the horrible state where a type contains an unexpanded pack, but its canonical type does not. This is a re-commit of r219977: r219977 was reverted in r220038 because it hit a wrong-code bug in GCC 4.7.2. (That's gcc.gnu.org/PR56135, and affects any implicit lambda-capture of 'this' within a template.) r219977 was a re-commit of r217995, r218011, and r218053: r217995 was reverted in r218058 because it hit a rejects-valid bug in MSVC. (Incorrect overload resolution in the presence of using-declarations.) It was re-committed in r219977 with a workaround for the MSVC rejects-valid. r218011 was a workaround for an MSVC parser bug. (Incorrect desugaring of unbraced range-based for loop). llvm-svn: 221750
2014-11-12 10:00:47 +08:00
// per core issue 1668. Substitute into the type from the pattern, in case
// it's instantiation-dependent.
PR18275: If a member function of a class template is declared with a const-qualified parameter type and the defined with a non-const-qualified parameter type, the parameter is not const inside its body. Ensure that the type we use when instantiating the body is the right one. Patch by suyog sarda! This is still rather unsatisfactory; it seems like it might be better to instantiate at least the function parameters, and maybe the complete function declaration, when we instantiate the definition for such a member function (instead of reusing the declaration from inside the instantiated class definition). llvm-svn: 203741
2014-03-13 08:28:45 +08:00
// FIXME: Updating the type to work around this is at best fragile.
Instantiate exception specifications when instantiating function types (other than the type of a function declaration). We previously didn't instantiate these at all! This also covers the pathological case where the only mention of a parameter pack is within the exception specification; this gives us a second way (other than alias templates) to reach the horrible state where a type contains an unexpanded pack, but its canonical type does not. This is a re-commit of r219977: r219977 was reverted in r220038 because it hit a wrong-code bug in GCC 4.7.2. (That's gcc.gnu.org/PR56135, and affects any implicit lambda-capture of 'this' within a template.) r219977 was a re-commit of r217995, r218011, and r218053: r217995 was reverted in r218058 because it hit a rejects-valid bug in MSVC. (Incorrect overload resolution in the presence of using-declarations.) It was re-committed in r219977 with a workaround for the MSVC rejects-valid. r218011 was a workaround for an MSVC parser bug. (Incorrect desugaring of unbraced range-based for loop). llvm-svn: 221750
2014-11-12 10:00:47 +08:00
if (!PatternDecl->getType()->isDependentType()) {
QualType T = S.SubstType(PatternParam->getType(), TemplateArgs,
FunctionParam->getLocation(),
FunctionParam->getDeclName());
if (T.isNull())
return true;
FunctionParam->setType(T);
}
PR18275: If a member function of a class template is declared with a const-qualified parameter type and the defined with a non-const-qualified parameter type, the parameter is not const inside its body. Ensure that the type we use when instantiating the body is the right one. Patch by suyog sarda! This is still rather unsatisfactory; it seems like it might be better to instantiate at least the function parameters, and maybe the complete function declaration, when we instantiate the definition for such a member function (instead of reusing the declaration from inside the instantiated class definition). llvm-svn: 203741
2014-03-13 08:28:45 +08:00
Implement DR1330 in C++11 mode, to support libstdc++4.7 which uses it. We have a new flavor of exception specification, EST_Uninstantiated. A function type with this exception specification carries a pointer to a FunctionDecl, and the exception specification for that FunctionDecl is instantiated (if needed) and used in the place of the function type's exception specification. When a function template declaration with a non-trivial exception specification is instantiated, the specialization's exception specification is set to this new 'uninstantiated' kind rather than being instantiated immediately. Expr::CanThrow has migrated onto Sema, so it can instantiate exception specs on-demand. Also, any odr-use of a function triggers the instantiation of its exception specification (the exception specification could be needed by IRGen). In passing, fix two places where a DeclRefExpr was created but the corresponding function was not actually marked odr-used. We used to get away with this, but don't any more. Also fix a bug where instantiating an exception specification which refers to function parameters resulted in a crash. We still have the same bug in default arguments, which I'll be looking into next. This, plus a tiny patch to fix libstdc++'s common_type, is enough for clang to parse (and, in very limited testing, support) all of libstdc++4.7's standard headers. llvm-svn: 154886
2012-04-17 08:58:00 +08:00
Scope.InstantiatedLocal(PatternParam, FunctionParam);
++FParamIdx;
continue;
}
// Expand the parameter pack.
Scope.MakeInstantiatedLocalArgPack(PatternParam);
Include llvm::Optional in clang/Basic/LLVM.h Post-commit CR feedback from Jordan Rose regarding r175594. llvm-svn: 175679
2013-02-21 06:23:23 +08:00
Optional<unsigned> NumArgumentsInExpansion
Implement DR1330 in C++11 mode, to support libstdc++4.7 which uses it. We have a new flavor of exception specification, EST_Uninstantiated. A function type with this exception specification carries a pointer to a FunctionDecl, and the exception specification for that FunctionDecl is instantiated (if needed) and used in the place of the function type's exception specification. When a function template declaration with a non-trivial exception specification is instantiated, the specialization's exception specification is set to this new 'uninstantiated' kind rather than being instantiated immediately. Expr::CanThrow has migrated onto Sema, so it can instantiate exception specs on-demand. Also, any odr-use of a function triggers the instantiation of its exception specification (the exception specification could be needed by IRGen). In passing, fix two places where a DeclRefExpr was created but the corresponding function was not actually marked odr-used. We used to get away with this, but don't any more. Also fix a bug where instantiating an exception specification which refers to function parameters resulted in a crash. We still have the same bug in default arguments, which I'll be looking into next. This, plus a tiny patch to fix libstdc++'s common_type, is enough for clang to parse (and, in very limited testing, support) all of libstdc++4.7's standard headers. llvm-svn: 154886
2012-04-17 08:58:00 +08:00
= S.getNumArgumentsInExpansion(PatternParam->getType(), TemplateArgs);
PR13386: When matching up parameters between a function template declaration and a function template instantiation, if there's a parameter pack in the declaration and one at the same place in the instantiation, don't assume that the pack wasn't expanded -- it may have expanded to nothing. Instead, go ahead and check whether the parameter pack was expandable. We can do this as a side-effect of the work we'd need to do anyway, to find how many parameters were produced. llvm-svn: 160416
2012-07-18 09:29:05 +08:00
assert(NumArgumentsInExpansion &&
"should only be called when all template arguments are known");
Instantiate exception specifications when instantiating function types (other than the type of a function declaration). We previously didn't instantiate these at all! This also covers the pathological case where the only mention of a parameter pack is within the exception specification; this gives us a second way (other than alias templates) to reach the horrible state where a type contains an unexpanded pack, but its canonical type does not. This is a re-commit of r219977: r219977 was reverted in r220038 because it hit a wrong-code bug in GCC 4.7.2. (That's gcc.gnu.org/PR56135, and affects any implicit lambda-capture of 'this' within a template.) r219977 was a re-commit of r217995, r218011, and r218053: r217995 was reverted in r218058 because it hit a rejects-valid bug in MSVC. (Incorrect overload resolution in the presence of using-declarations.) It was re-committed in r219977 with a workaround for the MSVC rejects-valid. r218011 was a workaround for an MSVC parser bug. (Incorrect desugaring of unbraced range-based for loop). llvm-svn: 221750
2014-11-12 10:00:47 +08:00
QualType PatternType =
PatternParam->getType()->castAs<PackExpansionType>()->getPattern();
PR13386: When matching up parameters between a function template declaration and a function template instantiation, if there's a parameter pack in the declaration and one at the same place in the instantiation, don't assume that the pack wasn't expanded -- it may have expanded to nothing. Instead, go ahead and check whether the parameter pack was expandable. We can do this as a side-effect of the work we'd need to do anyway, to find how many parameters were produced. llvm-svn: 160416
2012-07-18 09:29:05 +08:00
for (unsigned Arg = 0; Arg < *NumArgumentsInExpansion; ++Arg) {
Implement DR1330 in C++11 mode, to support libstdc++4.7 which uses it. We have a new flavor of exception specification, EST_Uninstantiated. A function type with this exception specification carries a pointer to a FunctionDecl, and the exception specification for that FunctionDecl is instantiated (if needed) and used in the place of the function type's exception specification. When a function template declaration with a non-trivial exception specification is instantiated, the specialization's exception specification is set to this new 'uninstantiated' kind rather than being instantiated immediately. Expr::CanThrow has migrated onto Sema, so it can instantiate exception specs on-demand. Also, any odr-use of a function triggers the instantiation of its exception specification (the exception specification could be needed by IRGen). In passing, fix two places where a DeclRefExpr was created but the corresponding function was not actually marked odr-used. We used to get away with this, but don't any more. Also fix a bug where instantiating an exception specification which refers to function parameters resulted in a crash. We still have the same bug in default arguments, which I'll be looking into next. This, plus a tiny patch to fix libstdc++'s common_type, is enough for clang to parse (and, in very limited testing, support) all of libstdc++4.7's standard headers. llvm-svn: 154886
2012-04-17 08:58:00 +08:00
ParmVarDecl *FunctionParam = Function->getParamDecl(FParamIdx);
FunctionParam->setDeclName(PatternParam->getDeclName());
Instantiate exception specifications when instantiating function types (other than the type of a function declaration). We previously didn't instantiate these at all! This also covers the pathological case where the only mention of a parameter pack is within the exception specification; this gives us a second way (other than alias templates) to reach the horrible state where a type contains an unexpanded pack, but its canonical type does not. This is a re-commit of r219977: r219977 was reverted in r220038 because it hit a wrong-code bug in GCC 4.7.2. (That's gcc.gnu.org/PR56135, and affects any implicit lambda-capture of 'this' within a template.) r219977 was a re-commit of r217995, r218011, and r218053: r217995 was reverted in r218058 because it hit a rejects-valid bug in MSVC. (Incorrect overload resolution in the presence of using-declarations.) It was re-committed in r219977 with a workaround for the MSVC rejects-valid. r218011 was a workaround for an MSVC parser bug. (Incorrect desugaring of unbraced range-based for loop). llvm-svn: 221750
2014-11-12 10:00:47 +08:00
if (!PatternDecl->getType()->isDependentType()) {
Sema::ArgumentPackSubstitutionIndexRAII SubstIndex(S, Arg);
QualType T = S.SubstType(PatternType, TemplateArgs,
FunctionParam->getLocation(),
FunctionParam->getDeclName());
Implement DR1330 in C++11 mode, to support libstdc++4.7 which uses it. We have a new flavor of exception specification, EST_Uninstantiated. A function type with this exception specification carries a pointer to a FunctionDecl, and the exception specification for that FunctionDecl is instantiated (if needed) and used in the place of the function type's exception specification. When a function template declaration with a non-trivial exception specification is instantiated, the specialization's exception specification is set to this new 'uninstantiated' kind rather than being instantiated immediately. Expr::CanThrow has migrated onto Sema, so it can instantiate exception specs on-demand. Also, any odr-use of a function triggers the instantiation of its exception specification (the exception specification could be needed by IRGen). In passing, fix two places where a DeclRefExpr was created but the corresponding function was not actually marked odr-used. We used to get away with this, but don't any more. Also fix a bug where instantiating an exception specification which refers to function parameters resulted in a crash. We still have the same bug in default arguments, which I'll be looking into next. This, plus a tiny patch to fix libstdc++'s common_type, is enough for clang to parse (and, in very limited testing, support) all of libstdc++4.7's standard headers. llvm-svn: 154886
2012-04-17 08:58:00 +08:00
if (T.isNull())
Instantiate exception specifications when instantiating function types (other than the type of a function declaration). We previously didn't instantiate these at all! This also covers the pathological case where the only mention of a parameter pack is within the exception specification; this gives us a second way (other than alias templates) to reach the horrible state where a type contains an unexpanded pack, but its canonical type does not. This is a re-commit of r219977: r219977 was reverted in r220038 because it hit a wrong-code bug in GCC 4.7.2. (That's gcc.gnu.org/PR56135, and affects any implicit lambda-capture of 'this' within a template.) r219977 was a re-commit of r217995, r218011, and r218053: r217995 was reverted in r218058 because it hit a rejects-valid bug in MSVC. (Incorrect overload resolution in the presence of using-declarations.) It was re-committed in r219977 with a workaround for the MSVC rejects-valid. r218011 was a workaround for an MSVC parser bug. (Incorrect desugaring of unbraced range-based for loop). llvm-svn: 221750
2014-11-12 10:00:47 +08:00
return true;
FunctionParam->setType(T);
Revert r219977, "Re-commit r217995 and follow-up patches (r217997, r218011, r218053). These were" It broke some builders. I guess it'd be reproducible with --vg. Failing Tests (3): Clang :: CXX/except/except.spec/p1.cpp Clang :: SemaTemplate/instantiate-exception-spec-cxx11.cpp Clang :: SemaTemplate/instantiate-exception-spec.cpp llvm-svn: 220038
2014-10-17 20:48:37 +08:00
}
Instantiate exception specifications when instantiating function types (other than the type of a function declaration). We previously didn't instantiate these at all! This also covers the pathological case where the only mention of a parameter pack is within the exception specification; this gives us a second way (other than alias templates) to reach the horrible state where a type contains an unexpanded pack, but its canonical type does not. This is a re-commit of r219977: r219977 was reverted in r220038 because it hit a wrong-code bug in GCC 4.7.2. (That's gcc.gnu.org/PR56135, and affects any implicit lambda-capture of 'this' within a template.) r219977 was a re-commit of r217995, r218011, and r218053: r217995 was reverted in r218058 because it hit a rejects-valid bug in MSVC. (Incorrect overload resolution in the presence of using-declarations.) It was re-committed in r219977 with a workaround for the MSVC rejects-valid. r218011 was a workaround for an MSVC parser bug. (Incorrect desugaring of unbraced range-based for loop). llvm-svn: 221750
2014-11-12 10:00:47 +08:00
Scope.InstantiatedLocalPackArg(PatternParam, FunctionParam);
++FParamIdx;
Implement DR1330 in C++11 mode, to support libstdc++4.7 which uses it. We have a new flavor of exception specification, EST_Uninstantiated. A function type with this exception specification carries a pointer to a FunctionDecl, and the exception specification for that FunctionDecl is instantiated (if needed) and used in the place of the function type's exception specification. When a function template declaration with a non-trivial exception specification is instantiated, the specialization's exception specification is set to this new 'uninstantiated' kind rather than being instantiated immediately. Expr::CanThrow has migrated onto Sema, so it can instantiate exception specs on-demand. Also, any odr-use of a function triggers the instantiation of its exception specification (the exception specification could be needed by IRGen). In passing, fix two places where a DeclRefExpr was created but the corresponding function was not actually marked odr-used. We used to get away with this, but don't any more. Also fix a bug where instantiating an exception specification which refers to function parameters resulted in a crash. We still have the same bug in default arguments, which I'll be looking into next. This, plus a tiny patch to fix libstdc++'s common_type, is enough for clang to parse (and, in very limited testing, support) all of libstdc++4.7's standard headers. llvm-svn: 154886
2012-04-17 08:58:00 +08:00
}
}
Instantiate exception specifications when instantiating function types (other than the type of a function declaration). We previously didn't instantiate these at all! This also covers the pathological case where the only mention of a parameter pack is within the exception specification; this gives us a second way (other than alias templates) to reach the horrible state where a type contains an unexpanded pack, but its canonical type does not. This is a re-commit of r219977: r219977 was reverted in r220038 because it hit a wrong-code bug in GCC 4.7.2. (That's gcc.gnu.org/PR56135, and affects any implicit lambda-capture of 'this' within a template.) r219977 was a re-commit of r217995, r218011, and r218053: r217995 was reverted in r218058 because it hit a rejects-valid bug in MSVC. (Incorrect overload resolution in the presence of using-declarations.) It was re-committed in r219977 with a workaround for the MSVC rejects-valid. r218011 was a workaround for an MSVC parser bug. (Incorrect desugaring of unbraced range-based for loop). llvm-svn: 221750
2014-11-12 10:00:47 +08:00
return false;
Implement DR1330 in C++11 mode, to support libstdc++4.7 which uses it. We have a new flavor of exception specification, EST_Uninstantiated. A function type with this exception specification carries a pointer to a FunctionDecl, and the exception specification for that FunctionDecl is instantiated (if needed) and used in the place of the function type's exception specification. When a function template declaration with a non-trivial exception specification is instantiated, the specialization's exception specification is set to this new 'uninstantiated' kind rather than being instantiated immediately. Expr::CanThrow has migrated onto Sema, so it can instantiate exception specs on-demand. Also, any odr-use of a function triggers the instantiation of its exception specification (the exception specification could be needed by IRGen). In passing, fix two places where a DeclRefExpr was created but the corresponding function was not actually marked odr-used. We used to get away with this, but don't any more. Also fix a bug where instantiating an exception specification which refers to function parameters resulted in a crash. We still have the same bug in default arguments, which I'll be looking into next. This, plus a tiny patch to fix libstdc++'s common_type, is enough for clang to parse (and, in very limited testing, support) all of libstdc++4.7's standard headers. llvm-svn: 154886
2012-04-17 08:58:00 +08:00
}
void Sema::InstantiateExceptionSpec(SourceLocation PointOfInstantiation,
FunctionDecl *Decl) {
PR 12586: Fix assert while running libc++ testsuite: deal with exception specifications on member function templates of class templates and other such nested beasties. Store the function template from which we are to instantiate an exception specification rather than trying to deduce it. Plus some additional test cases. llvm-svn: 155076
2012-04-19 08:08:28 +08:00
const FunctionProtoType *Proto = Decl->getType()->castAs<FunctionProtoType>();
if (Proto->getExceptionSpecType() != EST_Uninstantiated)
Implement DR1330 in C++11 mode, to support libstdc++4.7 which uses it. We have a new flavor of exception specification, EST_Uninstantiated. A function type with this exception specification carries a pointer to a FunctionDecl, and the exception specification for that FunctionDecl is instantiated (if needed) and used in the place of the function type's exception specification. When a function template declaration with a non-trivial exception specification is instantiated, the specialization's exception specification is set to this new 'uninstantiated' kind rather than being instantiated immediately. Expr::CanThrow has migrated onto Sema, so it can instantiate exception specs on-demand. Also, any odr-use of a function triggers the instantiation of its exception specification (the exception specification could be needed by IRGen). In passing, fix two places where a DeclRefExpr was created but the corresponding function was not actually marked odr-used. We used to get away with this, but don't any more. Also fix a bug where instantiating an exception specification which refers to function parameters resulted in a crash. We still have the same bug in default arguments, which I'll be looking into next. This, plus a tiny patch to fix libstdc++'s common_type, is enough for clang to parse (and, in very limited testing, support) all of libstdc++4.7's standard headers. llvm-svn: 154886
2012-04-17 08:58:00 +08:00
return;
InstantiatingTemplate Inst(*this, PointOfInstantiation, Decl,
InstantiatingTemplate::ExceptionSpecification());
Make InstantiatingTemplate depth checks clearer The bool conversion operator on InstantiatingTemplate never added value and only served to obfuscate the template instantiation routines. This replaces the conversion and its callers with an explicit isInvalid() function to make it clear what's going on at a glance. llvm-svn: 192177
2013-10-08 16:09:04 +08:00
if (Inst.isInvalid()) {
Final piece of core issue 1330: delay computing the exception specification of a defaulted special member function until the exception specification is needed (using the same criteria used for the delayed instantiation of exception specifications for function temploids). EST_Delayed is now EST_Unevaluated (using 1330's terminology), and, like EST_Uninstantiated, carries a pointer to the FunctionDecl which will be used to resolve the exception specification. This is enabled for all C++ modes: it's a little faster in the case where the exception specification isn't used, allows our C++11-in-C++98 extensions to work, and is still correct for C++98, since in that mode the computation of the exception specification can't fail. The diagnostics here aren't great (in particular, we should include implicit evaluation of exception specifications for defaulted special members in the template instantiation backtraces), but they're not much worse than before. Our approach to the problem of cycles between in-class initializers and the exception specification for a defaulted default constructor is modified a little by this change -- we now reject any odr-use of a defaulted default constructor if that constructor uses an in-class initializer and the use is in an in-class initialzer which is declared lexically earlier. This is a closer approximation to the current draft solution in core issue 1351, but isn't an exact match (but the current draft wording isn't reasonable, so that's to be expected). llvm-svn: 160847
2012-07-27 12:22:15 +08:00
// We hit the instantiation depth limit. Clear the exception specification
// so that our callers don't have to cope with EST_Uninstantiated.
Factor out exception specification information from FunctionProtoType::ExtProtoInfo. Most of the users of these fields don't care about the other ExtProtoInfo bits and just want to talk about the exception specification. llvm-svn: 214450
2014-08-01 05:57:55 +08:00
UpdateExceptionSpec(Decl, EST_None);
Implement DR1330 in C++11 mode, to support libstdc++4.7 which uses it. We have a new flavor of exception specification, EST_Uninstantiated. A function type with this exception specification carries a pointer to a FunctionDecl, and the exception specification for that FunctionDecl is instantiated (if needed) and used in the place of the function type's exception specification. When a function template declaration with a non-trivial exception specification is instantiated, the specialization's exception specification is set to this new 'uninstantiated' kind rather than being instantiated immediately. Expr::CanThrow has migrated onto Sema, so it can instantiate exception specs on-demand. Also, any odr-use of a function triggers the instantiation of its exception specification (the exception specification could be needed by IRGen). In passing, fix two places where a DeclRefExpr was created but the corresponding function was not actually marked odr-used. We used to get away with this, but don't any more. Also fix a bug where instantiating an exception specification which refers to function parameters resulted in a crash. We still have the same bug in default arguments, which I'll be looking into next. This, plus a tiny patch to fix libstdc++'s common_type, is enough for clang to parse (and, in very limited testing, support) all of libstdc++4.7's standard headers. llvm-svn: 154886
2012-04-17 08:58:00 +08:00
return;
Final piece of core issue 1330: delay computing the exception specification of a defaulted special member function until the exception specification is needed (using the same criteria used for the delayed instantiation of exception specifications for function temploids). EST_Delayed is now EST_Unevaluated (using 1330's terminology), and, like EST_Uninstantiated, carries a pointer to the FunctionDecl which will be used to resolve the exception specification. This is enabled for all C++ modes: it's a little faster in the case where the exception specification isn't used, allows our C++11-in-C++98 extensions to work, and is still correct for C++98, since in that mode the computation of the exception specification can't fail. The diagnostics here aren't great (in particular, we should include implicit evaluation of exception specifications for defaulted special members in the template instantiation backtraces), but they're not much worse than before. Our approach to the problem of cycles between in-class initializers and the exception specification for a defaulted default constructor is modified a little by this change -- we now reject any odr-use of a defaulted default constructor if that constructor uses an in-class initializer and the use is in an in-class initialzer which is declared lexically earlier. This is a closer approximation to the current draft solution in core issue 1351, but isn't an exact match (but the current draft wording isn't reasonable, so that's to be expected). llvm-svn: 160847
2012-07-27 12:22:15 +08:00
}
PR12298 et al: don't recursively instantiate a template specialization from within the instantiation of that same specialization. This could previously happen for eagerly-instantiated function templates, variable templates, exception specifications, default arguments, and a handful of other cases. We still have an issue here for default template arguments that recursively make use of themselves and likewise for substitution into the type of a non-type template parameter, but in those cases we're producing a different entity each time, so they should instead be caught by the instantiation depth limit. However, currently we will typically run out of stack before we reach it. :( llvm-svn: 280190
2016-08-31 10:15:21 +08:00
if (Inst.isAlreadyInstantiating()) {
// This exception specification indirectly depends on itself. Reject.
// FIXME: Corresponding rule in the standard?
Diag(PointOfInstantiation, diag::err_exception_spec_cycle) << Decl;
UpdateExceptionSpec(Decl, EST_None);
return;
}
Implement DR1330 in C++11 mode, to support libstdc++4.7 which uses it. We have a new flavor of exception specification, EST_Uninstantiated. A function type with this exception specification carries a pointer to a FunctionDecl, and the exception specification for that FunctionDecl is instantiated (if needed) and used in the place of the function type's exception specification. When a function template declaration with a non-trivial exception specification is instantiated, the specialization's exception specification is set to this new 'uninstantiated' kind rather than being instantiated immediately. Expr::CanThrow has migrated onto Sema, so it can instantiate exception specs on-demand. Also, any odr-use of a function triggers the instantiation of its exception specification (the exception specification could be needed by IRGen). In passing, fix two places where a DeclRefExpr was created but the corresponding function was not actually marked odr-used. We used to get away with this, but don't any more. Also fix a bug where instantiating an exception specification which refers to function parameters resulted in a crash. We still have the same bug in default arguments, which I'll be looking into next. This, plus a tiny patch to fix libstdc++'s common_type, is enough for clang to parse (and, in very limited testing, support) all of libstdc++4.7's standard headers. llvm-svn: 154886
2012-04-17 08:58:00 +08:00
// Enter the scope of this instantiation. We don't use
// PushDeclContext because we don't have a scope.
Sema::ContextRAII savedContext(*this, Decl);
LocalInstantiationScope Scope(*this);
MultiLevelTemplateArgumentList TemplateArgs =
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
getTemplateInstantiationArgs(Decl, nullptr, /*RelativeToPrimary*/true);
Implement DR1330 in C++11 mode, to support libstdc++4.7 which uses it. We have a new flavor of exception specification, EST_Uninstantiated. A function type with this exception specification carries a pointer to a FunctionDecl, and the exception specification for that FunctionDecl is instantiated (if needed) and used in the place of the function type's exception specification. When a function template declaration with a non-trivial exception specification is instantiated, the specialization's exception specification is set to this new 'uninstantiated' kind rather than being instantiated immediately. Expr::CanThrow has migrated onto Sema, so it can instantiate exception specs on-demand. Also, any odr-use of a function triggers the instantiation of its exception specification (the exception specification could be needed by IRGen). In passing, fix two places where a DeclRefExpr was created but the corresponding function was not actually marked odr-used. We used to get away with this, but don't any more. Also fix a bug where instantiating an exception specification which refers to function parameters resulted in a crash. We still have the same bug in default arguments, which I'll be looking into next. This, plus a tiny patch to fix libstdc++'s common_type, is enough for clang to parse (and, in very limited testing, support) all of libstdc++4.7's standard headers. llvm-svn: 154886
2012-04-17 08:58:00 +08:00
PR 12586: Fix assert while running libc++ testsuite: deal with exception specifications on member function templates of class templates and other such nested beasties. Store the function template from which we are to instantiate an exception specification rather than trying to deduce it. Plus some additional test cases. llvm-svn: 155076
2012-04-19 08:08:28 +08:00
FunctionDecl *Template = Proto->getExceptionSpecTemplate();
Instantiate exception specifications when instantiating function types (other than the type of a function declaration). We previously didn't instantiate these at all! This also covers the pathological case where the only mention of a parameter pack is within the exception specification; this gives us a second way (other than alias templates) to reach the horrible state where a type contains an unexpanded pack, but its canonical type does not. This is a re-commit of r219977: r219977 was reverted in r220038 because it hit a wrong-code bug in GCC 4.7.2. (That's gcc.gnu.org/PR56135, and affects any implicit lambda-capture of 'this' within a template.) r219977 was a re-commit of r217995, r218011, and r218053: r217995 was reverted in r218058 because it hit a rejects-valid bug in MSVC. (Incorrect overload resolution in the presence of using-declarations.) It was re-committed in r219977 with a workaround for the MSVC rejects-valid. r218011 was a workaround for an MSVC parser bug. (Incorrect desugaring of unbraced range-based for loop). llvm-svn: 221750
2014-11-12 10:00:47 +08:00
if (addInstantiatedParametersToScope(*this, Decl, Template, Scope,
TemplateArgs)) {
UpdateExceptionSpec(Decl, EST_None);
return;
}
Implement DR1330 in C++11 mode, to support libstdc++4.7 which uses it. We have a new flavor of exception specification, EST_Uninstantiated. A function type with this exception specification carries a pointer to a FunctionDecl, and the exception specification for that FunctionDecl is instantiated (if needed) and used in the place of the function type's exception specification. When a function template declaration with a non-trivial exception specification is instantiated, the specialization's exception specification is set to this new 'uninstantiated' kind rather than being instantiated immediately. Expr::CanThrow has migrated onto Sema, so it can instantiate exception specs on-demand. Also, any odr-use of a function triggers the instantiation of its exception specification (the exception specification could be needed by IRGen). In passing, fix two places where a DeclRefExpr was created but the corresponding function was not actually marked odr-used. We used to get away with this, but don't any more. Also fix a bug where instantiating an exception specification which refers to function parameters resulted in a crash. We still have the same bug in default arguments, which I'll be looking into next. This, plus a tiny patch to fix libstdc++'s common_type, is enough for clang to parse (and, in very limited testing, support) all of libstdc++4.7's standard headers. llvm-svn: 154886
2012-04-17 08:58:00 +08:00
Instantiate exception specifications when instantiating function types (other than the type of a function declaration). We previously didn't instantiate these at all! This also covers the pathological case where the only mention of a parameter pack is within the exception specification; this gives us a second way (other than alias templates) to reach the horrible state where a type contains an unexpanded pack, but its canonical type does not. This is a re-commit of r219977: r219977 was reverted in r220038 because it hit a wrong-code bug in GCC 4.7.2. (That's gcc.gnu.org/PR56135, and affects any implicit lambda-capture of 'this' within a template.) r219977 was a re-commit of r217995, r218011, and r218053: r217995 was reverted in r218058 because it hit a rejects-valid bug in MSVC. (Incorrect overload resolution in the presence of using-declarations.) It was re-committed in r219977 with a workaround for the MSVC rejects-valid. r218011 was a workaround for an MSVC parser bug. (Incorrect desugaring of unbraced range-based for loop). llvm-svn: 221750
2014-11-12 10:00:47 +08:00
SubstExceptionSpec(Decl, Template->getType()->castAs<FunctionProtoType>(),
TemplateArgs);
Implement DR1330 in C++11 mode, to support libstdc++4.7 which uses it. We have a new flavor of exception specification, EST_Uninstantiated. A function type with this exception specification carries a pointer to a FunctionDecl, and the exception specification for that FunctionDecl is instantiated (if needed) and used in the place of the function type's exception specification. When a function template declaration with a non-trivial exception specification is instantiated, the specialization's exception specification is set to this new 'uninstantiated' kind rather than being instantiated immediately. Expr::CanThrow has migrated onto Sema, so it can instantiate exception specs on-demand. Also, any odr-use of a function triggers the instantiation of its exception specification (the exception specification could be needed by IRGen). In passing, fix two places where a DeclRefExpr was created but the corresponding function was not actually marked odr-used. We used to get away with this, but don't any more. Also fix a bug where instantiating an exception specification which refers to function parameters resulted in a crash. We still have the same bug in default arguments, which I'll be looking into next. This, plus a tiny patch to fix libstdc++'s common_type, is enough for clang to parse (and, in very limited testing, support) all of libstdc++4.7's standard headers. llvm-svn: 154886
2012-04-17 08:58:00 +08:00
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
/// \brief Initializes the common fields of an instantiation function
Improved semantic analysis and AST respresentation for function templates. For example, this now type-checks (but does not instantiate the body of deref<int>): template<typename T> T& deref(T* t) { return *t; } void test(int *ip) { int &ir = deref(ip); } Specific changes/additions: * Template argument deduction from a call to a function template. * Instantiation of a function template specializations (just the declarations) from the template arguments deduced from a call. * FunctionTemplateDecls are stored directly in declaration contexts and found via name lookup (all forms), rather than finding the FunctionDecl and then realizing it is a template. This is responsible for most of the churn, since some of the core declaration matching and lookup code assumes that all functions are FunctionDecls. llvm-svn: 74213
2009-06-26 06:08:12 +08:00
/// declaration (New) from the corresponding fields of its template (Tmpl).
///
/// \returns true if there was an error
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
bool
TemplateDeclInstantiator::InitFunctionInstantiation(FunctionDecl *New,
Improved semantic analysis and AST respresentation for function templates. For example, this now type-checks (but does not instantiate the body of deref<int>): template<typename T> T& deref(T* t) { return *t; } void test(int *ip) { int &ir = deref(ip); } Specific changes/additions: * Template argument deduction from a call to a function template. * Instantiation of a function template specializations (just the declarations) from the template arguments deduced from a call. * FunctionTemplateDecls are stored directly in declaration contexts and found via name lookup (all forms), rather than finding the FunctionDecl and then realizing it is a template. This is responsible for most of the churn, since some of the core declaration matching and lookup code assumes that all functions are FunctionDecls. llvm-svn: 74213
2009-06-26 06:08:12 +08:00
FunctionDecl *Tmpl) {
Fix rejects-valid: explicit specialization of redeclared deleted function template. Review by Richard Smith. llvm-svn: 160306
2012-07-17 02:50:45 +08:00
if (Tmpl->isDeleted())
Modify some deleted function methods to better reflect reality: - New isDefined() function checks for deletedness - isThisDeclarationADefinition checks for deletedness - New doesThisDeclarationHaveABody() does what isThisDeclarationADefinition() used to do - The IsDeleted bit is not propagated across redeclarations - isDeleted() now checks the canoncial declaration - New isDeletedAsWritten() does what it says on the tin. - isUserProvided() now correct (thanks Richard!) This fixes the bug that we weren't catching void foo() = delete; void foo() {} as being a redefinition. llvm-svn: 131013
2011-05-07 04:44:56 +08:00
New->setDeletedAsWritten();
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
[c++1z] Synthesize implicit deduction guides from constructors on demand. Rank such guides below explicit ones, and ensure that references to the class's template parameters are not treated as forwarding references. We make a few tweaks to the wording in the current standard: 1) The constructor parameter list is copied faithfully to the deduction guide, without losing default arguments or a varargs ellipsis (which the standard wording loses by omission). 2) If the class template declares no constructors, we add a T() -> T<...> guide (which will only ever work if T has default arguments for all non-pack template parameters). 3) If the class template declares nothing that looks like a copy or move constructor, we add a T(T<...>) -> T<...> guide. #2 and #3 follow from the "pretend we had a class type with these constructors" philosophy for deduction guides. llvm-svn: 295007
2017-02-14 08:25:28 +08:00
New->setImplicit(Tmpl->isImplicit());
Sema: Propagate the mangling number into instantiations We would lose track of the mangling number assigned to the original declaration which would cause us to create manglings that didn't match the Itanium C++ specification. e.g. Two static fields with the same name inside of a function template would receive the same mangling with LLVM fixing up the second field so they wouldn't collide. This would create an incompatibility with other compilers following the Itanium ABI. I've confirmed that the new mangling is identical to the ones generated by icc and gcc. N.B. This was uncovered while working on Microsoft mangler. llvm-svn: 196368
2013-12-04 17:01:55 +08:00
// Forward the mangling number from the template to the instantiated decl.
SemaRef.Context.setManglingNumber(New,
SemaRef.Context.getManglingNumber(Tmpl));
Keep track of more information within the template instantiation stack, e.g., by distinguishing between substitution that occurs for template argument deduction vs. explicitly-specifiad template arguments. This is used both to improve diagnostics and to make sure we only provide SFINAE in those cases where SFINAE should apply. In addition, deal with the sticky issue where SFINAE only considers substitution of template arguments into the *type* of a function template; we need to issue hard errors beyond this point, as test/SemaTemplate/operator-template.cpp illustrates. llvm-svn: 74651
2009-07-02 06:01:06 +08:00
// If we are performing substituting explicitly-specified template arguments
// or deduced template arguments into a function template and we reach this
// point, we are now past the point where SFINAE applies and have committed
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
// to keeping the new function template specialization. We therefore
// convert the active template instantiation for the function template
Keep track of more information within the template instantiation stack, e.g., by distinguishing between substitution that occurs for template argument deduction vs. explicitly-specifiad template arguments. This is used both to improve diagnostics and to make sure we only provide SFINAE in those cases where SFINAE should apply. In addition, deal with the sticky issue where SFINAE only considers substitution of template arguments into the *type* of a function template; we need to issue hard errors beyond this point, as test/SemaTemplate/operator-template.cpp illustrates. llvm-svn: 74651
2009-07-02 06:01:06 +08:00
// into a template instantiation for this specific function template
// specialization, which is not a SFINAE context, so that we diagnose any
// further errors in the declaration itself.
Rename ActiveTemplateInstantiation to CodeSynthesisContext in preparation for using it for other kinds of context (where we currently produce context notes in a highly ad-hoc manner). llvm-svn: 295919
2017-02-23 09:43:54 +08:00
typedef Sema::CodeSynthesisContext ActiveInstType;
ActiveInstType &ActiveInst = SemaRef.CodeSynthesisContexts.back();
Keep track of more information within the template instantiation stack, e.g., by distinguishing between substitution that occurs for template argument deduction vs. explicitly-specifiad template arguments. This is used both to improve diagnostics and to make sure we only provide SFINAE in those cases where SFINAE should apply. In addition, deal with the sticky issue where SFINAE only considers substitution of template arguments into the *type* of a function template; we need to issue hard errors beyond this point, as test/SemaTemplate/operator-template.cpp illustrates. llvm-svn: 74651
2009-07-02 06:01:06 +08:00
if (ActiveInst.Kind == ActiveInstType::ExplicitTemplateArgumentSubstitution ||
ActiveInst.Kind == ActiveInstType::DeducedTemplateArgumentSubstitution) {
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
if (FunctionTemplateDecl *FunTmpl
Store this Decl* as a Decl* instead of a uintptr_t. No functionality change. llvm-svn: 168145
2012-11-16 16:40:59 +08:00
= dyn_cast<FunctionTemplateDecl>(ActiveInst.Entity)) {
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
assert(FunTmpl->getTemplatedDecl() == Tmpl &&
Keep track of more information within the template instantiation stack, e.g., by distinguishing between substitution that occurs for template argument deduction vs. explicitly-specifiad template arguments. This is used both to improve diagnostics and to make sure we only provide SFINAE in those cases where SFINAE should apply. In addition, deal with the sticky issue where SFINAE only considers substitution of template arguments into the *type* of a function template; we need to issue hard errors beyond this point, as test/SemaTemplate/operator-template.cpp illustrates. llvm-svn: 74651
2009-07-02 06:01:06 +08:00
"Deduction from the wrong function template?");
Fix unused variable warnings (with -Asserts) llvm-svn: 76112
2009-07-17 06:10:11 +08:00
(void) FunTmpl;
Keep track of more information within the template instantiation stack, e.g., by distinguishing between substitution that occurs for template argument deduction vs. explicitly-specifiad template arguments. This is used both to improve diagnostics and to make sure we only provide SFINAE in those cases where SFINAE should apply. In addition, deal with the sticky issue where SFINAE only considers substitution of template arguments into the *type* of a function template; we need to issue hard errors beyond this point, as test/SemaTemplate/operator-template.cpp illustrates. llvm-svn: 74651
2009-07-02 06:01:06 +08:00
ActiveInst.Kind = ActiveInstType::TemplateInstantiation;
Store this Decl* as a Decl* instead of a uintptr_t. No functionality change. llvm-svn: 168145
2012-11-16 16:40:59 +08:00
ActiveInst.Entity = New;
Keep track of more information within the template instantiation stack, e.g., by distinguishing between substitution that occurs for template argument deduction vs. explicitly-specifiad template arguments. This is used both to improve diagnostics and to make sure we only provide SFINAE in those cases where SFINAE should apply. In addition, deal with the sticky issue where SFINAE only considers substitution of template arguments into the *type* of a function template; we need to issue hard errors beyond this point, as test/SemaTemplate/operator-template.cpp illustrates. llvm-svn: 74651
2009-07-02 06:01:06 +08:00
}
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Implement template instantiation for exception specifications. Also, print exception specifications on function types and declarations. Fixes <rdar://problem/7450999>. There is some poor source-location information here, because we don't track locations of the types in exception specifications. Filed PR5719. Failures during template instantiation of the signature of a function or function template have wrong point-of-instantiation location information. I'll tackle that with a separate commit. llvm-svn: 90863
2009-12-09 01:45:32 +08:00
const FunctionProtoType *Proto = Tmpl->getType()->getAs<FunctionProtoType>();
assert(Proto && "Function template without prototype?");
Propagate the new exception information to FunctionProtoType. Change the interface to expose the new information and deal with the enormous fallout. Introduce the new ExceptionSpecificationType value EST_DynamicNone to more easily deal with empty throw specifications. Update the tests for noexcept and fix the various bugs uncovered, such as lack of tentative parsing support. llvm-svn: 127537
2011-03-12 19:50:43 +08:00
if (Proto->hasExceptionSpec() || Proto->getNoReturnAttr()) {
Restore r121752 without modification. llvm-svn: 121763
2010-12-14 16:05:40 +08:00
FunctionProtoType::ExtProtoInfo EPI = Proto->getExtProtoInfo();
Implement DR1330 in C++11 mode, to support libstdc++4.7 which uses it. We have a new flavor of exception specification, EST_Uninstantiated. A function type with this exception specification carries a pointer to a FunctionDecl, and the exception specification for that FunctionDecl is instantiated (if needed) and used in the place of the function type's exception specification. When a function template declaration with a non-trivial exception specification is instantiated, the specialization's exception specification is set to this new 'uninstantiated' kind rather than being instantiated immediately. Expr::CanThrow has migrated onto Sema, so it can instantiate exception specs on-demand. Also, any odr-use of a function triggers the instantiation of its exception specification (the exception specification could be needed by IRGen). In passing, fix two places where a DeclRefExpr was created but the corresponding function was not actually marked odr-used. We used to get away with this, but don't any more. Also fix a bug where instantiating an exception specification which refers to function parameters resulted in a crash. We still have the same bug in default arguments, which I'll be looking into next. This, plus a tiny patch to fix libstdc++'s common_type, is enough for clang to parse (and, in very limited testing, support) all of libstdc++4.7's standard headers. llvm-svn: 154886
2012-04-17 08:58:00 +08:00
// DR1330: In C++11, defer instantiation of a non-trivial
// exception specification.
Instantiation of local class members. If a function containing a local class is instantiated, instantiate all of local class member, including default arguments and exception specifications. This change fixes PR21332 and thus implements DR1484. Differential Revision: http://reviews.llvm.org/D9990 llvm-svn: 240974
2015-06-30 01:50:19 +08:00
// DR1484: Local classes and their members are instantiated along with the
// containing function.
s/CPlusPlus0x/CPlusPlus11/g llvm-svn: 171367
2013-01-02 19:42:31 +08:00
if (SemaRef.getLangOpts().CPlusPlus11 &&
Factor out exception specification information from FunctionProtoType::ExtProtoInfo. Most of the users of these fields don't care about the other ExtProtoInfo bits and just want to talk about the exception specification. llvm-svn: 214450
2014-08-01 05:57:55 +08:00
EPI.ExceptionSpec.Type != EST_None &&
EPI.ExceptionSpec.Type != EST_DynamicNone &&
Instantiation of local class members. If a function containing a local class is instantiated, instantiate all of local class member, including default arguments and exception specifications. This change fixes PR21332 and thus implements DR1484. Differential Revision: http://reviews.llvm.org/D9990 llvm-svn: 240974
2015-06-30 01:50:19 +08:00
EPI.ExceptionSpec.Type != EST_BasicNoexcept &&
Instantiate function declarations in instantiated functions. If a function declaration is found inside a template function as in: template<class T> void f() { void g(int x = T::v) except(T::w); } it must be instantiated along with the enclosing template function, including default arguments and exception specification. Together with the patch committed in r240974 this implements DR1484. Differential Revision: http://reviews.llvm.org/D11194 llvm-svn: 245810
2015-08-23 18:22:28 +08:00
!Tmpl->isLexicallyWithinFunctionOrMethod()) {
PR 12586: Fix assert while running libc++ testsuite: deal with exception specifications on member function templates of class templates and other such nested beasties. Store the function template from which we are to instantiate an exception specification rather than trying to deduce it. Plus some additional test cases. llvm-svn: 155076
2012-04-19 08:08:28 +08:00
FunctionDecl *ExceptionSpecTemplate = Tmpl;
Factor out exception specification information from FunctionProtoType::ExtProtoInfo. Most of the users of these fields don't care about the other ExtProtoInfo bits and just want to talk about the exception specification. llvm-svn: 214450
2014-08-01 05:57:55 +08:00
if (EPI.ExceptionSpec.Type == EST_Uninstantiated)
ExceptionSpecTemplate = EPI.ExceptionSpec.SourceTemplate;
C++11 inheriting constructors: support for inheriting constructor templates. llvm-svn: 179151
2013-04-10 13:48:59 +08:00
ExceptionSpecificationType NewEST = EST_Uninstantiated;
Factor out exception specification information from FunctionProtoType::ExtProtoInfo. Most of the users of these fields don't care about the other ExtProtoInfo bits and just want to talk about the exception specification. llvm-svn: 214450
2014-08-01 05:57:55 +08:00
if (EPI.ExceptionSpec.Type == EST_Unevaluated)
C++11 inheriting constructors: support for inheriting constructor templates. llvm-svn: 179151
2013-04-10 13:48:59 +08:00
NewEST = EST_Unevaluated;
PR 12586: Fix assert while running libc++ testsuite: deal with exception specifications on member function templates of class templates and other such nested beasties. Store the function template from which we are to instantiate an exception specification rather than trying to deduce it. Plus some additional test cases. llvm-svn: 155076
2012-04-19 08:08:28 +08:00
Implement DR1330 in C++11 mode, to support libstdc++4.7 which uses it. We have a new flavor of exception specification, EST_Uninstantiated. A function type with this exception specification carries a pointer to a FunctionDecl, and the exception specification for that FunctionDecl is instantiated (if needed) and used in the place of the function type's exception specification. When a function template declaration with a non-trivial exception specification is instantiated, the specialization's exception specification is set to this new 'uninstantiated' kind rather than being instantiated immediately. Expr::CanThrow has migrated onto Sema, so it can instantiate exception specs on-demand. Also, any odr-use of a function triggers the instantiation of its exception specification (the exception specification could be needed by IRGen). In passing, fix two places where a DeclRefExpr was created but the corresponding function was not actually marked odr-used. We used to get away with this, but don't any more. Also fix a bug where instantiating an exception specification which refers to function parameters resulted in a crash. We still have the same bug in default arguments, which I'll be looking into next. This, plus a tiny patch to fix libstdc++'s common_type, is enough for clang to parse (and, in very limited testing, support) all of libstdc++4.7's standard headers. llvm-svn: 154886
2012-04-17 08:58:00 +08:00
// Mark the function has having an uninstantiated exception specification.
const FunctionProtoType *NewProto
= New->getType()->getAs<FunctionProtoType>();
assert(NewProto && "Template instantiation without function prototype?");
EPI = NewProto->getExtProtoInfo();
Factor out exception specification information from FunctionProtoType::ExtProtoInfo. Most of the users of these fields don't care about the other ExtProtoInfo bits and just want to talk about the exception specification. llvm-svn: 214450
2014-08-01 05:57:55 +08:00
EPI.ExceptionSpec.Type = NewEST;
EPI.ExceptionSpec.SourceDecl = New;
EPI.ExceptionSpec.SourceTemplate = ExceptionSpecTemplate;
Use FPT::getArgTypes() instead of manually building ArrayRefs Made significantly easier with git-clang-format. Differential Revision: http://llvm-reviews.chandlerc.com/D947 llvm-svn: 183694
2013-06-11 04:51:09 +08:00
New->setType(SemaRef.Context.getFunctionType(
Rename getResultType() on function and method declarations to getReturnType() A return type is the declared or deduced part of the function type specified in the declaration. A result type is the (potentially adjusted) type of the value of an expression that calls the function. Rule of thumb: * Declarations have return types and parameters. * Expressions have result types and arguments. llvm-svn: 200082
2014-01-26 00:55:45 +08:00
NewProto->getReturnType(), NewProto->getParamTypes(), EPI));
Implement DR1330 in C++11 mode, to support libstdc++4.7 which uses it. We have a new flavor of exception specification, EST_Uninstantiated. A function type with this exception specification carries a pointer to a FunctionDecl, and the exception specification for that FunctionDecl is instantiated (if needed) and used in the place of the function type's exception specification. When a function template declaration with a non-trivial exception specification is instantiated, the specialization's exception specification is set to this new 'uninstantiated' kind rather than being instantiated immediately. Expr::CanThrow has migrated onto Sema, so it can instantiate exception specs on-demand. Also, any odr-use of a function triggers the instantiation of its exception specification (the exception specification could be needed by IRGen). In passing, fix two places where a DeclRefExpr was created but the corresponding function was not actually marked odr-used. We used to get away with this, but don't any more. Also fix a bug where instantiating an exception specification which refers to function parameters resulted in a crash. We still have the same bug in default arguments, which I'll be looking into next. This, plus a tiny patch to fix libstdc++'s common_type, is enough for clang to parse (and, in very limited testing, support) all of libstdc++4.7's standard headers. llvm-svn: 154886
2012-04-17 08:58:00 +08:00
} else {
Fix PR32638 : Make sure we switch Sema's CurContext to the substituted FunctionDecl when instantiating the exception specification. This fixes the bug: https://bugs.llvm.org/show_bug.cgi?id=32638 int main() { [](auto x) noexcept(noexcept(x)) { } (0); } In the above code, prior to this patch, when substituting into the noexcept expression, i.e. transforming the DeclRefExpr that represents 'x' - clang attempts to capture 'x' because Sema's CurContext is still pointing to the pattern FunctionDecl (i.e. the templated-decl set in FinishTemplateArgumentDeduction) which does not match the substituted 'x's DeclContext, which leads to an attempt to capture and an assertion failure. We fix this by adjusting Sema's CurContext to point to the substituted FunctionDecl under which the noexcept specifier's argument should be transformed, and so the ParmVarDecl that 'x' refers to has the same declcontext and no capture is attempted. I briefly investigated whether the SwitchContext should occur right after VisitMethodDecl creates the new substituted FunctionDecl, instead of only during instantiating the exception specification - but seeing no other code that seemed to rely on that, I decided to leave it just for the duration of the exception specification instantiation. llvm-svn: 302507
2017-05-09 12:17:15 +08:00
Sema::ContextRAII SwitchContext(SemaRef, New);
Instantiate exception specifications when instantiating function types (other than the type of a function declaration). We previously didn't instantiate these at all! This also covers the pathological case where the only mention of a parameter pack is within the exception specification; this gives us a second way (other than alias templates) to reach the horrible state where a type contains an unexpanded pack, but its canonical type does not. This is a re-commit of r219977: r219977 was reverted in r220038 because it hit a wrong-code bug in GCC 4.7.2. (That's gcc.gnu.org/PR56135, and affects any implicit lambda-capture of 'this' within a template.) r219977 was a re-commit of r217995, r218011, and r218053: r217995 was reverted in r218058 because it hit a rejects-valid bug in MSVC. (Incorrect overload resolution in the presence of using-declarations.) It was re-committed in r219977 with a workaround for the MSVC rejects-valid. r218011 was a workaround for an MSVC parser bug. (Incorrect desugaring of unbraced range-based for loop). llvm-svn: 221750
2014-11-12 10:00:47 +08:00
SemaRef.SubstExceptionSpec(New, Proto, TemplateArgs);
Implement DR1330 in C++11 mode, to support libstdc++4.7 which uses it. We have a new flavor of exception specification, EST_Uninstantiated. A function type with this exception specification carries a pointer to a FunctionDecl, and the exception specification for that FunctionDecl is instantiated (if needed) and used in the place of the function type's exception specification. When a function template declaration with a non-trivial exception specification is instantiated, the specialization's exception specification is set to this new 'uninstantiated' kind rather than being instantiated immediately. Expr::CanThrow has migrated onto Sema, so it can instantiate exception specs on-demand. Also, any odr-use of a function triggers the instantiation of its exception specification (the exception specification could be needed by IRGen). In passing, fix two places where a DeclRefExpr was created but the corresponding function was not actually marked odr-used. We used to get away with this, but don't any more. Also fix a bug where instantiating an exception specification which refers to function parameters resulted in a crash. We still have the same bug in default arguments, which I'll be looking into next. This, plus a tiny patch to fix libstdc++'s common_type, is enough for clang to parse (and, in very limited testing, support) all of libstdc++4.7's standard headers. llvm-svn: 154886
2012-04-17 08:58:00 +08:00
}
Implement template instantiation for exception specifications. Also, print exception specifications on function types and declarations. Fixes <rdar://problem/7450999>. There is some poor source-location information here, because we don't track locations of the types in exception specifications. Filed PR5719. Failures during template instantiation of the signature of a function or function template have wrong point-of-instantiation location information. I'll tackle that with a separate commit. llvm-svn: 90863
2009-12-09 01:45:32 +08:00
}
Use attributes from the definition (if available) when instantiating functions. Fixes PR10272. llvm-svn: 134491
2011-07-06 23:46:09 +08:00
// Get the definition. Leaves the variable unchanged if undefined.
Implement DR1330 in C++11 mode, to support libstdc++4.7 which uses it. We have a new flavor of exception specification, EST_Uninstantiated. A function type with this exception specification carries a pointer to a FunctionDecl, and the exception specification for that FunctionDecl is instantiated (if needed) and used in the place of the function type's exception specification. When a function template declaration with a non-trivial exception specification is instantiated, the specialization's exception specification is set to this new 'uninstantiated' kind rather than being instantiated immediately. Expr::CanThrow has migrated onto Sema, so it can instantiate exception specs on-demand. Also, any odr-use of a function triggers the instantiation of its exception specification (the exception specification could be needed by IRGen). In passing, fix two places where a DeclRefExpr was created but the corresponding function was not actually marked odr-used. We used to get away with this, but don't any more. Also fix a bug where instantiating an exception specification which refers to function parameters resulted in a crash. We still have the same bug in default arguments, which I'll be looking into next. This, plus a tiny patch to fix libstdc++'s common_type, is enough for clang to parse (and, in very limited testing, support) all of libstdc++4.7's standard headers. llvm-svn: 154886
2012-04-17 08:58:00 +08:00
const FunctionDecl *Definition = Tmpl;
Use attributes from the definition (if available) when instantiating functions. Fixes PR10272. llvm-svn: 134491
2011-07-06 23:46:09 +08:00
Tmpl->isDefined(Definition);
Delayed template instantiation of late-parsed attributes. llvm-svn: 148595
2012-01-21 06:50:54 +08:00
SemaRef.InstantiateAttrs(TemplateArgs, Definition, New,
LateAttrs, StartingScope);
Implement -fvisibility-inlines-hidden. <rdar://problem/7819834> llvm-svn: 106003
2010-06-16 01:05:35 +08:00
Improved semantic analysis and AST respresentation for function templates. For example, this now type-checks (but does not instantiate the body of deref<int>): template<typename T> T& deref(T* t) { return *t; } void test(int *ip) { int &ir = deref(ip); } Specific changes/additions: * Template argument deduction from a call to a function template. * Instantiation of a function template specializations (just the declarations) from the template arguments deduced from a call. * FunctionTemplateDecls are stored directly in declaration contexts and found via name lookup (all forms), rather than finding the FunctionDecl and then realizing it is a template. This is responsible for most of the churn, since some of the core declaration matching and lookup code assumes that all functions are FunctionDecls. llvm-svn: 74213
2009-06-26 06:08:12 +08:00
return false;
}
Cleanup template instantiation for methods, destructors llvm-svn: 67585
2009-03-24 08:38:23 +08:00
/// \brief Initializes common fields of an instantiated method
/// declaration (New) from the corresponding fields of its template
/// (Tmpl).
///
/// \returns true if there was an error
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
bool
TemplateDeclInstantiator::InitMethodInstantiation(CXXMethodDecl *New,
Cleanup template instantiation for methods, destructors llvm-svn: 67585
2009-03-24 08:38:23 +08:00
CXXMethodDecl *Tmpl) {
Improved semantic analysis and AST respresentation for function templates. For example, this now type-checks (but does not instantiate the body of deref<int>): template<typename T> T& deref(T* t) { return *t; } void test(int *ip) { int &ir = deref(ip); } Specific changes/additions: * Template argument deduction from a call to a function template. * Instantiation of a function template specializations (just the declarations) from the template arguments deduced from a call. * FunctionTemplateDecls are stored directly in declaration contexts and found via name lookup (all forms), rather than finding the FunctionDecl and then realizing it is a template. This is responsible for most of the churn, since some of the core declaration matching and lookup code assumes that all functions are FunctionDecls. llvm-svn: 74213
2009-06-26 06:08:12 +08:00
if (InitFunctionInstantiation(New, Tmpl))
return true;
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Cleanup template instantiation for methods, destructors llvm-svn: 67585
2009-03-24 08:38:23 +08:00
New->setAccess(Tmpl->getAccess());
A new helper function to set various bits in the class when a new virtual function is declared/instantiated. it is used in couple of places. llvm-svn: 90470
2009-12-04 02:44:40 +08:00
if (Tmpl->isVirtualAsWritten())
Reinstate r114925 and r114929, both steps toward <rdar://problem/8459981>. llvm-svn: 114984
2010-09-29 04:50:54 +08:00
New->setVirtualAsWritten(true);
Cleanup template instantiation for methods, destructors llvm-svn: 67585
2009-03-24 08:38:23 +08:00
// FIXME: New needs a pointer to Tmpl
return false;
}
Explicit instantiations of templates now instantiate the definitions of class members (recursively). Only member classes are actually instantiated; the instantiation logic for member functions and variables are just stubs. llvm-svn: 71713
2009-05-14 04:28:22 +08:00
[MS] Instantiate default args during instantiation of exported default ctors Summary: Replace some old code that probably pre-dated the change to delay emission of dllexported code until after the closing brace of the outermost record type. Only uninstantiated default argument expressions need to be handled now. It is enough to instantiate default argument expressions when instantiating dllexported default ctors. This also fixes some double-diagnostic issues in this area. Fixes PR31500 Reviewers: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D28274 llvm-svn: 291045
2017-01-05 09:08:22 +08:00
/// In the MS ABI, we need to instantiate default arguments of dllexported
/// default constructors along with the constructor definition. This allows IR
/// gen to emit a constructor closure which calls the default constructor with
/// its default arguments.
static void InstantiateDefaultCtorDefaultArgs(Sema &S,
CXXConstructorDecl *Ctor) {
assert(S.Context.getTargetInfo().getCXXABI().isMicrosoft() &&
Ctor->isDefaultConstructor());
unsigned NumParams = Ctor->getNumParams();
if (NumParams == 0)
return;
DLLExportAttr *Attr = Ctor->getAttr<DLLExportAttr>();
if (!Attr)
return;
for (unsigned I = 0; I != NumParams; ++I) {
(void)S.CheckCXXDefaultArgExpr(Attr->getLocation(), Ctor,
Ctor->getParamDecl(I));
S.DiscardCleanupsInEvaluationContext();
}
}
Explicit instantiations of templates now instantiate the definitions of class members (recursively). Only member classes are actually instantiated; the instantiation logic for member functions and variables are just stubs. llvm-svn: 71713
2009-05-14 04:28:22 +08:00
/// \brief Instantiate the definition of the given function from its
/// template.
///
When recursively instantiating function templates, keep track of the instantiation stack so that we provide a full instantiation backtrace. Previously, we performed all of the instantiations implied by the recursion, but each looked like a "top-level" instantiation. The included test case tests the previous fix for the instantiation of DeclRefExprs. Note that the "instantiated from" diagnostics still don't tell us which template arguments we're instantiating with. llvm-svn: 74540
2009-07-01 01:20:14 +08:00
/// \param PointOfInstantiation the point at which the instantiation was
/// required. Note that this is not precisely a "point of instantiation"
/// for the function, but it's close.
///
Explicit instantiations of templates now instantiate the definitions of class members (recursively). Only member classes are actually instantiated; the instantiation logic for member functions and variables are just stubs. llvm-svn: 71713
2009-05-14 04:28:22 +08:00
/// \param Function the already-instantiated declaration of a
When recursively instantiating function templates, keep track of the instantiation stack so that we provide a full instantiation backtrace. Previously, we performed all of the instantiations implied by the recursion, but each looked like a "top-level" instantiation. The included test case tests the previous fix for the instantiation of DeclRefExprs. Note that the "instantiated from" diagnostics still don't tell us which template arguments we're instantiating with. llvm-svn: 74540
2009-07-01 01:20:14 +08:00
/// function template specialization or member function of a class template
/// specialization.
///
/// \param Recursive if true, recursively instantiates any functions that
/// are required by this instantiation.
Diagnose explicit instantiations of function templates and member functions/static data members of class template specializations that do not have definitions. This is the latter part of [temp.explicit]p4; the former part still needs more testing. llvm-svn: 84182
2009-10-15 22:05:49 +08:00
///
/// \param DefinitionRequired if true, then we are performing an explicit
/// instantiation where the body of the function is required. Complain if
/// there is no such body.
When instantiating the definition of a member function of a class template, introduce that member function into the template instantiation stack. Also, add diagnostics showing the member function within the instantiation stack and clean up the qualified-name printing so that we get something like: note: in instantiation of member function 'Switch1<int, 2, 2>::f' requested here in the template instantiation backtrace. llvm-svn: 72015
2009-05-19 01:01:57 +08:00
void Sema::InstantiateFunctionDefinition(SourceLocation PointOfInstantiation,
When recursively instantiating function templates, keep track of the instantiation stack so that we provide a full instantiation backtrace. Previously, we performed all of the instantiations implied by the recursion, but each looked like a "top-level" instantiation. The included test case tests the previous fix for the instantiation of DeclRefExprs. Note that the "instantiated from" diagnostics still don't tell us which template arguments we're instantiating with. llvm-svn: 74540
2009-07-01 01:20:14 +08:00
FunctionDecl *Function,
Diagnose explicit instantiations of function templates and member functions/static data members of class template specializations that do not have definitions. This is the latter part of [temp.explicit]p4; the former part still needs more testing. llvm-svn: 84182
2009-10-15 22:05:49 +08:00
bool Recursive,
Warn if function or variable cannot be implicitly instantiated With this patch compiler emits warning if it tries to make implicit instantiation of a template but cannot find the template definition. The warning can be suppressed by explicit instantiation declaration or by command line options -Wundefined-var-template and -Wundefined-func-template. The implementation follows the discussion of http://reviews.llvm.org/D12326. Differential Revision: http://reviews.llvm.org/D16396 llvm-svn: 266719
2016-04-19 14:19:52 +08:00
bool DefinitionRequired,
bool AtEndOfTU) {
Modify some deleted function methods to better reflect reality: - New isDefined() function checks for deletedness - isThisDeclarationADefinition checks for deletedness - New doesThisDeclarationHaveABody() does what isThisDeclarationADefinition() used to do - The IsDeleted bit is not propagated across redeclarations - isDeleted() now checks the canoncial declaration - New isDeletedAsWritten() does what it says on the tin. - isUserProvided() now correct (thanks Richard!) This fixes the bug that we weren't catching void foo() = delete; void foo() {} as being a redefinition. llvm-svn: 131013
2011-05-07 04:44:56 +08:00
if (Function->isInvalidDecl() || Function->isDefined())
Introduce basic support for instantiating the definitions of member functions of class templates. Only compound statements and expression statements are currently implemented. llvm-svn: 71814
2009-05-15 07:26:13 +08:00
return;
Implement function template specialization at class scope extension in Microsoft mode. A new AST node is introduced: ClassScopeFunctionSpecialization. This node holds a FunctionDecl that is not yet specialized; then during the class template instantiation the ClassScopeFunctionSpecialization will spawn the actual function specialization. Example: template <class T> class A { public: template <class U> void f(U p) { } template <> void f(int p) { } // <== class scope specialization }; This extension is necessary to parse MSVC standard C++ headers, MFC and ATL code. BTW, with this feature in, clang can parse (-fsyntax-only) all the MSVC 2010 standard header files without any error. llvm-svn: 137573
2011-08-14 11:52:19 +08:00
// Never instantiate an explicit specialization except if it is a class scope
// explicit specialization.
PR28794: Don't try to instantiate function templates which are not visible. Reviewed by Richard Smith. llvm-svn: 279164
2016-08-19 06:01:25 +08:00
TemplateSpecializationKind TSK = Function->getTemplateSpecializationKind();
if (TSK == TSK_ExplicitSpecialization &&
Implement function template specialization at class scope extension in Microsoft mode. A new AST node is introduced: ClassScopeFunctionSpecialization. This node holds a FunctionDecl that is not yet specialized; then during the class template instantiation the ClassScopeFunctionSpecialization will spawn the actual function specialization. Example: template <class T> class A { public: template <class U> void f(U p) { } template <> void f(int p) { } // <== class scope specialization }; This extension is necessary to parse MSVC standard C++ headers, MFC and ATL code. BTW, with this feature in, clang can parse (-fsyntax-only) all the MSVC 2010 standard header files without any error. llvm-svn: 137573
2011-08-14 11:52:19 +08:00
!Function->getClassScopeSpecializationPattern())
For instantiations of static data members of class templates, keep track of the kind of specialization or instantiation. Also, check the scope of the specialization and ensure that a specialization declaration without an initializer is not a definition. llvm-svn: 83533
2009-10-08 15:24:58 +08:00
return;
Determine when the instantiation of a friend function defined inside a class template conflicts with an existing (non-template) definition. This is another part of PR6952. llvm-svn: 103948
2010-05-18 01:34:56 +08:00
Link FunctionDecls instantiated from the member functions of a class template to the FunctionDecls from which they were instantiated. This is a necessary first step to support instantiation of the definitions of such functions, but by itself does essentially nothing. llvm-svn: 71792
2009-05-15 05:06:31 +08:00
// Find the function body that we'll be substituting.
Explicit instantiation suppresses the instantiation of non-inline function template specializations and member functions of class template specializations. llvm-svn: 85300
2009-10-28 04:53:28 +08:00
const FunctionDecl *PatternDecl = Function->getTemplateInstantiationPattern();
Add assertions to verify that we are not trying to instantiate a nontemplate in Sema::InstantiateTemplateDecl. This should make the issue in PR10026 more visible, although it's not going to fix it because something is violating this precondition. llvm-svn: 132208
2011-05-28 04:00:14 +08:00
assert(PatternDecl && "instantiating a non-template");
Fix regression introduced by r279164: only pass definitions as the PatternDef to DiagnoseUninstantiableTemplate, teach hasVisibleDefinition to correctly determine whether a function definition is visible, and mark both the function and the template as visible when merging function template definitions to provide hasVisibleDefinition with the relevant information. The change to always pass the right declaration as the PatternDef to DiagnoseUninstantiableTemplate also caused those checks to happen before other diagnostics in InstantiateFunctionDefinition, giving worse diagnostics for the same situations, so I sunk the relevant diagnostics into DiagnoseUninstantiableTemplate. Those parts of this patch are based on changes in reviews.llvm.org/D23492 by Vassil Vassilev. This reinstates r279486, reverted in r279500, with a fix to DiagnoseUninstantiableTemplate to only mark uninstantiable explicit instantiation declarations as invalid if we actually diagnosed them. (When we trigger an explicit instantiation of a class member from an explicit instantiation declaration for the class, it's OK if there is no corresponding definition and we certainly don't want to mark the member invalid in that case.) This previously caused a build failure during bootstrap. llvm-svn: 279557
2016-08-24 03:41:39 +08:00
const FunctionDecl *PatternDef = PatternDecl->getDefinition();
Fix member call on null pointer, found by sanitizer buildbot. llvm-svn: 279571
2016-08-24 05:12:54 +08:00
Stmt *Pattern = nullptr;
if (PatternDef) {
Pattern = PatternDef->getBody(PatternDef);
Fix regression introduced by r279164: only pass definitions as the PatternDef to DiagnoseUninstantiableTemplate, teach hasVisibleDefinition to correctly determine whether a function definition is visible, and mark both the function and the template as visible when merging function template definitions to provide hasVisibleDefinition with the relevant information. The change to always pass the right declaration as the PatternDef to DiagnoseUninstantiableTemplate also caused those checks to happen before other diagnostics in InstantiateFunctionDefinition, giving worse diagnostics for the same situations, so I sunk the relevant diagnostics into DiagnoseUninstantiableTemplate. Those parts of this patch are based on changes in reviews.llvm.org/D23492 by Vassil Vassilev. This reinstates r279486, reverted in r279500, with a fix to DiagnoseUninstantiableTemplate to only mark uninstantiable explicit instantiation declarations as invalid if we actually diagnosed them. (When we trigger an explicit instantiation of a class member from an explicit instantiation declaration for the class, it's OK if there is no corresponding definition and we certainly don't want to mark the member invalid in that case.) This previously caused a build failure during bootstrap. llvm-svn: 279557
2016-08-24 03:41:39 +08:00
PatternDecl = PatternDef;
Fix member call on null pointer, found by sanitizer buildbot. llvm-svn: 279571
2016-08-24 05:12:54 +08:00
}
Link FunctionDecls instantiated from the member functions of a class template to the FunctionDecls from which they were instantiated. This is a necessary first step to support instantiation of the definitions of such functions, but by itself does essentially nothing. llvm-svn: 71792
2009-05-15 05:06:31 +08:00
PR28794: Don't try to instantiate function templates which are not visible. Reviewed by Richard Smith. llvm-svn: 279164
2016-08-19 06:01:25 +08:00
// FIXME: We need to track the instantiation stack in order to know which
// definitions should be visible within this instantiation.
if (DiagnoseUninstantiableTemplate(PointOfInstantiation, Function,
Function->getInstantiatedFromMemberFunction(),
Fix regression introduced by r279164: only pass definitions as the PatternDef to DiagnoseUninstantiableTemplate, teach hasVisibleDefinition to correctly determine whether a function definition is visible, and mark both the function and the template as visible when merging function template definitions to provide hasVisibleDefinition with the relevant information. The change to always pass the right declaration as the PatternDef to DiagnoseUninstantiableTemplate also caused those checks to happen before other diagnostics in InstantiateFunctionDefinition, giving worse diagnostics for the same situations, so I sunk the relevant diagnostics into DiagnoseUninstantiableTemplate. Those parts of this patch are based on changes in reviews.llvm.org/D23492 by Vassil Vassilev. This reinstates r279486, reverted in r279500, with a fix to DiagnoseUninstantiableTemplate to only mark uninstantiable explicit instantiation declarations as invalid if we actually diagnosed them. (When we trigger an explicit instantiation of a class member from an explicit instantiation declaration for the class, it's OK if there is no corresponding definition and we certainly don't want to mark the member invalid in that case.) This previously caused a build failure during bootstrap. llvm-svn: 279557
2016-08-24 03:41:39 +08:00
PatternDecl, PatternDef, TSK,
/*Complain*/DefinitionRequired)) {
if (DefinitionRequired)
Function->setInvalidDecl();
else if (TSK == TSK_ExplicitInstantiationDefinition) {
// Try again at the end of the translation unit (at which point a
// definition will be required).
assert(!Recursive);
PendingInstantiations.push_back(
std::make_pair(Function, PointOfInstantiation));
} else if (TSK == TSK_ImplicitInstantiation) {
Switch the template specialization kind for a non-defining declaration of a non-template function instantiated from a friend declaration in a class template from TSK_ImplicitInstantiation to TSK_Undeclared. It doesn't make sense for a non-template function to be flagged as being instantiated from a template; that property really belongs to the entity as a whole and not an individual declaration of it. There's some history here: * r137934 started marking these functions as instantiations in order to work around an issue where we might instantiate a class template while we're still parsing its member definitions, and would otherwise fail to instantiate the friend definition * r177003 fixed the same issue but for friend templates, but did so by making the friends claim to be definitions even before we'd parsed their actual bodies; this made the r137934 change redundant * r293558 worked around a problem caused by the marking of a non-template function as a template instantiation in r137934 This change reverts the code changes from r293358 and r137934 and retains all the tests. llvm-svn: 293367
2017-01-28 10:56:07 +08:00
if (AtEndOfTU && !getDiagnostics().hasErrorOccurred()) {
Fix regression introduced by r279164: only pass definitions as the PatternDef to DiagnoseUninstantiableTemplate, teach hasVisibleDefinition to correctly determine whether a function definition is visible, and mark both the function and the template as visible when merging function template definitions to provide hasVisibleDefinition with the relevant information. The change to always pass the right declaration as the PatternDef to DiagnoseUninstantiableTemplate also caused those checks to happen before other diagnostics in InstantiateFunctionDefinition, giving worse diagnostics for the same situations, so I sunk the relevant diagnostics into DiagnoseUninstantiableTemplate. Those parts of this patch are based on changes in reviews.llvm.org/D23492 by Vassil Vassilev. This reinstates r279486, reverted in r279500, with a fix to DiagnoseUninstantiableTemplate to only mark uninstantiable explicit instantiation declarations as invalid if we actually diagnosed them. (When we trigger an explicit instantiation of a class member from an explicit instantiation declaration for the class, it's OK if there is no corresponding definition and we certainly don't want to mark the member invalid in that case.) This previously caused a build failure during bootstrap. llvm-svn: 279557
2016-08-24 03:41:39 +08:00
Diag(PointOfInstantiation, diag::warn_func_template_missing)
<< Function;
Diag(PatternDecl->getLocation(), diag::note_forward_template_decl);
if (getLangOpts().CPlusPlus11)
Diag(PointOfInstantiation, diag::note_inst_declaration_hint)
<< Function;
}
}
PR28794: Don't try to instantiate function templates which are not visible. Reviewed by Richard Smith. llvm-svn: 279164
2016-08-19 06:01:25 +08:00
Fix regression introduced by r279164: only pass definitions as the PatternDef to DiagnoseUninstantiableTemplate, teach hasVisibleDefinition to correctly determine whether a function definition is visible, and mark both the function and the template as visible when merging function template definitions to provide hasVisibleDefinition with the relevant information. The change to always pass the right declaration as the PatternDef to DiagnoseUninstantiableTemplate also caused those checks to happen before other diagnostics in InstantiateFunctionDefinition, giving worse diagnostics for the same situations, so I sunk the relevant diagnostics into DiagnoseUninstantiableTemplate. Those parts of this patch are based on changes in reviews.llvm.org/D23492 by Vassil Vassilev. This reinstates r279486, reverted in r279500, with a fix to DiagnoseUninstantiableTemplate to only mark uninstantiable explicit instantiation declarations as invalid if we actually diagnosed them. (When we trigger an explicit instantiation of a class member from an explicit instantiation declaration for the class, it's OK if there is no corresponding definition and we certainly don't want to mark the member invalid in that case.) This previously caused a build failure during bootstrap. llvm-svn: 279557
2016-08-24 03:41:39 +08:00
return;
}
PR28794: Don't try to instantiate function templates which are not visible. Reviewed by Richard Smith. llvm-svn: 279164
2016-08-19 06:01:25 +08:00
Add -fdelayed-template-parsing option. Using this option all templated function definitions are parsed at the end of the translation unit only if it is required by an actual instantiation. As such all the symbols of the TU are available during name lookup. Using this flag is necessary for compatibility with Microsoft template code. This also provides some parsing speed improvement. llvm-svn: 130022
2011-04-23 06:18:13 +08:00
// Postpone late parsed template instantiations.
Add assertions to verify that we are not trying to instantiate a nontemplate in Sema::InstantiateTemplateDecl. This should make the issue in PR10026 more visible, although it's not going to fix it because something is violating this precondition. llvm-svn: 132208
2011-05-28 04:00:14 +08:00
if (PatternDecl->isLateTemplateParsed() &&
Fix crasher spotted in IWYU. llvm-svn: 131222
2011-05-12 11:51:24 +08:00
!LateTemplateParser) {
Add -fdelayed-template-parsing option. Using this option all templated function definitions are parsed at the end of the translation unit only if it is required by an actual instantiation. As such all the symbols of the TU are available during name lookup. Using this flag is necessary for compatibility with Microsoft template code. This also provides some parsing speed improvement. llvm-svn: 130022
2011-04-23 06:18:13 +08:00
PendingInstantiations.push_back(
std::make_pair(Function, PointOfInstantiation));
return;
}
Make sure that vtables referenced from delay-parsed templates get referenced. This fixes PR20671, see the bug for details. In short, ActOnTranslationUnit() calls DefineUsedVTables() and only then PerformPendingInstantiations(). But PerformPendingInstantiations() is what does delayed template parsing, so vtables only references from late-parsed templates weren't marked used. As a fix, move the SavePendingInstantiationsAndVTableUsesRAII in PerformPendingInstantiations() up above the delayed template parsing code. That way, vtables referenced from templates end up in the RAII object, and the call to DefineUsedVTables() in PerformPendingInstantiations() marks them used. llvm-svn: 215786
2014-08-16 07:21:41 +08:00
// If we're performing recursive template instantiation, create our own
// queue of pending implicit instantiations that we will instantiate later,
// while we're still within our own instantiation context.
// This has to happen before LateTemplateParser below is called, so that
// it marks vtables used in late parsed templates as used.
Rename RAII objects for performing eager instantiation to have names that describe what they're for, not how they do it, and factor out a bit more common code into them. llvm-svn: 303479
2017-05-20 09:36:41 +08:00
GlobalEagerInstantiationScope GlobalInstantiations(*this,
/*Enabled=*/Recursive);
LocalEagerInstantiationScope LocalInstantiations(*this);
Make sure that vtables referenced from delay-parsed templates get referenced. This fixes PR20671, see the bug for details. In short, ActOnTranslationUnit() calls DefineUsedVTables() and only then PerformPendingInstantiations(). But PerformPendingInstantiations() is what does delayed template parsing, so vtables only references from late-parsed templates weren't marked used. As a fix, move the SavePendingInstantiationsAndVTableUsesRAII in PerformPendingInstantiations() up above the delayed template parsing code. That way, vtables referenced from templates end up in the RAII object, and the call to DefineUsedVTables() in PerformPendingInstantiations() marks them used. llvm-svn: 215786
2014-08-16 07:21:41 +08:00
Parse: Do not 'HandleTopLevelDecl' on templated functions. Summary: HandleTopLevelDecl on a templated function leads us to try and mangle it. Reviewers: rsmith Reviewed By: rsmith CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1412 llvm-svn: 188536
2013-08-16 16:29:13 +08:00
// Call the LateTemplateParser callback if there is a need to late parse
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
// a templated function definition.
Add assertions to verify that we are not trying to instantiate a nontemplate in Sema::InstantiateTemplateDecl. This should make the issue in PR10026 more visible, although it's not going to fix it because something is violating this precondition. llvm-svn: 132208
2011-05-28 04:00:14 +08:00
if (!Pattern && PatternDecl->isLateTemplateParsed() &&
Add -fdelayed-template-parsing option. Using this option all templated function definitions are parsed at the end of the translation unit only if it is required by an actual instantiation. As such all the symbols of the TU are available during name lookup. Using this flag is necessary for compatibility with Microsoft template code. This also provides some parsing speed improvement. llvm-svn: 130022
2011-04-23 06:18:13 +08:00
LateTemplateParser) {
PR9992: Serialize and deserialize the token sequence for a function template in -fdelayed-template-parsing mode. Patch by Will Wilson! llvm-svn: 187916
2013-08-08 05:41:30 +08:00
// FIXME: Optimize to allow individual templates to be deserialized.
if (PatternDecl->isFromASTFile())
ExternalSource->ReadLateParsedTemplates(LateParsedTemplateMap);
[Sema] Use unique_ptr instead of raw pointers in the late-parsed templates map. Summary: This is possible now that MapVector supports move-only values. Depends on D25404. Reviewers: timshen Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D25405 llvm-svn: 283766
2016-10-11 00:26:08 +08:00
auto LPTIter = LateParsedTemplateMap.find(PatternDecl);
assert(LPTIter != LateParsedTemplateMap.end() &&
"missing LateParsedTemplate");
LateTemplateParser(OpaqueParser, *LPTIter->second);
Add -fdelayed-template-parsing option. Using this option all templated function definitions are parsed at the end of the translation unit only if it is required by an actual instantiation. As such all the symbols of the TU are available during name lookup. Using this flag is necessary for compatibility with Microsoft template code. This also provides some parsing speed improvement. llvm-svn: 130022
2011-04-23 06:18:13 +08:00
Pattern = PatternDecl->getBody(PatternDecl);
}
Fix regression introduced by r279164: only pass definitions as the PatternDef to DiagnoseUninstantiableTemplate, teach hasVisibleDefinition to correctly determine whether a function definition is visible, and mark both the function and the template as visible when merging function template definitions to provide hasVisibleDefinition with the relevant information. The change to always pass the right declaration as the PatternDef to DiagnoseUninstantiableTemplate also caused those checks to happen before other diagnostics in InstantiateFunctionDefinition, giving worse diagnostics for the same situations, so I sunk the relevant diagnostics into DiagnoseUninstantiableTemplate. Those parts of this patch are based on changes in reviews.llvm.org/D23492 by Vassil Vassilev. This reinstates r279486, reverted in r279500, with a fix to DiagnoseUninstantiableTemplate to only mark uninstantiable explicit instantiation declarations as invalid if we actually diagnosed them. (When we trigger an explicit instantiation of a class member from an explicit instantiation declaration for the class, it's OK if there is no corresponding definition and we certainly don't want to mark the member invalid in that case.) This previously caused a build failure during bootstrap. llvm-svn: 279557
2016-08-24 03:41:39 +08:00
// Note, we should never try to instantiate a deleted function template.
assert((Pattern || PatternDecl->isDefaulted()) &&
"unexpected kind of function template definition");
Link FunctionDecls instantiated from the member functions of a class template to the FunctionDecls from which they were instantiated. This is a necessary first step to support instantiation of the definitions of such functions, but by itself does essentially nothing. llvm-svn: 71792
2009-05-15 05:06:31 +08:00
Implement most of N3638 (return type deduction for normal functions). Missing (somewhat ironically) is support for the new deduction rules in lambda functions, plus PCH support for return type patching. llvm-svn: 181108
2013-05-04 15:00:32 +08:00
// C++1y [temp.explicit]p10:
// Except for inline functions, declarations with types deduced from their
// initializer or return value, and class template specializations, other
// explicit instantiation declarations have the effect of suppressing the
// implicit instantiation of the entity to which they refer.
PR28794: Don't try to instantiate function templates which are not visible. Reviewed by Richard Smith. llvm-svn: 279164
2016-08-19 06:01:25 +08:00
if (TSK == TSK_ExplicitInstantiationDeclaration &&
Implement most of N3638 (return type deduction for normal functions). Missing (somewhat ironically) is support for the new deduction rules in lambda functions, plus PCH support for return type patching. llvm-svn: 181108
2013-05-04 15:00:32 +08:00
!PatternDecl->isInlined() &&
Rename getResultType() on function and method declarations to getReturnType() A return type is the declared or deduced part of the function type specified in the declaration. A result type is the (potentially adjusted) type of the value of an expression that calls the function. Rule of thumb: * Declarations have return types and parameters. * Expressions have result types and arguments. llvm-svn: 200082
2014-01-26 00:55:45 +08:00
!PatternDecl->getReturnType()->getContainedAutoType())
Improve the AST representation and semantic analysis for extern templates. We now distinguish between an explicit instantiation declaration and an explicit instantiation definition, and know not to instantiate explicit instantiation declarations. Unfortunately, there is some remaining confusion w.r.t. instantiation of out-of-line member function definitions that causes trouble here. llvm-svn: 81053
2009-09-05 06:48:11 +08:00
return;
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
When merging functions across modules (and in particular, instantiations of member functions), ensure that the redecl chain never transitions from 'inline' to 'not inline', since that violates an AST invariant. llvm-svn: 209794
2014-05-29 11:15:31 +08:00
if (PatternDecl->isInlined()) {
// Function, and all later redeclarations of it (from imported modules,
// for instance), are now implicitly inline.
for (auto *D = Function->getMostRecentDecl(); /**/;
D = D->getPreviousDecl()) {
D->setImplicitlyInline();
if (D == Function)
break;
}
}
Clean up: since we have FunctionDecl::IsInline, make it store the right value for template instantiations, and use it to simplify the implementation of FunctionDecl::isInlined(). This incidentally changes the result of isInlined on a declared-but-not-defined non-inline member function from true to false. This is sort of a bug fix, but currently isInlined is only called on function definitions, so it has no visible effects. llvm-svn: 173397
2013-01-25 08:08:28 +08:00
When instantiating the definition of a member function of a class template, introduce that member function into the template instantiation stack. Also, add diagnostics showing the member function within the instantiation stack and clean up the qualified-name printing so that we get something like: note: in instantiation of member function 'Switch1<int, 2, 2>::f' requested here in the template instantiation backtrace. llvm-svn: 72015
2009-05-19 01:01:57 +08:00
InstantiatingTemplate Inst(*this, PointOfInstantiation, Function);
PR12298 et al: don't recursively instantiate a template specialization from within the instantiation of that same specialization. This could previously happen for eagerly-instantiated function templates, variable templates, exception specifications, default arguments, and a handful of other cases. We still have an issue here for default template arguments that recursively make use of themselves and likewise for substitution into the type of a non-type template parameter, but in those cases we're producing a different entity each time, so they should instead be caught by the instantiation depth limit. However, currently we will typically run out of stack before we reach it. :( llvm-svn: 280190
2016-08-31 10:15:21 +08:00
if (Inst.isInvalid() || Inst.isAlreadyInstantiating())
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
return;
Produce better pretty stack traces from crashes in template instantiation: add pretty stack trace entries for all cases where we instantiate the definition of something, and include the fully-qualified name with template arguments in the name of the instantiated entity. llvm-svn: 270904
2016-05-27 04:23:13 +08:00
PrettyDeclStackTraceEntry CrashInfo(*this, Function, SourceLocation(),
"instantiating function definition");
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
PR28794: Don't try to instantiate function templates which are not visible. Reviewed by Richard Smith. llvm-svn: 279164
2016-08-19 06:01:25 +08:00
// The instantiation is visible here, even if it was first declared in an
// unimported module.
Function->setHidden(false);
Fixed implicit instantiations source range. llvm-svn: 144977
2011-11-18 16:08:52 +08:00
// Copy the inner loc start from the pattern.
Function->setInnerLocStart(PatternDecl->getInnerLocStart());
[NFC, Scoped Enum] Convert Sema::ExpressionEvaluationContext into a scoped Enum - also replace direct equality checks against the ConstantEvaluated enumerator with isConstantEvaluted(), in anticipation of adding finer granularity to the various ConstantEvaluated contexts and reinstating certain restrictions on where lambda expressions can occur in C++17. - update the clang tablegen backend that uses these Enumerators, and add the relevant scope where needed. llvm-svn: 299316
2017-04-02 05:30:49 +08:00
EnterExpressionEvaluationContext EvalContext(
*this, Sema::ExpressionEvaluationContext::PotentiallyEvaluated);
Call ActOnStartOfFunctionDecl/ActOnFinishFunctionBody when instantiating the definition of a function from a template. llvm-svn: 71869
2009-05-16 01:59:04 +08:00
Introduce basic support for instantiating the definitions of member functions of class templates. Only compound statements and expression statements are currently implemented. llvm-svn: 71814
2009-05-15 07:26:13 +08:00
// Introduce a new scope where local variable instantiations will be
Introduce a second queue of "local" pending implicit instantiation, which are instantiations of the member functions of local classes. These implicit instantiations have to occur at the same time as---and in the same local instantiation scope as---the enclosing function, since the member functions of the local class can refer to locals within the enclosing function. This should really, really fix PR5764. llvm-svn: 93666
2010-01-17 06:29:39 +08:00
// recorded, unless we're actually a member function within a local
// class, in which case we need to merge our results with the parent
// scope (of the enclosing function).
bool MergeWithParentScope = false;
if (CXXRecordDecl *Rec = dyn_cast<CXXRecordDecl>(Function->getDeclContext()))
MergeWithParentScope = Rec->isLocalClass();
LocalInstantiationScope Scope(*this, MergeWithParentScope);
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
PR14558: Compute triviality of special members (etc) at the end of the class definition, rather than at the end of the definition of the set of nested classes. We still defer checking of the user-specified exception specification to the end of the nesting -- we can't check that until we've parsed the in-class initializers for non-static data members. llvm-svn: 169805
2012-12-11 09:14:52 +08:00
if (PatternDecl->isDefaulted())
SetDeclDefaulted(Function, PatternDecl->getLocation());
else {
Don't forget to substitute into the qualifier when instantiating the definition of a member function of a class template that is defined outside the template. This substitution can actually fail in some weird cases. llvm-svn: 220085
2014-10-18 04:37:29 +08:00
MultiLevelTemplateArgumentList TemplateArgs =
getTemplateInstantiationArgs(Function, nullptr, false, PatternDecl);
// Substitute into the qualifier; we can get a substitution failure here
// through evil use of alias templates.
// FIXME: Is CurContext correct for this? Should we go to the (instantiation
// of the) lexical context of the pattern?
SubstQualifier(*this, PatternDecl, Function, TemplateArgs);
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
ActOnStartOfFunctionDef(nullptr, Function);
PR11850 + duplicates: don't assume that a function parameter pack expansion is at the end of the parameter list. llvm-svn: 152618
2012-03-13 14:56:52 +08:00
PR14558: Compute triviality of special members (etc) at the end of the class definition, rather than at the end of the definition of the set of nested classes. We still defer checking of the user-specified exception specification to the end of the nesting -- we can't check that until we've parsed the in-class initializers for non-static data members. llvm-svn: 169805
2012-12-11 09:14:52 +08:00
// Enter the scope of this instantiation. We don't use
// PushDeclContext because we don't have a scope.
Sema::ContextRAII savedContext(*this, Function);
PR11850 + duplicates: don't assume that a function parameter pack expansion is at the end of the parameter list. llvm-svn: 152618
2012-03-13 14:56:52 +08:00
Instantiate exception specifications when instantiating function types (other than the type of a function declaration). We previously didn't instantiate these at all! This also covers the pathological case where the only mention of a parameter pack is within the exception specification; this gives us a second way (other than alias templates) to reach the horrible state where a type contains an unexpanded pack, but its canonical type does not. This is a re-commit of r219977: r219977 was reverted in r220038 because it hit a wrong-code bug in GCC 4.7.2. (That's gcc.gnu.org/PR56135, and affects any implicit lambda-capture of 'this' within a template.) r219977 was a re-commit of r217995, r218011, and r218053: r217995 was reverted in r218058 because it hit a rejects-valid bug in MSVC. (Incorrect overload resolution in the presence of using-declarations.) It was re-committed in r219977 with a workaround for the MSVC rejects-valid. r218011 was a workaround for an MSVC parser bug. (Incorrect desugaring of unbraced range-based for loop). llvm-svn: 221750
2014-11-12 10:00:47 +08:00
if (addInstantiatedParametersToScope(*this, Function, PatternDecl, Scope,
TemplateArgs))
return;
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
[MS] Instantiate default args during instantiation of exported default ctors Summary: Replace some old code that probably pre-dated the change to delay emission of dllexported code until after the closing brace of the outermost record type. Only uninstantiated default argument expressions need to be handled now. It is enough to instantiate default argument expressions when instantiating dllexported default ctors. This also fixes some double-diagnostic issues in this area. Fixes PR31500 Reviewers: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D28274 llvm-svn: 291045
2017-01-05 09:08:22 +08:00
if (CXXConstructorDecl *Ctor = dyn_cast<CXXConstructorDecl>(Function)) {
// If this is a constructor, instantiate the member initializers.
InstantiateMemInitializers(Ctor, cast<CXXConstructorDecl>(PatternDecl),
Implement explicit specialization of explicitly-defaulted constructors. The general out-of-line case (including explicit instantiation mostly works except that the definition is being lost somewhere between the AST and CodeGen, so the definition is never emitted. llvm-svn: 131933
2011-05-24 07:14:04 +08:00
TemplateArgs);
[MS] Instantiate default args during instantiation of exported default ctors Summary: Replace some old code that probably pre-dated the change to delay emission of dllexported code until after the closing brace of the outermost record type. Only uninstantiated default argument expressions need to be handled now. It is enough to instantiate default argument expressions when instantiating dllexported default ctors. This also fixes some double-diagnostic issues in this area. Fixes PR31500 Reviewers: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D28274 llvm-svn: 291045
2017-01-05 09:08:22 +08:00
// If this is an MS ABI dllexport default constructor, instantiate any
// default arguments.
if (Context.getTargetInfo().getCXXABI().isMicrosoft() &&
Ctor->isDefaultConstructor()) {
InstantiateDefaultCtorDefaultArgs(*this, Ctor);
}
Implement explicit specialization of explicitly-defaulted constructors. The general out-of-line case (including explicit instantiation mostly works except that the definition is being lost somewhere between the AST and CodeGen, so the definition is never emitted. llvm-svn: 131933
2011-05-24 07:14:04 +08:00
}
// Instantiate the function body.
StmtResult Body = SubstStmt(Pattern, TemplateArgs);
if (Body.isInvalid())
Function->setInvalidDecl();
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
[VLA] Handle VLA size expression in a full-expression context. Summary: Previously the cleanups (e.g. dtor calls) are inserted into the outer scope (e.g. function body scope), instead of it's own scope. After the fix, the cleanups are inserted right after getting the size value. This fixes pr30306. Reviewers: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D24333 llvm-svn: 295123
2017-02-15 07:46:37 +08:00
// FIXME: finishing the function body while in an expression evaluation
// context seems wrong. Investigate more.
Implement explicit specialization of explicitly-defaulted constructors. The general out-of-line case (including explicit instantiation mostly works except that the definition is being lost somewhere between the AST and CodeGen, so the definition is never emitted. llvm-svn: 131933
2011-05-24 07:14:04 +08:00
ActOnFinishFunctionBody(Function, Body.get(),
/*IsInstantiation=*/true);
Implement template instantiation for DeclStmt llvm-svn: 71818
2009-05-15 08:01:03 +08:00
PR14558: Compute triviality of special members (etc) at the end of the class definition, rather than at the end of the definition of the set of nested classes. We still defer checking of the user-specified exception specification to the end of the nesting -- we can't check that until we've parsed the in-class initializers for non-static data members. llvm-svn: 169805
2012-12-11 09:14:52 +08:00
PerformDependentDiagnostics(PatternDecl, TemplateArgs);
Implement a framework for the delay of arbitrary diagnostics within templates. So delay access-control diagnostics when (for example) the target of a friend declaration is a specific specialization of a template. I was surprised to find that this was required for an access-controlled selfhost. llvm-svn: 99383
2010-03-24 13:22:00 +08:00
Emit an update record if we instantiate the definition of a function template specialization from a module. (This can also happen for function template specializations in PCHs if they're instantiated eagerly, because they're constexpr or have a deduced return type.) llvm-svn: 204547
2014-03-23 07:33:22 +08:00
if (auto *Listener = getASTMutationListener())
Listener->FunctionDefinitionInstantiated(Function);
Refactor: move loading pending instantiations from chained PCHs to a more appropriate place, so that we only ask the external source once. llvm-svn: 204535
2014-03-22 09:43:32 +08:00
PR14558: Compute triviality of special members (etc) at the end of the class definition, rather than at the end of the definition of the set of nested classes. We still defer checking of the user-specified exception specification to the end of the nesting -- we can't check that until we've parsed the in-class initializers for non-static data members. llvm-svn: 169805
2012-12-11 09:14:52 +08:00
savedContext.pop();
}
Make sure that CodeGen sees template instantiations. llvm-svn: 72433
2009-05-27 04:50:29 +08:00
DeclGroupRef DG(Function);
Consumer.HandleTopLevelDecl(DG);
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Introduce a second queue of "local" pending implicit instantiation, which are instantiations of the member functions of local classes. These implicit instantiations have to occur at the same time as---and in the same local instantiation scope as---the enclosing function, since the member functions of the local class can refer to locals within the enclosing function. This should really, really fix PR5764. llvm-svn: 93666
2010-01-17 06:29:39 +08:00
// This class may have local implicit instantiations that need to be
// instantiation within this scope.
Rename RAII objects for performing eager instantiation to have names that describe what they're for, not how they do it, and factor out a bit more common code into them. llvm-svn: 303479
2017-05-20 09:36:41 +08:00
LocalInstantiations.perform();
Introduce a second queue of "local" pending implicit instantiation, which are instantiations of the member functions of local classes. These implicit instantiations have to occur at the same time as---and in the same local instantiation scope as---the enclosing function, since the member functions of the local class can refer to locals within the enclosing function. This should really, really fix PR5764. llvm-svn: 93666
2010-01-17 06:29:39 +08:00
Scope.Exit();
Rename RAII objects for performing eager instantiation to have names that describe what they're for, not how they do it, and factor out a bit more common code into them. llvm-svn: 303479
2017-05-20 09:36:41 +08:00
GlobalInstantiations.perform();
Explicit instantiations of templates now instantiate the definitions of class members (recursively). Only member classes are actually instantiated; the instantiation logic for member functions and variables are just stubs. llvm-svn: 71713
2009-05-14 04:28:22 +08:00
}
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
VarTemplateSpecializationDecl *Sema::BuildVarTemplateInstantiation(
VarTemplateDecl *VarTemplate, VarDecl *FromVar,
const TemplateArgumentList &TemplateArgList,
const TemplateArgumentListInfo &TemplateArgsInfo,
SmallVectorImpl<TemplateArgument> &Converted,
SourceLocation PointOfInstantiation, void *InsertPos,
LateInstantiatedAttrVec *LateAttrs,
LocalInstantiationScope *StartingScope) {
if (FromVar->isInvalidDecl())
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
InstantiatingTemplate Inst(*this, PointOfInstantiation, FromVar);
Make InstantiatingTemplate depth checks clearer The bool conversion operator on InstantiatingTemplate never added value and only served to obfuscate the template instantiation routines. This replaces the conversion and its callers with an explicit isInvalid() function to make it clear what's going on at a glance. llvm-svn: 192177
2013-10-08 16:09:04 +08:00
if (Inst.isInvalid())
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
MultiLevelTemplateArgumentList TemplateArgLists;
TemplateArgLists.addOuterTemplateArguments(&TemplateArgList);
Variable templates: handle instantiation of static data member templates appropriately, especially when they appear within class templates. llvm-svn: 191548
2013-09-28 04:14:12 +08:00
// Instantiate the first declaration of the variable template: for a partial
// specialization of a static data member template, the first declaration may
// or may not be the declaration in the class; if it's in the class, we want
// to instantiate a member in the class (a declaration), and if it's outside,
// we want to instantiate a definition.
Clean up variable template handling a bit, and correct the behavior of name lookup when declaring a variable template specialization. llvm-svn: 199438
2014-01-17 07:39:20 +08:00
//
// If we're instantiating an explicitly-specialized member template or member
// partial specialization, don't do this. The member specialization completely
// replaces the original declaration in this case.
bool IsMemberSpec = false;
if (VarTemplatePartialSpecializationDecl *PartialSpec =
dyn_cast<VarTemplatePartialSpecializationDecl>(FromVar))
IsMemberSpec = PartialSpec->isMemberSpecialization();
else if (VarTemplateDecl *FromTemplate = FromVar->getDescribedVarTemplate())
IsMemberSpec = FromTemplate->isMemberSpecialization();
if (!IsMemberSpec)
FromVar = FromVar->getFirstDecl();
Variable templates: handle instantiation of static data member templates appropriately, especially when they appear within class templates. llvm-svn: 191548
2013-09-28 04:14:12 +08:00
Fix use-after-free. TemplateDeclInstantiator takes the MultiLevelArgumentList by const-ref and stores a const-ref member. Thus, we must not pass a temporary into the constructor. llvm-svn: 191665
2013-09-30 21:29:01 +08:00
MultiLevelTemplateArgumentList MultiLevelList(TemplateArgList);
TemplateDeclInstantiator Instantiator(*this, FromVar->getDeclContext(),
MultiLevelList);
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
// TODO: Set LateAttrs and StartingScope ...
return cast_or_null<VarTemplateSpecializationDecl>(
Instantiator.VisitVarTemplateSpecializationDecl(
VarTemplate, FromVar, InsertPos, TemplateArgsInfo, Converted));
}
/// \brief Instantiates a variable template specialization by completing it
/// with appropriate type information and initializer.
VarTemplateSpecializationDecl *Sema::CompleteVarTemplateSpecializationDecl(
VarTemplateSpecializationDecl *VarSpec, VarDecl *PatternDecl,
const MultiLevelTemplateArgumentList &TemplateArgs) {
// Do substitution on the type of the declaration
TypeSourceInfo *DI =
Variable templates: handle instantiation of static data member templates appropriately, especially when they appear within class templates. llvm-svn: 191548
2013-09-28 04:14:12 +08:00
SubstType(PatternDecl->getTypeSourceInfo(), TemplateArgs,
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
PatternDecl->getTypeSpecStartLoc(), PatternDecl->getDeclName());
if (!DI)
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
// Update the type of this variable template specialization.
VarSpec->setType(DI->getType());
// Instantiate the initializer.
InstantiateVariableInitializer(VarSpec, PatternDecl, TemplateArgs);
return VarSpec;
}
/// BuildVariableInstantiation - Used after a new variable has been created.
/// Sets basic variable data and decides whether to postpone the
/// variable instantiation.
void Sema::BuildVariableInstantiation(
VarDecl *NewVar, VarDecl *OldVar,
const MultiLevelTemplateArgumentList &TemplateArgs,
Switch the semantic DeclContext for a block-scope declaration of a function or variable from being the function to being the enclosing namespace scope (in C++) or the TU (in C). This allows us to fix a selection of related issues where we would build incorrect redeclaration chains for such declarations, and fail to notice type mismatches. Such declarations are put into a new IdentifierNamespace, IDNS_LocalExtern, which is only found when searching scopes, and not found when searching DeclContexts. Such a declaration is only made visible in its DeclContext if there are no non-LocalExtern declarations. llvm-svn: 191064
2013-09-20 09:15:31 +08:00
LateInstantiatedAttrVec *LateAttrs, DeclContext *Owner,
LocalInstantiationScope *StartingScope,
Refactor for clarity and simplicity. llvm-svn: 188974
2013-08-22 08:59:14 +08:00
bool InstantiatingVarTemplate) {
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
Switch the semantic DeclContext for a block-scope declaration of a function or variable from being the function to being the enclosing namespace scope (in C++) or the TU (in C). This allows us to fix a selection of related issues where we would build incorrect redeclaration chains for such declarations, and fail to notice type mismatches. Such declarations are put into a new IdentifierNamespace, IDNS_LocalExtern, which is only found when searching scopes, and not found when searching DeclContexts. Such a declaration is only made visible in its DeclContext if there are no non-LocalExtern declarations. llvm-svn: 191064
2013-09-20 09:15:31 +08:00
// If we are instantiating a local extern declaration, the
// instantiation belongs lexically to the containing function.
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
// If we are instantiating a static data member defined
// out-of-line, the instantiation will have the same lexical
// context (which will be a namespace scope) as the template.
Switch the semantic DeclContext for a block-scope declaration of a function or variable from being the function to being the enclosing namespace scope (in C++) or the TU (in C). This allows us to fix a selection of related issues where we would build incorrect redeclaration chains for such declarations, and fail to notice type mismatches. Such declarations are put into a new IdentifierNamespace, IDNS_LocalExtern, which is only found when searching scopes, and not found when searching DeclContexts. Such a declaration is only made visible in its DeclContext if there are no non-LocalExtern declarations. llvm-svn: 191064
2013-09-20 09:15:31 +08:00
if (OldVar->isLocalExternDecl()) {
NewVar->setLocalExternDecl();
NewVar->setLexicalDeclContext(Owner);
} else if (OldVar->isOutOfLine())
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
NewVar->setLexicalDeclContext(OldVar->getLexicalDeclContext());
NewVar->setTSCSpec(OldVar->getTSCSpec());
NewVar->setInitStyle(OldVar->getInitStyle());
NewVar->setCXXForRangeDecl(OldVar->isCXXForRangeDecl());
NewVar->setConstexpr(OldVar->isConstexpr());
Per latest drafting, switch to implementing init-captures as if by declaring and capturing a variable declaration, and complete the implementation of them. llvm-svn: 191605
2013-09-28 12:02:39 +08:00
NewVar->setInitCapture(OldVar->isInitCapture());
Fix implementation of C11 6.2.7/4 and C++11 [dcl.array]p3: When a local extern declaration redeclares some other entity, the type of that entity is merged with the prior type if the prior declaration is visible (in C) or is declared in the same scope (in C++). - Make LookupRedeclarationWithLinkage actually work in C++, use it in the right set of cases, and make it track whether it found a shadowed declaration. - Track whether we found a declaration in the same scope (for C++) including across serialization and template instantiation. llvm-svn: 188307
2013-08-14 02:18:50 +08:00
NewVar->setPreviousDeclInSameBlockScope(
OldVar->isPreviousDeclInSameBlockScope());
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
NewVar->setAccess(OldVar->getAccess());
Revert change accidentally committed in r191150. llvm-svn: 191237
2013-09-24 07:12:22 +08:00
if (!OldVar->isStaticDataMember()) {
A decl never becomes unused. Make that explicit in the API. llvm-svn: 193248
2013-10-24 00:46:34 +08:00
if (OldVar->isUsed(false))
NewVar->setIsUsed();
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
NewVar->setReferenced(OldVar->isReferenced());
}
InstantiateAttrs(TemplateArgs, OldVar, NewVar, LateAttrs, StartingScope);
Switch the semantic DeclContext for a block-scope declaration of a function or variable from being the function to being the enclosing namespace scope (in C++) or the TU (in C). This allows us to fix a selection of related issues where we would build incorrect redeclaration chains for such declarations, and fail to notice type mismatches. Such declarations are put into a new IdentifierNamespace, IDNS_LocalExtern, which is only found when searching scopes, and not found when searching DeclContexts. Such a declaration is only made visible in its DeclContext if there are no non-LocalExtern declarations. llvm-svn: 191064
2013-09-20 09:15:31 +08:00
LookupResult Previous(
*this, NewVar->getDeclName(), NewVar->getLocation(),
NewVar->isLocalExternDecl() ? Sema::LookupRedeclarationWithLinkage
: Sema::LookupOrdinaryName,
Sema::ForRedeclaration);
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
[Sema] Don't look for the instantiation of a local extern decl in a different dependent context that the one we are instantiating, otherwise there will be an assertion. rdar://15464547 llvm-svn: 195828
2013-11-27 16:34:14 +08:00
if (NewVar->isLocalExternDecl() && OldVar->getPreviousDecl() &&
(!OldVar->getPreviousDecl()->getDeclContext()->isDependentContext() ||
OldVar->getPreviousDecl()->getDeclContext()==OldVar->getDeclContext())) {
Fix implementation of C11 6.2.7/4 and C++11 [dcl.array]p3: When a local extern declaration redeclares some other entity, the type of that entity is merged with the prior type if the prior declaration is visible (in C) or is declared in the same scope (in C++). - Make LookupRedeclarationWithLinkage actually work in C++, use it in the right set of cases, and make it track whether it found a shadowed declaration. - Track whether we found a declaration in the same scope (for C++) including across serialization and template instantiation. llvm-svn: 188307
2013-08-14 02:18:50 +08:00
// We have a previous declaration. Use that one, so we merge with the
// right type.
if (NamedDecl *NewPrev = FindInstantiatedDecl(
NewVar->getLocation(), OldVar->getPreviousDecl(), TemplateArgs))
Previous.addDecl(NewPrev);
} else if (!isa<VarTemplateSpecializationDecl>(NewVar) &&
OldVar->hasLinkage())
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
LookupQualifiedName(Previous, NewVar->getDeclContext(), false);
Refactor for clarity and simplicity. llvm-svn: 188974
2013-08-22 08:59:14 +08:00
CheckVariableDeclaration(NewVar, Previous);
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
Switch the semantic DeclContext for a block-scope declaration of a function or variable from being the function to being the enclosing namespace scope (in C++) or the TU (in C). This allows us to fix a selection of related issues where we would build incorrect redeclaration chains for such declarations, and fail to notice type mismatches. Such declarations are put into a new IdentifierNamespace, IDNS_LocalExtern, which is only found when searching scopes, and not found when searching DeclContexts. Such a declaration is only made visible in its DeclContext if there are no non-LocalExtern declarations. llvm-svn: 191064
2013-09-20 09:15:31 +08:00
if (!InstantiatingVarTemplate) {
NewVar->getLexicalDeclContext()->addHiddenDecl(NewVar);
if (!NewVar->isLocalExternDecl() || !NewVar->getPreviousDecl())
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
NewVar->getDeclContext()->makeDeclVisibleInContext(NewVar);
Switch the semantic DeclContext for a block-scope declaration of a function or variable from being the function to being the enclosing namespace scope (in C++) or the TU (in C). This allows us to fix a selection of related issues where we would build incorrect redeclaration chains for such declarations, and fail to notice type mismatches. Such declarations are put into a new IdentifierNamespace, IDNS_LocalExtern, which is only found when searching scopes, and not found when searching DeclContexts. Such a declaration is only made visible in its DeclContext if there are no non-LocalExtern declarations. llvm-svn: 191064
2013-09-20 09:15:31 +08:00
}
if (!OldVar->isOutOfLine()) {
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
if (NewVar->getDeclContext()->isFunctionOrMethod())
CurrentInstantiationScope->InstantiatedLocal(OldVar, NewVar);
}
// Link instantiations of static data members back to the template from
// which they were instantiated.
Refactor for clarity and simplicity. llvm-svn: 188974
2013-08-22 08:59:14 +08:00
if (NewVar->isStaticDataMember() && !InstantiatingVarTemplate)
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
NewVar->setInstantiationOfStaticDataMember(OldVar,
TSK_ImplicitInstantiation);
Sema: Propagate the mangling number into instantiations We would lose track of the mangling number assigned to the original declaration which would cause us to create manglings that didn't match the Itanium C++ specification. e.g. Two static fields with the same name inside of a function template would receive the same mangling with LLVM fixing up the second field so they wouldn't collide. This would create an incompatibility with other compilers following the Itanium ABI. I've confirmed that the new mangling is identical to the ones generated by icc and gcc. N.B. This was uncovered while working on Microsoft mangler. llvm-svn: 196368
2013-12-04 17:01:55 +08:00
// Forward the mangling number from the template to the instantiated decl.
Context.setManglingNumber(NewVar, Context.getManglingNumber(OldVar));
[-cxx-abi microsoft] Implement local manglings accurately Summary: The MSVC ABI appears to mangle the lexical scope into the names of statics. Specifically, a counter is incremented whenever a scope is entered where things can be declared in such a way that an ambiguity can arise. For example, a class scope inside of a class scope doesn't do anything interesting because the nested class cannot collide with another nested class. There are problems with this scheme: - It is unreliable. The counter is only incremented when a previously never encountered scope is entered. There are cases where this will cause ambiguity amongst declarations that have the same name where one was introduced in a deep scope while the other was introduced right after in the previous lexical scope. - It is wasteful. Statements like: {{{{{{{ static int foo = a; }}}}}}} will make the mangling of "foo" larger than it need be because the scope counter has been incremented many times. Because of these problems, and practical implementation concerns. We choose not to implement this scheme if the local static or local type isn't visible. The mangling of these declarations will look very similar but the numbering will make far more sense, this scheme is lifted from the Itanium ABI implementation. Reviewers: rsmith, doug.gregor, rnk, eli.friedman, cdavis5x Reviewed By: rnk CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2953 llvm-svn: 202951
2014-03-05 16:57:59 +08:00
Context.setStaticLocalNumber(NewVar, Context.getStaticLocalNumber(OldVar));
Sema: Propagate the mangling number into instantiations We would lose track of the mangling number assigned to the original declaration which would cause us to create manglings that didn't match the Itanium C++ specification. e.g. Two static fields with the same name inside of a function template would receive the same mangling with LLVM fixing up the second field so they wouldn't collide. This would create an incompatibility with other compilers following the Itanium ABI. I've confirmed that the new mangling is identical to the ones generated by icc and gcc. N.B. This was uncovered while working on Microsoft mangler. llvm-svn: 196368
2013-12-04 17:01:55 +08:00
Implement C++17 P0386R2, inline variables. (The 'inline' specifier gives a variable weak discardable linkage and partially-ordered initialization, and is implied for constexpr static data members.) llvm-svn: 273754
2016-06-25 08:15:56 +08:00
// Delay instantiation of the initializer for variable templates or inline
// static data members until a definition of the variable is needed. We need
// it right away if the type contains 'auto'.
PR19152: If a variable template's type involves 'auto', instantiate the initializer with the variable in order to determine the type. llvm-svn: 204015
2014-03-16 09:00:40 +08:00
if ((!isa<VarTemplateSpecializationDecl>(NewVar) &&
Implement C++17 P0386R2, inline variables. (The 'inline' specifier gives a variable weak discardable linkage and partially-ordered initialization, and is implied for constexpr static data members.) llvm-svn: 273754
2016-06-25 08:15:56 +08:00
!InstantiatingVarTemplate &&
!(OldVar->isInline() && OldVar->isThisDeclarationADefinition())) ||
PR19152: If a variable template's type involves 'auto', instantiate the initializer with the variable in order to determine the type. llvm-svn: 204015
2014-03-16 09:00:40 +08:00
NewVar->getType()->isUndeducedType())
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
InstantiateVariableInitializer(NewVar, OldVar, TemplateArgs);
// Diagnose unused local variables with dependent types, where the diagnostic
// will have been deferred.
if (!NewVar->isInvalidDecl() &&
Add -Wunused-local-typedef, a warning that finds unused local typedefs. The warning warns on TypedefNameDecls -- typedefs and C++11 using aliases -- that are !isReferenced(). Since the isReferenced() bit on TypedefNameDecls wasn't used for anything before this warning it wasn't always set correctly, so this patch also adds a few missing MarkAnyDeclReferenced() calls in various places for TypedefNameDecls. This is made a bit complicated due to local typedefs possibly being used only after their local scope has closed. Consider: template <class T> void template_fun(T t) { typename T::Foo s3foo; // YYY (void)s3foo; } void template_fun_user() { struct Local { typedef int Foo; // XXX } p; template_fun(p); } Here the typedef in XXX is only used at end-of-translation unit, when YYY in template_fun() gets instantiated. To handle this, typedefs that are unused when their scope exits are added to a set of potentially unused typedefs, and that set gets checked at end-of-TU. Typedefs that are still unused at that point then get warned on. There's also serialization code for this set, so that the warning works with precompiled headers and modules. For modules, the warning is emitted when the module is built, for precompiled headers each time the header gets used. Finally, consider a function using C++14 auto return types to return a local type defined in a header: auto f() { struct S { typedef int a; }; return S(); } Here, the typedef escapes its local scope and could be used by only some translation units including the header. To not warn on this, add a RecursiveASTVisitor that marks all delcs on local types returned from auto functions as referenced. (Except if it's a function with internal linkage, or the decls are private and the local type has no friends -- in these cases, it _is_ safe to warn.) Several of the included testcases (most of the interesting ones) were provided by Richard Smith. (gcc's spelling -Wunused-local-typedefs is supported as an alias for this warning.) llvm-svn: 217298
2014-09-06 09:25:55 +08:00
NewVar->getDeclContext()->isFunctionOrMethod() &&
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
OldVar->getType()->isDependentType())
DiagnoseUnusedDecl(NewVar);
}
/// \brief Instantiate the initializer of a variable.
void Sema::InstantiateVariableInitializer(
VarDecl *Var, VarDecl *OldVar,
const MultiLevelTemplateArgumentList &TemplateArgs) {
Implement C++17 P0386R2, inline variables. (The 'inline' specifier gives a variable weak discardable linkage and partially-ordered initialization, and is implied for constexpr static data members.) llvm-svn: 273754
2016-06-25 08:15:56 +08:00
// We propagate the 'inline' flag with the initializer, because it
// would otherwise imply that the variable is a definition for a
// non-static data member.
if (OldVar->isInlineSpecified())
Var->setInlineSpecified();
else if (OldVar->isInline())
Var->setImplicitlyInline();
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
if (OldVar->getInit()) {
if (Var->isStaticDataMember() && !OldVar->isOutOfLine())
[NFC, Scoped Enum] Convert Sema::ExpressionEvaluationContext into a scoped Enum - also replace direct equality checks against the ConstantEvaluated enumerator with isConstantEvaluted(), in anticipation of adding finer granularity to the various ConstantEvaluated contexts and reinstating certain restrictions on where lambda expressions can occur in C++17. - update the clang tablegen backend that uses these Enumerators, and add the relevant scope where needed. llvm-svn: 299316
2017-04-02 05:30:49 +08:00
PushExpressionEvaluationContext(
Sema::ExpressionEvaluationContext::ConstantEvaluated, OldVar);
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
else
[NFC, Scoped Enum] Convert Sema::ExpressionEvaluationContext into a scoped Enum - also replace direct equality checks against the ConstantEvaluated enumerator with isConstantEvaluted(), in anticipation of adding finer granularity to the various ConstantEvaluated contexts and reinstating certain restrictions on where lambda expressions can occur in C++17. - update the clang tablegen backend that uses these Enumerators, and add the relevant scope where needed. llvm-svn: 299316
2017-04-02 05:30:49 +08:00
PushExpressionEvaluationContext(
Sema::ExpressionEvaluationContext::PotentiallyEvaluated, OldVar);
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
// Instantiate the initializer.
[Sema] Fix a crash that occurs when a variable template is initialized with a generic lambda. This patch fixes Sema::InstantiateVariableInitializer to switch to the context of the variable before instantiating its initializer, which is necessary to set the correct type for VarTemplateSpecializationDecl. This is the first part of the patch that was reviewed here: http://reviews.llvm.org/D19175 rdar://problem/23440346 llvm-svn: 267956
2016-04-29 07:50:12 +08:00
ExprResult Init;
{
ContextRAII SwitchContext(*this, Var->getDeclContext());
Init = SubstInitializer(OldVar->getInit(), TemplateArgs,
OldVar->getInitStyle() == VarDecl::CallInit);
}
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
if (!Init.isInvalid()) {
Improve checking for dynamic initializers of dllimport fields in template instantiation We would previously assert if the initializer was dependent. I also think that checking isConstantInitializer is more correct here than checkInitIsICE. llvm-svn: 210505
2014-06-10 08:55:51 +08:00
Expr *InitExpr = Init.get();
PR20256: don't accidentally instantiate non-dependent default-initialization as value-initialization. llvm-svn: 212764
2014-07-11 04:53:43 +08:00
if (Var->hasAttr<DLLImportAttr>() &&
(!InitExpr ||
!InitExpr->isConstantInitializer(getASTContext(), false))) {
Improve checking for dynamic initializers of dllimport fields in template instantiation We would previously assert if the initializer was dependent. I also think that checking isConstantInitializer is more correct here than checkInitIsICE. llvm-svn: 210505
2014-06-10 08:55:51 +08:00
// Do not dynamically initialize dllimport variables.
} else if (InitExpr) {
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
bool DirectInit = OldVar->isDirectInit();
Remove redundant passing around of a "ContainsAutoType" flag. This flag serves no purpose other than to prevent us walking through a type to check whether it contains an 'auto' specifier; this duplication of information is error-prone, does not appear to provide any performance benefit, and will become less practical once we support C++1z deduced class template types and eventually constrained types from the Concepts TS. No functionality change intended. llvm-svn: 291737
2017-01-12 10:27:38 +08:00
AddInitializerToDecl(Var, InitExpr, DirectInit);
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
} else
Remove redundant passing around of a "ContainsAutoType" flag. This flag serves no purpose other than to prevent us walking through a type to check whether it contains an 'auto' specifier; this duplication of information is error-prone, does not appear to provide any performance benefit, and will become less practical once we support C++1z deduced class template types and eventually constrained types from the Concepts TS. No functionality change intended. llvm-svn: 291737
2017-01-12 10:27:38 +08:00
ActOnUninitializedDecl(Var);
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
} else {
// FIXME: Not too happy about invalidating the declaration
// because of a bogus initializer.
Var->setInvalidDecl();
}
PopExpressionEvaluationContext();
PR12298 et al: don't recursively instantiate a template specialization from within the instantiation of that same specialization. This could previously happen for eagerly-instantiated function templates, variable templates, exception specifications, default arguments, and a handful of other cases. We still have an issue here for default template arguments that recursively make use of themselves and likewise for substitution into the type of a non-type template parameter, but in those cases we're producing a different entity each time, so they should instead be caught by the instantiation depth limit. However, currently we will typically run out of stack before we reach it. :( llvm-svn: 280190
2016-08-31 10:15:21 +08:00
} else {
if (Var->isStaticDataMember()) {
if (!Var->isOutOfLine())
return;
// If the declaration inside the class had an initializer, don't add
// another one to the out-of-line definition.
if (OldVar->getFirstDecl()->hasInit())
return;
}
// We'll add an initializer to a for-range declaration later.
if (Var->isCXXForRangeDecl())
return;
Remove redundant passing around of a "ContainsAutoType" flag. This flag serves no purpose other than to prevent us walking through a type to check whether it contains an 'auto' specifier; this duplication of information is error-prone, does not appear to provide any performance benefit, and will become less practical once we support C++1z deduced class template types and eventually constrained types from the Concepts TS. No functionality change intended. llvm-svn: 291737
2017-01-12 10:27:38 +08:00
ActOnUninitializedDecl(Var);
PR12298 et al: don't recursively instantiate a template specialization from within the instantiation of that same specialization. This could previously happen for eagerly-instantiated function templates, variable templates, exception specifications, default arguments, and a handful of other cases. We still have an issue here for default template arguments that recursively make use of themselves and likewise for substitution into the type of a non-type template parameter, but in those cases we're producing a different entity each time, so they should instead be caught by the instantiation depth limit. However, currently we will typically run out of stack before we reach it. :( llvm-svn: 280190
2016-08-31 10:15:21 +08:00
}
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
}
Explicit instantiations of templates now instantiate the definitions of class members (recursively). Only member classes are actually instantiated; the instantiation logic for member functions and variables are just stubs. llvm-svn: 71713
2009-05-14 04:28:22 +08:00
/// \brief Instantiate the definition of the given variable from its
/// template.
///
Template instantiation for static data members that are defined out-of-line. Note that this also fixes a bug that affects non-template code, where we were not treating out-of-line static data members are "file-scope" variables, and therefore not checking their initializers. llvm-svn: 77002
2009-07-25 04:34:43 +08:00
/// \param PointOfInstantiation the point at which the instantiation was
/// required. Note that this is not precisely a "point of instantiation"
/// for the function, but it's close.
///
/// \param Var the already-instantiated declaration of a static member
/// variable of a class template specialization.
///
/// \param Recursive if true, recursively instantiates any functions that
/// are required by this instantiation.
Diagnose explicit instantiations of function templates and member functions/static data members of class template specializations that do not have definitions. This is the latter part of [temp.explicit]p4; the former part still needs more testing. llvm-svn: 84182
2009-10-15 22:05:49 +08:00
///
/// \param DefinitionRequired if true, then we are performing an explicit
/// instantiation where an out-of-line definition of the member variable
/// is required. Complain if there is no such definition.
Template instantiation for static data members that are defined out-of-line. Note that this also fixes a bug that affects non-template code, where we were not treating out-of-line static data members are "file-scope" variables, and therefore not checking their initializers. llvm-svn: 77002
2009-07-25 04:34:43 +08:00
void Sema::InstantiateStaticDataMemberDefinition(
SourceLocation PointOfInstantiation,
VarDecl *Var,
Diagnose explicit instantiations of function templates and member functions/static data members of class template specializations that do not have definitions. This is the latter part of [temp.explicit]p4; the former part still needs more testing. llvm-svn: 84182
2009-10-15 22:05:49 +08:00
bool Recursive,
bool DefinitionRequired) {
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
InstantiateVariableDefinition(PointOfInstantiation, Var, Recursive,
DefinitionRequired);
}
void Sema::InstantiateVariableDefinition(SourceLocation PointOfInstantiation,
VarDecl *Var, bool Recursive,
Warn if function or variable cannot be implicitly instantiated With this patch compiler emits warning if it tries to make implicit instantiation of a template but cannot find the template definition. The warning can be suppressed by explicit instantiation declaration or by command line options -Wundefined-var-template and -Wundefined-func-template. The implementation follows the discussion of http://reviews.llvm.org/D12326. Differential Revision: http://reviews.llvm.org/D16396 llvm-svn: 266719
2016-04-19 14:19:52 +08:00
bool DefinitionRequired, bool AtEndOfTU) {
Template instantiation for static data members that are defined out-of-line. Note that this also fixes a bug that affects non-template code, where we were not treating out-of-line static data members are "file-scope" variables, and therefore not checking their initializers. llvm-svn: 77002
2009-07-25 04:34:43 +08:00
if (Var->isInvalidDecl())
return;
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
VarTemplateSpecializationDecl *VarSpec =
dyn_cast<VarTemplateSpecializationDecl>(Var);
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
VarDecl *PatternDecl = nullptr, *Def = nullptr;
Variable templates: handle instantiation of static data member templates appropriately, especially when they appear within class templates. llvm-svn: 191548
2013-09-28 04:14:12 +08:00
MultiLevelTemplateArgumentList TemplateArgs =
getTemplateInstantiationArgs(Var);
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
if (VarSpec) {
Variable templates: handle instantiation of static data member templates appropriately, especially when they appear within class templates. llvm-svn: 191548
2013-09-28 04:14:12 +08:00
// If this is a variable template specialization, make sure that it is
// non-dependent, then find its instantiation pattern.
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
bool InstantiationDependent = false;
assert(!TemplateSpecializationType::anyDependentTemplateArguments(
VarSpec->getTemplateArgsInfo(), InstantiationDependent) &&
"Only instantiate variable template specializations that are "
"not type-dependent");
Fixing commit r187768: Moved diagnosis of forward declarations of variable templates from Parser to Sema. llvm-svn: 187770
2013-08-06 11:57:41 +08:00
(void)InstantiationDependent;
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
Variable templates: handle instantiation of static data member templates appropriately, especially when they appear within class templates. llvm-svn: 191548
2013-09-28 04:14:12 +08:00
// Find the variable initialization that we'll be substituting. If the
// pattern was instantiated from a member template, look back further to
// find the real pattern.
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
assert(VarSpec->getSpecializedTemplate() &&
"Specialization without specialized template?");
llvm::PointerUnion<VarTemplateDecl *,
VarTemplatePartialSpecializationDecl *> PatternPtr =
VarSpec->getSpecializedTemplateOrPartial();
variable templates updated for PCH serialization... Still working on test cases... llvm-svn: 188249
2013-08-13 10:02:26 +08:00
if (PatternPtr.is<VarTemplatePartialSpecializationDecl *>()) {
Variable templates: handle instantiation of static data member templates appropriately, especially when they appear within class templates. llvm-svn: 191548
2013-09-28 04:14:12 +08:00
VarTemplatePartialSpecializationDecl *Tmpl =
PatternPtr.get<VarTemplatePartialSpecializationDecl *>();
while (VarTemplatePartialSpecializationDecl *From =
Tmpl->getInstantiatedFromMember()) {
if (Tmpl->isMemberSpecialization())
break;
variable templates updated for PCH serialization... Still working on test cases... llvm-svn: 188249
2013-08-13 10:02:26 +08:00
Variable templates: handle instantiation of static data member templates appropriately, especially when they appear within class templates. llvm-svn: 191548
2013-09-28 04:14:12 +08:00
Tmpl = From;
}
PatternDecl = Tmpl;
variable templates updated for PCH serialization... Still working on test cases... llvm-svn: 188249
2013-08-13 10:02:26 +08:00
} else {
Variable templates: handle instantiation of static data member templates appropriately, especially when they appear within class templates. llvm-svn: 191548
2013-09-28 04:14:12 +08:00
VarTemplateDecl *Tmpl = PatternPtr.get<VarTemplateDecl *>();
while (VarTemplateDecl *From =
Tmpl->getInstantiatedFromMemberTemplate()) {
if (Tmpl->isMemberSpecialization())
break;
Tmpl = From;
}
PatternDecl = Tmpl->getTemplatedDecl();
}
// If this is a static data member template, there might be an
// uninstantiated initializer on the declaration. If so, instantiate
// it now.
if (PatternDecl->isStaticDataMember() &&
Rename some functions for consistency. Every other function in Redeclarable.h was using Decl instead of Declaration. llvm-svn: 192900
2013-10-17 23:37:26 +08:00
(PatternDecl = PatternDecl->getFirstDecl())->hasInit() &&
Variable templates: handle instantiation of static data member templates appropriately, especially when they appear within class templates. llvm-svn: 191548
2013-09-28 04:14:12 +08:00
!Var->hasInit()) {
// FIXME: Factor out the duplicated instantiation context setup/tear down
// code here.
InstantiatingTemplate Inst(*this, PointOfInstantiation, Var);
PR12298 et al: don't recursively instantiate a template specialization from within the instantiation of that same specialization. This could previously happen for eagerly-instantiated function templates, variable templates, exception specifications, default arguments, and a handful of other cases. We still have an issue here for default template arguments that recursively make use of themselves and likewise for substitution into the type of a non-type template parameter, but in those cases we're producing a different entity each time, so they should instead be caught by the instantiation depth limit. However, currently we will typically run out of stack before we reach it. :( llvm-svn: 280190
2016-08-31 10:15:21 +08:00
if (Inst.isInvalid() || Inst.isAlreadyInstantiating())
Variable templates: handle instantiation of static data member templates appropriately, especially when they appear within class templates. llvm-svn: 191548
2013-09-28 04:14:12 +08:00
return;
Produce better pretty stack traces from crashes in template instantiation: add pretty stack trace entries for all cases where we instantiate the definition of something, and include the fully-qualified name with template arguments in the name of the instantiated entity. llvm-svn: 270904
2016-05-27 04:23:13 +08:00
PrettyDeclStackTraceEntry CrashInfo(*this, Var, SourceLocation(),
"instantiating variable initializer");
Variable templates: handle instantiation of static data member templates appropriately, especially when they appear within class templates. llvm-svn: 191548
2013-09-28 04:14:12 +08:00
Reinstate r284008 reverted in r284081, with two fixes: 1) Merge and demote variable definitions when we find a redefinition in MergeVarDecls, not only when we find one in AddInitializerToDecl (we only reach the second case if it's the addition of the initializer itself that converts an existing declaration into a definition). 2) When rebuilding a redeclaration chain for a variable, if we merge two definitions together, mark the definitions as merged so the retained definition is made visible whenever the demoted definition would have been. Original commit message (from r283882): [modules] PR28752: Do not instantiate variable declarations which are not visible. Original patch by Vassil Vassilev! Changes listed above are mine. llvm-svn: 284284
2016-10-15 05:41:24 +08:00
// The instantiation is visible here, even if it was first declared in an
// unimported module.
Var->setHidden(false);
Variable templates: handle instantiation of static data member templates appropriately, especially when they appear within class templates. llvm-svn: 191548
2013-09-28 04:14:12 +08:00
// If we're performing recursive template instantiation, create our own
// queue of pending implicit instantiations that we will instantiate
// later, while we're still within our own instantiation context.
Rename RAII objects for performing eager instantiation to have names that describe what they're for, not how they do it, and factor out a bit more common code into them. llvm-svn: 303479
2017-05-20 09:36:41 +08:00
GlobalEagerInstantiationScope GlobalInstantiations(*this,
/*Enabled=*/Recursive);
Variable templates: handle instantiation of static data member templates appropriately, especially when they appear within class templates. llvm-svn: 191548
2013-09-28 04:14:12 +08:00
LocalInstantiationScope Local(*this);
Rename RAII objects for performing eager instantiation to have names that describe what they're for, not how they do it, and factor out a bit more common code into them. llvm-svn: 303479
2017-05-20 09:36:41 +08:00
LocalEagerInstantiationScope LocalInstantiations(*this);
Variable templates: handle instantiation of static data member templates appropriately, especially when they appear within class templates. llvm-svn: 191548
2013-09-28 04:14:12 +08:00
// Enter the scope of this instantiation. We don't use
// PushDeclContext because we don't have a scope.
ContextRAII PreviousContext(*this, Var->getDeclContext());
InstantiateVariableInitializer(Var, PatternDecl, TemplateArgs);
PreviousContext.pop();
// FIXME: Need to inform the ASTConsumer that we instantiated the
// initializer?
// This variable may have local implicit instantiations that need to be
// instantiated within this scope.
Rename RAII objects for performing eager instantiation to have names that describe what they're for, not how they do it, and factor out a bit more common code into them. llvm-svn: 303479
2017-05-20 09:36:41 +08:00
LocalInstantiations.perform();
Variable templates: handle instantiation of static data member templates appropriately, especially when they appear within class templates. llvm-svn: 191548
2013-09-28 04:14:12 +08:00
Local.Exit();
Rename RAII objects for performing eager instantiation to have names that describe what they're for, not how they do it, and factor out a bit more common code into them. llvm-svn: 303479
2017-05-20 09:36:41 +08:00
GlobalInstantiations.perform();
variable templates updated for PCH serialization... Still working on test cases... llvm-svn: 188249
2013-08-13 10:02:26 +08:00
}
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
Variable templates: handle instantiation of static data member templates appropriately, especially when they appear within class templates. llvm-svn: 191548
2013-09-28 04:14:12 +08:00
// Find actual definition
Def = PatternDecl->getDefinition(getASTContext());
} else {
// If this is a static data member, find its out-of-line definition.
assert(Var->isStaticDataMember() && "not a static data member?");
PatternDecl = Var->getInstantiatedFromStaticDataMember();
assert(PatternDecl && "data member was not instantiated from a template?");
assert(PatternDecl->isStaticDataMember() && "not a static data member?");
Implement C++17 P0386R2, inline variables. (The 'inline' specifier gives a variable weak discardable linkage and partially-ordered initialization, and is implied for constexpr static data members.) llvm-svn: 273754
2016-06-25 08:15:56 +08:00
Def = PatternDecl->getDefinition();
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
}
Reinstate r284008 reverted in r284081, with two fixes: 1) Merge and demote variable definitions when we find a redefinition in MergeVarDecls, not only when we find one in AddInitializerToDecl (we only reach the second case if it's the addition of the initializer itself that converts an existing declaration into a definition). 2) When rebuilding a redeclaration chain for a variable, if we merge two definitions together, mark the definitions as merged so the retained definition is made visible whenever the demoted definition would have been. Original commit message (from r283882): [modules] PR28752: Do not instantiate variable declarations which are not visible. Original patch by Vassil Vassilev! Changes listed above are mine. llvm-svn: 284284
2016-10-15 05:41:24 +08:00
TemplateSpecializationKind TSK = Var->getTemplateSpecializationKind();
[modules] Enforce the rules that an explicit or partial specialization must be declared before it is used. Because we don't use normal name lookup to find these, the normal code to filter out non-visible names from name lookup results does not apply. llvm-svn: 268585
2016-05-05 08:56:12 +08:00
Variable templates: handle instantiation of static data member templates appropriately, especially when they appear within class templates. llvm-svn: 191548
2013-09-28 04:14:12 +08:00
// If we don't have a definition of the variable template, we won't perform
// any instantiation. Rather, we rely on the user to instantiate this
// definition (or provide a specialization for it) in another translation
// unit.
Reinstate r284008 reverted in r284081, with two fixes: 1) Merge and demote variable definitions when we find a redefinition in MergeVarDecls, not only when we find one in AddInitializerToDecl (we only reach the second case if it's the addition of the initializer itself that converts an existing declaration into a definition). 2) When rebuilding a redeclaration chain for a variable, if we merge two definitions together, mark the definitions as merged so the retained definition is made visible whenever the demoted definition would have been. Original commit message (from r283882): [modules] PR28752: Do not instantiate variable declarations which are not visible. Original patch by Vassil Vassilev! Changes listed above are mine. llvm-svn: 284284
2016-10-15 05:41:24 +08:00
if (!Def && !DefinitionRequired) {
if (TSK == TSK_ExplicitInstantiationDefinition) {
Rename *PendingImplicitInstantiations to *PendingInstantiations. No functionality changed. llvm-svn: 112040
2010-08-25 16:44:16 +08:00
PendingInstantiations.push_back(
Support explicit instantiation of function templates and members of class templates when only the declaration is in scope. This requires deferring the instantiation to be lazy, and ensuring the definition is required for that translation unit. We re-use the existing pending instantiation queue, previously only used to track implicit instantiations which were required to be lazy. Fixes PR7979. A subsequent change will rename *PendingImplicitInstantiations to *PendingInstatiations for clarity given its broader role. llvm-svn: 112037
2010-08-25 16:27:02 +08:00
std::make_pair(Var, PointOfInstantiation));
Reinstate r284008 reverted in r284081, with two fixes: 1) Merge and demote variable definitions when we find a redefinition in MergeVarDecls, not only when we find one in AddInitializerToDecl (we only reach the second case if it's the addition of the initializer itself that converts an existing declaration into a definition). 2) When rebuilding a redeclaration chain for a variable, if we merge two definitions together, mark the definitions as merged so the retained definition is made visible whenever the demoted definition would have been. Original commit message (from r283882): [modules] PR28752: Do not instantiate variable declarations which are not visible. Original patch by Vassil Vassilev! Changes listed above are mine. llvm-svn: 284284
2016-10-15 05:41:24 +08:00
} else if (TSK == TSK_ImplicitInstantiation) {
Warn if function or variable cannot be implicitly instantiated With this patch compiler emits warning if it tries to make implicit instantiation of a template but cannot find the template definition. The warning can be suppressed by explicit instantiation declaration or by command line options -Wundefined-var-template and -Wundefined-func-template. The implementation follows the discussion of http://reviews.llvm.org/D12326. Differential Revision: http://reviews.llvm.org/D16396 llvm-svn: 266719
2016-04-19 14:19:52 +08:00
// Warn about missing definition at the end of translation unit.
if (AtEndOfTU && !getDiagnostics().hasErrorOccurred()) {
Diag(PointOfInstantiation, diag::warn_var_template_missing)
<< Var;
Diag(PatternDecl->getLocation(), diag::note_forward_template_decl);
if (getLangOpts().CPlusPlus11)
Diag(PointOfInstantiation, diag::note_inst_declaration_hint) << Var;
}
Reinstate r284008 reverted in r284081, with two fixes: 1) Merge and demote variable definitions when we find a redefinition in MergeVarDecls, not only when we find one in AddInitializerToDecl (we only reach the second case if it's the addition of the initializer itself that converts an existing declaration into a definition). 2) When rebuilding a redeclaration chain for a variable, if we merge two definitions together, mark the definitions as merged so the retained definition is made visible whenever the demoted definition would have been. Original commit message (from r283882): [modules] PR28752: Do not instantiate variable declarations which are not visible. Original patch by Vassil Vassilev! Changes listed above are mine. llvm-svn: 284284
2016-10-15 05:41:24 +08:00
return;
Support explicit instantiation of function templates and members of class templates when only the declaration is in scope. This requires deferring the instantiation to be lazy, and ensuring the definition is required for that translation unit. We re-use the existing pending instantiation queue, previously only used to track implicit instantiations which were required to be lazy. Fixes PR7979. A subsequent change will rename *PendingImplicitInstantiations to *PendingInstatiations for clarity given its broader role. llvm-svn: 112037
2010-08-25 16:27:02 +08:00
}
Revert r284008. This is us to fail to instantiate static data members in some cases. I'm working on reducing a testcase. llvm-svn: 284081
2016-10-13 07:29:02 +08:00
}
Reinstate r283887 and r283882. Original message: "[modules] PR28752: Do not instantiate variable declarations which are not visible. https://reviews.llvm.org/D24508 Patch developed in collaboration with Richard Smith!" llvm-svn: 284008
2016-10-12 19:57:08 +08:00
Reinstate r284008 reverted in r284081, with two fixes: 1) Merge and demote variable definitions when we find a redefinition in MergeVarDecls, not only when we find one in AddInitializerToDecl (we only reach the second case if it's the addition of the initializer itself that converts an existing declaration into a definition). 2) When rebuilding a redeclaration chain for a variable, if we merge two definitions together, mark the definitions as merged so the retained definition is made visible whenever the demoted definition would have been. Original commit message (from r283882): [modules] PR28752: Do not instantiate variable declarations which are not visible. Original patch by Vassil Vassilev! Changes listed above are mine. llvm-svn: 284284
2016-10-15 05:41:24 +08:00
// FIXME: We need to track the instantiation stack in order to know which
// definitions should be visible within this instantiation.
// FIXME: Produce diagnostics when Var->getInstantiatedFromStaticDataMember().
if (DiagnoseUninstantiableTemplate(PointOfInstantiation, Var,
/*InstantiatedFromMember*/false,
PatternDecl, Def, TSK,
/*Complain*/DefinitionRequired))
return;
Fix a small difference in sema and codegen views of what needs to be output. In the included testcase, soma thinks that we already have a definition after we see the out of line decl. Codegen puts it in a deferred list, to be output if a use is seen. This would break when we saw an explicit template instantiation definition, since codegen would not be notified. This patch adds a method to the consumer interface so that soma can notify codegen that this decl is now required. llvm-svn: 152024
2012-03-05 18:54:55 +08:00
For instantiations of static data members of class templates, keep track of the kind of specialization or instantiation. Also, check the scope of the specialization and ensure that a specialization declaration without an initializer is not a definition. llvm-svn: 83533
2009-10-08 15:24:58 +08:00
// Never instantiate an explicit specialization.
Fix a small difference in sema and codegen views of what needs to be output. In the included testcase, soma thinks that we already have a definition after we see the out of line decl. Codegen puts it in a deferred list, to be output if a use is seen. This would break when we saw an explicit template instantiation definition, since codegen would not be notified. This patch adds a method to the consumer interface so that soma can notify codegen that this decl is now required. llvm-svn: 152024
2012-03-05 18:54:55 +08:00
if (TSK == TSK_ExplicitSpecialization)
For instantiations of static data members of class templates, keep track of the kind of specialization or instantiation. Also, check the scope of the specialization and ensure that a specialization declaration without an initializer is not a definition. llvm-svn: 83533
2009-10-08 15:24:58 +08:00
return;
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
// C++11 [temp.explicit]p10:
// Except for inline functions, [...] explicit instantiation declarations
// have the effect of suppressing the implicit instantiation of the entity
// to which they refer.
Fix a small difference in sema and codegen views of what needs to be output. In the included testcase, soma thinks that we already have a definition after we see the out of line decl. Codegen puts it in a deferred list, to be output if a use is seen. This would break when we saw an explicit template instantiation definition, since codegen would not be notified. This patch adds a method to the consumer interface so that soma can notify codegen that this decl is now required. llvm-svn: 152024
2012-03-05 18:54:55 +08:00
if (TSK == TSK_ExplicitInstantiationDeclaration)
For instantiations of static data members of class templates, keep track of the kind of specialization or instantiation. Also, check the scope of the specialization and ensure that a specialization declaration without an initializer is not a definition. llvm-svn: 83533
2009-10-08 15:24:58 +08:00
return;
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
In Sema::InstantiateStaticDataMemberDefinition, pass the var decl to the consumer just using ASTConsumer::HandleCXXStaticMemberVarInstantiation(), don't pass it with ASTConsumer::HandleTopLevelDecl. ASTConsumer::HandleTopLevelDecl is intended for user-written top-level decls; a consumer can treat an instantiated static data member however it wants of course. llvm-svn: 175976
2013-02-24 08:05:01 +08:00
// Make sure to pass the instantiated variable to the consumer at the end.
struct PassToConsumerRAII {
ASTConsumer &Consumer;
VarDecl *Var;
PassToConsumerRAII(ASTConsumer &Consumer, VarDecl *Var)
: Consumer(Consumer), Var(Var) { }
~PassToConsumerRAII() {
Variable templates: handle instantiation of static data member templates appropriately, especially when they appear within class templates. llvm-svn: 191548
2013-09-28 04:14:12 +08:00
Consumer.HandleCXXStaticMemberVarInstantiation(Var);
In Sema::InstantiateStaticDataMemberDefinition, pass the var decl to the consumer just using ASTConsumer::HandleCXXStaticMemberVarInstantiation(), don't pass it with ASTConsumer::HandleTopLevelDecl. ASTConsumer::HandleTopLevelDecl is intended for user-written top-level decls; a consumer can treat an instantiated static data member however it wants of course. llvm-svn: 175976
2013-02-24 08:05:01 +08:00
}
} PassToConsumerRAII(Consumer, Var);
Replace MarkVarRequired with a more generic HandleCXXStaticMemberVarInstantiation. Suggested by Argyrios. llvm-svn: 152320
2012-03-08 23:51:03 +08:00
Move the logic to avoid double global emission from Sema to CodeGen Reverts the code changes from r234675 but keeps the test case. We were already maintaining a DenseMap of globals with dynamic initializers anyway. Fixes the test case from PR23234. llvm-svn: 234961
2015-04-15 09:08:06 +08:00
// If we already have a definition, we're done.
if (VarDecl *Def = Var->getDefinition()) {
// We may be explicitly instantiating something we've already implicitly
// instantiated.
Def->setTemplateSpecializationKind(Var->getTemplateSpecializationKind(),
PointOfInstantiation);
Variable templates: handle instantiation of static data member templates appropriately, especially when they appear within class templates. llvm-svn: 191548
2013-09-28 04:14:12 +08:00
return;
Move the logic to avoid double global emission from Sema to CodeGen Reverts the code changes from r234675 but keeps the test case. We were already maintaining a DenseMap of globals with dynamic initializers anyway. Fixes the test case from PR23234. llvm-svn: 234961
2015-04-15 09:08:06 +08:00
}
When performing template argument deduction given a function argument of incomplete array type, attempt to complete the array type. This was made much easier by Chandler's addition of RequireCompleteExprType(), which I've tweaked (slightly) to improve the consistency of the DeclRefExpr. Fixes PR7985. llvm-svn: 132530
2011-06-03 11:35:07 +08:00
Template instantiation for static data members that are defined out-of-line. Note that this also fixes a bug that affects non-template code, where we were not treating out-of-line static data members are "file-scope" variables, and therefore not checking their initializers. llvm-svn: 77002
2009-07-25 04:34:43 +08:00
InstantiatingTemplate Inst(*this, PointOfInstantiation, Var);
PR12298 et al: don't recursively instantiate a template specialization from within the instantiation of that same specialization. This could previously happen for eagerly-instantiated function templates, variable templates, exception specifications, default arguments, and a handful of other cases. We still have an issue here for default template arguments that recursively make use of themselves and likewise for substitution into the type of a non-type template parameter, but in those cases we're producing a different entity each time, so they should instead be caught by the instantiation depth limit. However, currently we will typically run out of stack before we reach it. :( llvm-svn: 280190
2016-08-31 10:15:21 +08:00
if (Inst.isInvalid() || Inst.isAlreadyInstantiating())
Template instantiation for static data members that are defined out-of-line. Note that this also fixes a bug that affects non-template code, where we were not treating out-of-line static data members are "file-scope" variables, and therefore not checking their initializers. llvm-svn: 77002
2009-07-25 04:34:43 +08:00
return;
Produce better pretty stack traces from crashes in template instantiation: add pretty stack trace entries for all cases where we instantiate the definition of something, and include the fully-qualified name with template arguments in the name of the instantiated entity. llvm-svn: 270904
2016-05-27 04:23:13 +08:00
PrettyDeclStackTraceEntry CrashInfo(*this, Var, SourceLocation(),
"instantiating variable definition");
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Template instantiation for static data members that are defined out-of-line. Note that this also fixes a bug that affects non-template code, where we were not treating out-of-line static data members are "file-scope" variables, and therefore not checking their initializers. llvm-svn: 77002
2009-07-25 04:34:43 +08:00
// If we're performing recursive template instantiation, create our own
// queue of pending implicit instantiations that we will instantiate later,
// while we're still within our own instantiation context.
Rename RAII objects for performing eager instantiation to have names that describe what they're for, not how they do it, and factor out a bit more common code into them. llvm-svn: 303479
2017-05-20 09:36:41 +08:00
GlobalEagerInstantiationScope GlobalInstantiations(*this,
/*Enabled=*/Recursive);
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Template instantiation for static data members that are defined out-of-line. Note that this also fixes a bug that affects non-template code, where we were not treating out-of-line static data members are "file-scope" variables, and therefore not checking their initializers. llvm-svn: 77002
2009-07-25 04:34:43 +08:00
// Enter the scope of this instantiation. We don't use
// PushDeclContext because we don't have a scope.
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
ContextRAII PreviousContext(*this, Var->getDeclContext());
Lambda closure types are always considered to be like "local" classes, even if they are not within a function scope. Teach template instantiation to treat them as such, and make sure that we have a local instantiation scope when instantiating default arguments and static data members. llvm-svn: 150725
2012-02-17 05:36:18 +08:00
LocalInstantiationScope Local(*this);
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
Rename RAII objects for performing eager instantiation to have names that describe what they're for, not how they do it, and factor out a bit more common code into them. llvm-svn: 303479
2017-05-20 09:36:41 +08:00
LocalEagerInstantiationScope LocalInstantiations(*this);
Give explicit and implicit instantiations of static data members of class templates the proper linkage. Daniel, please look over the CodeGenModule bits. llvm-svn: 84140
2009-10-15 05:29:40 +08:00
VarDecl *OldVar = Var;
Implement C++17 P0386R2, inline variables. (The 'inline' specifier gives a variable weak discardable linkage and partially-ordered initialization, and is implied for constexpr static data members.) llvm-svn: 273754
2016-06-25 08:15:56 +08:00
if (Def->isStaticDataMember() && !Def->isOutOfLine()) {
// We're instantiating an inline static data member whose definition was
// provided inside the class.
// FIXME: Update record?
InstantiateVariableInitializer(Var, Def, TemplateArgs);
} else if (!VarSpec) {
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
Var = cast_or_null<VarDecl>(SubstDecl(Def, Var->getDeclContext(),
Variable templates: handle instantiation of static data member templates appropriately, especially when they appear within class templates. llvm-svn: 191548
2013-09-28 04:14:12 +08:00
TemplateArgs));
Implement C++17 P0386R2, inline variables. (The 'inline' specifier gives a variable weak discardable linkage and partially-ordered initialization, and is implied for constexpr static data members.) llvm-svn: 273754
2016-06-25 08:15:56 +08:00
} else if (Var->isStaticDataMember() &&
Var->getLexicalDeclContext()->isRecord()) {
Variable templates: handle instantiation of static data member templates appropriately, especially when they appear within class templates. llvm-svn: 191548
2013-09-28 04:14:12 +08:00
// We need to instantiate the definition of a static data member template,
// and all we have is the in-class declaration of it. Instantiate a separate
// declaration of the definition.
TemplateDeclInstantiator Instantiator(*this, Var->getDeclContext(),
TemplateArgs);
Var = cast_or_null<VarDecl>(Instantiator.VisitVarTemplateSpecializationDecl(
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
VarSpec->getSpecializedTemplate(), Def, nullptr,
Variable templates: handle instantiation of static data member templates appropriately, especially when they appear within class templates. llvm-svn: 191548
2013-09-28 04:14:12 +08:00
VarSpec->getTemplateArgsInfo(), VarSpec->getTemplateArgs().asArray()));
if (Var) {
llvm::PointerUnion<VarTemplateDecl *,
VarTemplatePartialSpecializationDecl *> PatternPtr =
VarSpec->getSpecializedTemplateOrPartial();
if (VarTemplatePartialSpecializationDecl *Partial =
PatternPtr.dyn_cast<VarTemplatePartialSpecializationDecl *>())
cast<VarTemplateSpecializationDecl>(Var)->setInstantiationOf(
Partial, &VarSpec->getTemplateInstantiationArgs());
// Merge the definition with the declaration.
LookupResult R(*this, Var->getDeclName(), Var->getLocation(),
LookupOrdinaryName, ForRedeclaration);
R.addDecl(OldVar);
MergeVarDecl(Var, R);
// Attach the initializer.
InstantiateVariableInitializer(Var, Def, TemplateArgs);
}
} else
// Complete the existing variable's definition with an appropriately
// substituted type and initializer.
Var = CompleteVarTemplateSpecializationDecl(VarSpec, Def, TemplateArgs);
Change the context correctly when instantiating a static data member definition. llvm-svn: 125517
2011-02-15 04:37:25 +08:00
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
PreviousContext.pop();
Template instantiation for static data members that are defined out-of-line. Note that this also fixes a bug that affects non-template code, where we were not treating out-of-line static data members are "file-scope" variables, and therefore not checking their initializers. llvm-svn: 77002
2009-07-25 04:34:43 +08:00
if (Var) {
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
PassToConsumerRAII.Var = Var;
Variable templates: handle instantiation of static data member templates appropriately, especially when they appear within class templates. llvm-svn: 191548
2013-09-28 04:14:12 +08:00
Var->setTemplateSpecializationKind(OldVar->getTemplateSpecializationKind(),
OldVar->getPointOfInstantiation());
Template instantiation for static data members that are defined out-of-line. Note that this also fixes a bug that affects non-template code, where we were not treating out-of-line static data members are "file-scope" variables, and therefore not checking their initializers. llvm-svn: 77002
2009-07-25 04:34:43 +08:00
}
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
// This variable may have local implicit instantiations that need to be
// instantiated within this scope.
Rename RAII objects for performing eager instantiation to have names that describe what they're for, not how they do it, and factor out a bit more common code into them. llvm-svn: 303479
2017-05-20 09:36:41 +08:00
LocalInstantiations.perform();
Lambda closure types are always considered to be like "local" classes, even if they are not within a function scope. Teach template instantiation to treat them as such, and make sure that we have a local instantiation scope when instantiating default arguments and static data members. llvm-svn: 150725
2012-02-17 05:36:18 +08:00
Local.Exit();
Rename RAII objects for performing eager instantiation to have names that describe what they're for, not how they do it, and factor out a bit more common code into them. llvm-svn: 303479
2017-05-20 09:36:41 +08:00
GlobalInstantiations.perform();
Explicit instantiations of templates now instantiate the definitions of class members (recursively). Only member classes are actually instantiated; the instantiation logic for member functions and variables are just stubs. llvm-svn: 71713
2009-05-14 04:28:22 +08:00
}
Initial stab at a generalized operation for determining the instantiation of a declaration from the template version (or version that lives in a template) and a given set of template arguments. This needs much, much more testing, but it suffices for simple examples like typedef T* iterator; iterator begin(); llvm-svn: 72461
2009-05-27 13:35:12 +08:00
Instantiate member and base initializers. Patch by Anders Johnsen! (tweaked slightly by me) llvm-svn: 80422
2009-08-29 13:16:22 +08:00
void
Sema::InstantiateMemInitializers(CXXConstructorDecl *New,
const CXXConstructorDecl *Tmpl,
const MultiLevelTemplateArgumentList &TemplateArgs) {
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Changed references of BaseTy, MemInitTy, CXXScopeTy, TemplateParamsTy to CXXBaseSpecifier, CXXCtorInitializer, NestedNameSpecifier, TemplateParameterList and removed their typedefs. llvm-svn: 139350
2011-09-09 11:18:59 +08:00
SmallVector<CXXCtorInitializer*, 4> NewInits;
Don't produce diagnostics for missing ctor-initializers during template instantiations if we encountered errors parsing some of the initializers. llvm-svn: 164578
2012-09-25 08:23:05 +08:00
bool AnyErrors = Tmpl->isInvalidDecl();
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Instantiate member and base initializers. Patch by Anders Johnsen! (tweaked slightly by me) llvm-svn: 80422
2009-08-29 13:16:22 +08:00
// Instantiate all the initializers.
[C++11] Replacing CXXRecordDecl iterators init_begin() and init_end() with iterator_range inits(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203819
2014-03-14 01:34:31 +08:00
for (const auto *Init : Tmpl->inits()) {
Fix PR7402 when it strikes via template instantiation. llvm-svn: 113019
2010-09-04 05:54:20 +08:00
// Only instantiate written initializers, let Sema re-construct implicit
// ones.
if (!Init->isWritten())
continue;
Implement pack expansion of base initializers, so that we can initialize those lovely mixins that come from pack expansions of base specifiers. llvm-svn: 122793
2011-01-04 08:32:56 +08:00
SourceLocation EllipsisLoc;
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Implement pack expansion of base initializers, so that we can initialize those lovely mixins that come from pack expansions of base specifiers. llvm-svn: 122793
2011-01-04 08:32:56 +08:00
if (Init->isPackExpansion()) {
// This is a pack expansion. We should expand it now.
Rework the AST for the initializer of a delegating constructor, so that it retains source location information for the type. Aside from general goodness (being able to walk the types described in that information), we now have a proper representation for dependent delegating constructors. Fixes PR10457 (for real). llvm-svn: 143410
2011-11-01 09:16:03 +08:00
TypeLoc BaseTL = Init->getTypeSourceInfo()->getTypeLoc();
Include the unexpanded packs in the initializer expression when checking a pack expanded constructor initializer list. Fixes PR16303! llvm-svn: 183878
2013-06-13 08:45:47 +08:00
SmallVector<UnexpandedParameterPack, 4> Unexpanded;
Implement pack expansion of base initializers, so that we can initialize those lovely mixins that come from pack expansions of base specifiers. llvm-svn: 122793
2011-01-04 08:32:56 +08:00
collectUnexpandedParameterPacks(BaseTL, Unexpanded);
Include the unexpanded packs in the initializer expression when checking a pack expanded constructor initializer list. Fixes PR16303! llvm-svn: 183878
2013-06-13 08:45:47 +08:00
collectUnexpandedParameterPacks(Init->getInit(), Unexpanded);
Implement pack expansion of base initializers, so that we can initialize those lovely mixins that come from pack expansions of base specifiers. llvm-svn: 122793
2011-01-04 08:32:56 +08:00
bool ShouldExpand = false;
Work-in-progress implementation of C++0x [temp.arg.explicit]p9, which allows an argument pack determines via explicit specification of function template arguments to be extended by further, deduced arguments. For example: template<class ... Types> void f(Types ... values); void g() { f<int*, float*>(0, 0, 0); // Types is deduced to the sequence int*, float*, int } There are a number of FIXMEs in here that indicate places where we need to implement + test retained expansions, plus a number of other places in deduction where we need to correctly cope with the explicitly-specified arguments when deducing an argument pack. Furthermore, it appears that the RecursiveASTVisitor needs to be auditied; it's missing some traversals (especially w.r.t. template arguments) that cause it not to find unexpanded parameter packs when it should. The good news, however, is that the tr1::tuple implementation now works fully, and the tr1::bind example (both from N2080) is actually working now. llvm-svn: 123163
2011-01-10 15:32:04 +08:00
bool RetainExpansion = false;
Include llvm::Optional in clang/Basic/LLVM.h Post-commit CR feedback from Jordan Rose regarding r175594. llvm-svn: 175679
2013-02-21 06:23:23 +08:00
Optional<unsigned> NumExpansions;
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
if (CheckParameterPacksForExpansion(Init->getEllipsisLoc(),
Implement pack expansion of base initializers, so that we can initialize those lovely mixins that come from pack expansions of base specifiers. llvm-svn: 122793
2011-01-04 08:32:56 +08:00
BaseTL.getSourceRange(),
ArrayRef-ifying the UnexpandedParameterPacks passed to Sema::CheckParameterPacksForExpansion llvm-svn: 140290
2011-09-22 10:34:54 +08:00
Unexpanded,
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
TemplateArgs, ShouldExpand,
Work-in-progress implementation of C++0x [temp.arg.explicit]p9, which allows an argument pack determines via explicit specification of function template arguments to be extended by further, deduced arguments. For example: template<class ... Types> void f(Types ... values); void g() { f<int*, float*>(0, 0, 0); // Types is deduced to the sequence int*, float*, int } There are a number of FIXMEs in here that indicate places where we need to implement + test retained expansions, plus a number of other places in deduction where we need to correctly cope with the explicitly-specified arguments when deducing an argument pack. Furthermore, it appears that the RecursiveASTVisitor needs to be auditied; it's missing some traversals (especially w.r.t. template arguments) that cause it not to find unexpanded parameter packs when it should. The good news, however, is that the tr1::tuple implementation now works fully, and the tr1::bind example (both from N2080) is actually working now. llvm-svn: 123163
2011-01-10 15:32:04 +08:00
RetainExpansion,
Implement pack expansion of base initializers, so that we can initialize those lovely mixins that come from pack expansions of base specifiers. llvm-svn: 122793
2011-01-04 08:32:56 +08:00
NumExpansions)) {
AnyErrors = true;
New->setInvalidDecl();
continue;
}
assert(ShouldExpand && "Partial instantiation of base initializer?");
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
// Loop over all of the arguments in the argument pack(s),
Keep track of the number of expansions to be produced from a type pack expansion, when it is known due to the substitution of an out parameter pack. This allows us to properly handle substitution into pack expansions that involve multiple parameter packs at different template parameter levels, even when this substitution happens one level at a time (as with partial specializations of member class templates and the signatures of member function templates). Note that the diagnostic we provide when there is an arity mismatch between an outer parameter pack and an inner parameter pack in this case isn't as clear as the normal diagnostic for an arity mismatch. However, this doesn't matter because these cases are very, very rare and (even then) only typically occur in a SFINAE context. The other kinds of pack expansions (expression, template, etc.) still need to support optional tracking of the number of expansions, and we need the moral equivalent of SubstTemplateTypeParmPackType for substituted argument packs of template template and non-type template parameters. llvm-svn: 123448
2011-01-15 01:04:44 +08:00
for (unsigned I = 0; I != *NumExpansions; ++I) {
Implement pack expansion of base initializers, so that we can initialize those lovely mixins that come from pack expansions of base specifiers. llvm-svn: 122793
2011-01-04 08:32:56 +08:00
Sema::ArgumentPackSubstitutionIndexRAII SubstIndex(*this, I);
// Instantiate the initializer.
Represent C++ direct initializers as ParenListExprs before semantic analysis instead of having a special-purpose function. - ActOnCXXDirectInitializer, which was mostly duplication of AddInitializerToDecl (leading e.g. to PR10620, which Eli fixed a few days ago), is dropped completely. - MultiInitializer, which was an ugly hack I added, is dropped again. - We now have the infrastructure in place to distinguish between int x = {1}; int x({1}); int x{1}; -- VarDecl now has getInitStyle(), which indicates which of the above was used. -- CXXConstructExpr now has a flag to indicate that it represents list- initialization, although this is not yet used. - InstantiateInitializer was renamed to SubstInitializer and simplified. - ActOnParenOrParenListExpr has been replaced by ActOnParenListExpr, which always produces a ParenListExpr. Placed that so far failed to convert that back to a ParenExpr containing comma operators have been fixed. I'm pretty sure I could have made a crashing test case before this. The end result is a (I hope) considerably cleaner design of initializers. More importantly, the fact that I can now distinguish between the various initialization kinds means that I can get the tricky generalized initializer test cases Johannes Schaub supplied to work. (This is not yet done.) This commit passed self-host, with the resulting compiler passing the tests. I hope it doesn't break more complicated code. It's a pretty big change, but one that I feel is necessary. llvm-svn: 150318
2012-02-12 07:51:47 +08:00
ExprResult TempInit = SubstInitializer(Init->getInit(), TemplateArgs,
/*CXXDirectInit=*/true);
if (TempInit.isInvalid()) {
Implement pack expansion of base initializers, so that we can initialize those lovely mixins that come from pack expansions of base specifiers. llvm-svn: 122793
2011-01-04 08:32:56 +08:00
AnyErrors = true;
break;
}
// Instantiate the base type.
Rework the AST for the initializer of a delegating constructor, so that it retains source location information for the type. Aside from general goodness (being able to walk the types described in that information), we now have a proper representation for dependent delegating constructors. Fixes PR10457 (for real). llvm-svn: 143410
2011-11-01 09:16:03 +08:00
TypeSourceInfo *BaseTInfo = SubstType(Init->getTypeSourceInfo(),
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
TemplateArgs,
Init->getSourceLocation(),
Implement pack expansion of base initializers, so that we can initialize those lovely mixins that come from pack expansions of base specifiers. llvm-svn: 122793
2011-01-04 08:32:56 +08:00
New->getDeclName());
if (!BaseTInfo) {
AnyErrors = true;
break;
}
// Build the initializer.
Correctly parse braced member initializers (even in delayed parsing) and correctly pass the information on to Sema. There's still an incorrectness in the way template instantiation works now, but that is due to a far larger underlying representational problem. Also add a test case for various list initialization cases of scalars, which test this commit as well as the previous one. llvm-svn: 140460
2011-09-25 01:48:25 +08:00
MemInitResult NewInit = BuildBaseInitializer(BaseTInfo->getType(),
Refactoring. Remove release and take methods from ActionResult. Rename takeAs to getAs. llvm-svn: 209800
2014-05-29 18:55:11 +08:00
BaseTInfo, TempInit.get(),
Implement pack expansion of base initializers, so that we can initialize those lovely mixins that come from pack expansions of base specifiers. llvm-svn: 122793
2011-01-04 08:32:56 +08:00
New->getParent(),
SourceLocation());
if (NewInit.isInvalid()) {
AnyErrors = true;
break;
}
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Implement pack expansion of base initializers, so that we can initialize those lovely mixins that come from pack expansions of base specifiers. llvm-svn: 122793
2011-01-04 08:32:56 +08:00
NewInits.push_back(NewInit.get());
}
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Implement pack expansion of base initializers, so that we can initialize those lovely mixins that come from pack expansions of base specifiers. llvm-svn: 122793
2011-01-04 08:32:56 +08:00
continue;
}
Unify initializer-instantiation code for variable declarations and base/member initializers. llvm-svn: 97560
2010-03-02 15:38:39 +08:00
// Instantiate the initializer.
Represent C++ direct initializers as ParenListExprs before semantic analysis instead of having a special-purpose function. - ActOnCXXDirectInitializer, which was mostly duplication of AddInitializerToDecl (leading e.g. to PR10620, which Eli fixed a few days ago), is dropped completely. - MultiInitializer, which was an ugly hack I added, is dropped again. - We now have the infrastructure in place to distinguish between int x = {1}; int x({1}); int x{1}; -- VarDecl now has getInitStyle(), which indicates which of the above was used. -- CXXConstructExpr now has a flag to indicate that it represents list- initialization, although this is not yet used. - InstantiateInitializer was renamed to SubstInitializer and simplified. - ActOnParenOrParenListExpr has been replaced by ActOnParenListExpr, which always produces a ParenListExpr. Placed that so far failed to convert that back to a ParenExpr containing comma operators have been fixed. I'm pretty sure I could have made a crashing test case before this. The end result is a (I hope) considerably cleaner design of initializers. More importantly, the fact that I can now distinguish between the various initialization kinds means that I can get the tricky generalized initializer test cases Johannes Schaub supplied to work. (This is not yet done.) This commit passed self-host, with the resulting compiler passing the tests. I hope it doesn't break more complicated code. It's a pretty big change, but one that I feel is necessary. llvm-svn: 150318
2012-02-12 07:51:47 +08:00
ExprResult TempInit = SubstInitializer(Init->getInit(), TemplateArgs,
/*CXXDirectInit=*/true);
if (TempInit.isInvalid()) {
Unify initializer-instantiation code for variable declarations and base/member initializers. llvm-svn: 97560
2010-03-02 15:38:39 +08:00
AnyErrors = true;
continue;
Instantiate member and base initializers. Patch by Anders Johnsen! (tweaked slightly by me) llvm-svn: 80422
2009-08-29 13:16:22 +08:00
}
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Instantiate member and base initializers. Patch by Anders Johnsen! (tweaked slightly by me) llvm-svn: 80422
2009-08-29 13:16:22 +08:00
MemInitResult NewInit;
Rework the AST for the initializer of a delegating constructor, so that it retains source location information for the type. Aside from general goodness (being able to walk the types described in that information), we now have a proper representation for dependent delegating constructors. Fixes PR10457 (for real). llvm-svn: 143410
2011-11-01 09:16:03 +08:00
if (Init->isDelegatingInitializer() || Init->isBaseInitializer()) {
TypeSourceInfo *TInfo = SubstType(Init->getTypeSourceInfo(),
TemplateArgs,
Init->getSourceLocation(),
New->getDeclName());
if (!TInfo) {
Rework base and member initialization in constructors, with several (necessarily simultaneous) changes: - CXXBaseOrMemberInitializer now contains only a single initializer rather than a set of initialiation arguments + a constructor. The single initializer covers all aspects of initialization, including constructor calls as necessary but also cleanup of temporaries created by the initializer (which we never handled before!). - Rework + simplify code generation for CXXBaseOrMemberInitializers, since we can now just emit the initializer as an initializer. - Switched base and member initialization over to the new initialization code (InitializationSequence), so that it - Improved diagnostics for the new initialization code when initializing bases and members, to match the diagnostics produced by the previous (special-purpose) code. - Simplify the representation of type-checked constructor initializers in templates; instead of keeping the fully-type-checked AST, which is rather hard to undo at template instantiation time, throw away the type-checked AST and store the raw expressions in the AST. This simplifies instantiation, but loses a little but of information in the AST. - When type-checking implicit base or member initializers within a dependent context, don't add the generated initializers into the AST, because they'll look like they were explicit. - Record in CXXConstructExpr when the constructor call is to initialize a base class, so that CodeGen does not have to infer it from context. This ensures that we call the right kind of constructor. There are also a few "opportunity" fixes here that were needed to not regress, for example: - Diagnose default-initialization of a const-qualified class that does not have a user-declared default constructor. We had this diagnostic specifically for bases and members, but missed it for variables. That's fixed now. - When defining the implicit constructors, destructor, and copy-assignment operator, set the CurContext to that constructor when we're defining the body. llvm-svn: 94952
2010-01-31 17:12:51 +08:00
AnyErrors = true;
Improve source location information for C++ member initializers in a constructor, by keeping the DeclaratorInfo* rather than just the type and a single location. llvm-svn: 90355
2009-12-03 06:36:29 +08:00
New->setInvalidDecl();
continue;
}
Correctly parse braced member initializers (even in delayed parsing) and correctly pass the information on to Sema. There's still an incorrectness in the way template instantiation works now, but that is due to a far larger underlying representational problem. Also add a test case for various list initialization cases of scalars, which test this commit as well as the previous one. llvm-svn: 140460
2011-09-25 01:48:25 +08:00
Rework the AST for the initializer of a delegating constructor, so that it retains source location information for the type. Aside from general goodness (being able to walk the types described in that information), we now have a proper representation for dependent delegating constructors. Fixes PR10457 (for real). llvm-svn: 143410
2011-11-01 09:16:03 +08:00
if (Init->isBaseInitializer())
Refactoring. Remove release and take methods from ActionResult. Rename takeAs to getAs. llvm-svn: 209800
2014-05-29 18:55:11 +08:00
NewInit = BuildBaseInitializer(TInfo->getType(), TInfo, TempInit.get(),
Rework the AST for the initializer of a delegating constructor, so that it retains source location information for the type. Aside from general goodness (being able to walk the types described in that information), we now have a proper representation for dependent delegating constructors. Fixes PR10457 (for real). llvm-svn: 143410
2011-11-01 09:16:03 +08:00
New->getParent(), EllipsisLoc);
else
Refactoring. Remove release and take methods from ActionResult. Rename takeAs to getAs. llvm-svn: 209800
2014-05-29 18:55:11 +08:00
NewInit = BuildDelegatingInitializer(TInfo, TempInit.get(),
Rework the AST for the initializer of a delegating constructor, so that it retains source location information for the type. Aside from general goodness (being able to walk the types described in that information), we now have a proper representation for dependent delegating constructors. Fixes PR10457 (for real). llvm-svn: 143410
2011-11-01 09:16:03 +08:00
cast<CXXRecordDecl>(CurContext->getParent()));
Instantiate member and base initializers. Patch by Anders Johnsen! (tweaked slightly by me) llvm-svn: 80422
2009-08-29 13:16:22 +08:00
} else if (Init->isMemberInitializer()) {
Patch up several Sema::FindInstantiatedDecl() callers, so that they'll properly cope with NULL return values. llvm-svn: 127024
2011-03-05 03:46:35 +08:00
FieldDecl *Member = cast_or_null<FieldDecl>(FindInstantiatedDecl(
More anonymous struct/union redesign. This one deals with anonymous field used in a constructor initializer list: struct X { X() : au_i1(123) {} union { int au_i1; float au_f1; }; }; clang will now deal with au_i1 explicitly as an IndirectFieldDecl. llvm-svn: 120900
2010-12-04 17:14:42 +08:00
Init->getMemberLocation(),
Init->getMember(),
TemplateArgs));
Patch up several Sema::FindInstantiatedDecl() callers, so that they'll properly cope with NULL return values. llvm-svn: 127024
2011-03-05 03:46:35 +08:00
if (!Member) {
AnyErrors = true;
New->setInvalidDecl();
continue;
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Refactoring. Remove release and take methods from ActionResult. Rename takeAs to getAs. llvm-svn: 209800
2014-05-29 18:55:11 +08:00
NewInit = BuildMemberInitializer(Member, TempInit.get(),
Correctly parse braced member initializers (even in delayed parsing) and correctly pass the information on to Sema. There's still an incorrectness in the way template instantiation works now, but that is due to a far larger underlying representational problem. Also add a test case for various list initialization cases of scalars, which test this commit as well as the previous one. llvm-svn: 140460
2011-09-25 01:48:25 +08:00
Init->getSourceLocation());
More anonymous struct/union redesign. This one deals with anonymous field used in a constructor initializer list: struct X { X() : au_i1(123) {} union { int au_i1; float au_f1; }; }; clang will now deal with au_i1 explicitly as an IndirectFieldDecl. llvm-svn: 120900
2010-12-04 17:14:42 +08:00
} else if (Init->isIndirectMemberInitializer()) {
IndirectFieldDecl *IndirectMember =
Patch up several Sema::FindInstantiatedDecl() callers, so that they'll properly cope with NULL return values. llvm-svn: 127024
2011-03-05 03:46:35 +08:00
cast_or_null<IndirectFieldDecl>(FindInstantiatedDecl(
More anonymous struct/union redesign. This one deals with anonymous field used in a constructor initializer list: struct X { X() : au_i1(123) {} union { int au_i1; float au_f1; }; }; clang will now deal with au_i1 explicitly as an IndirectFieldDecl. llvm-svn: 120900
2010-12-04 17:14:42 +08:00
Init->getMemberLocation(),
Init->getIndirectMember(), TemplateArgs));
Patch up several Sema::FindInstantiatedDecl() callers, so that they'll properly cope with NULL return values. llvm-svn: 127024
2011-03-05 03:46:35 +08:00
if (!IndirectMember) {
AnyErrors = true;
New->setInvalidDecl();
Correctly parse braced member initializers (even in delayed parsing) and correctly pass the information on to Sema. There's still an incorrectness in the way template instantiation works now, but that is due to a far larger underlying representational problem. Also add a test case for various list initialization cases of scalars, which test this commit as well as the previous one. llvm-svn: 140460
2011-09-25 01:48:25 +08:00
continue;
Patch up several Sema::FindInstantiatedDecl() callers, so that they'll properly cope with NULL return values. llvm-svn: 127024
2011-03-05 03:46:35 +08:00
}
Correctly parse braced member initializers (even in delayed parsing) and correctly pass the information on to Sema. There's still an incorrectness in the way template instantiation works now, but that is due to a far larger underlying representational problem. Also add a test case for various list initialization cases of scalars, which test this commit as well as the previous one. llvm-svn: 140460
2011-09-25 01:48:25 +08:00
Refactoring. Remove release and take methods from ActionResult. Rename takeAs to getAs. llvm-svn: 209800
2014-05-29 18:55:11 +08:00
NewInit = BuildMemberInitializer(IndirectMember, TempInit.get(),
Correctly parse braced member initializers (even in delayed parsing) and correctly pass the information on to Sema. There's still an incorrectness in the way template instantiation works now, but that is due to a far larger underlying representational problem. Also add a test case for various list initialization cases of scalars, which test this commit as well as the previous one. llvm-svn: 140460
2011-09-25 01:48:25 +08:00
Init->getSourceLocation());
Instantiate member and base initializers. Patch by Anders Johnsen! (tweaked slightly by me) llvm-svn: 80422
2009-08-29 13:16:22 +08:00
}
Rework base and member initialization in constructors, with several (necessarily simultaneous) changes: - CXXBaseOrMemberInitializer now contains only a single initializer rather than a set of initialiation arguments + a constructor. The single initializer covers all aspects of initialization, including constructor calls as necessary but also cleanup of temporaries created by the initializer (which we never handled before!). - Rework + simplify code generation for CXXBaseOrMemberInitializers, since we can now just emit the initializer as an initializer. - Switched base and member initialization over to the new initialization code (InitializationSequence), so that it - Improved diagnostics for the new initialization code when initializing bases and members, to match the diagnostics produced by the previous (special-purpose) code. - Simplify the representation of type-checked constructor initializers in templates; instead of keeping the fully-type-checked AST, which is rather hard to undo at template instantiation time, throw away the type-checked AST and store the raw expressions in the AST. This simplifies instantiation, but loses a little but of information in the AST. - When type-checking implicit base or member initializers within a dependent context, don't add the generated initializers into the AST, because they'll look like they were explicit. - Record in CXXConstructExpr when the constructor call is to initialize a base class, so that CodeGen does not have to infer it from context. This ensures that we call the right kind of constructor. There are also a few "opportunity" fixes here that were needed to not regress, for example: - Diagnose default-initialization of a const-qualified class that does not have a user-declared default constructor. We had this diagnostic specifically for bases and members, but missed it for variables. That's fixed now. - When defining the implicit constructors, destructor, and copy-assignment operator, set the CurContext to that constructor when we're defining the body. llvm-svn: 94952
2010-01-31 17:12:51 +08:00
if (NewInit.isInvalid()) {
AnyErrors = true;
Instantiate member and base initializers. Patch by Anders Johnsen! (tweaked slightly by me) llvm-svn: 80422
2009-08-29 13:16:22 +08:00
New->setInvalidDecl();
Rework base and member initialization in constructors, with several (necessarily simultaneous) changes: - CXXBaseOrMemberInitializer now contains only a single initializer rather than a set of initialiation arguments + a constructor. The single initializer covers all aspects of initialization, including constructor calls as necessary but also cleanup of temporaries created by the initializer (which we never handled before!). - Rework + simplify code generation for CXXBaseOrMemberInitializers, since we can now just emit the initializer as an initializer. - Switched base and member initialization over to the new initialization code (InitializationSequence), so that it - Improved diagnostics for the new initialization code when initializing bases and members, to match the diagnostics produced by the previous (special-purpose) code. - Simplify the representation of type-checked constructor initializers in templates; instead of keeping the fully-type-checked AST, which is rather hard to undo at template instantiation time, throw away the type-checked AST and store the raw expressions in the AST. This simplifies instantiation, but loses a little but of information in the AST. - When type-checking implicit base or member initializers within a dependent context, don't add the generated initializers into the AST, because they'll look like they were explicit. - Record in CXXConstructExpr when the constructor call is to initialize a base class, so that CodeGen does not have to infer it from context. This ensures that we call the right kind of constructor. There are also a few "opportunity" fixes here that were needed to not regress, for example: - Diagnose default-initialization of a const-qualified class that does not have a user-declared default constructor. We had this diagnostic specifically for bases and members, but missed it for variables. That's fixed now. - When defining the implicit constructors, destructor, and copy-assignment operator, set the CurContext to that constructor when we're defining the body. llvm-svn: 94952
2010-01-31 17:12:51 +08:00
} else {
Changed references of BaseTy, MemInitTy, CXXScopeTy, TemplateParamsTy to CXXBaseSpecifier, CXXCtorInitializer, NestedNameSpecifier, TemplateParameterList and removed their typedefs. llvm-svn: 139350
2011-09-09 11:18:59 +08:00
NewInits.push_back(NewInit.get());
Instantiate member and base initializers. Patch by Anders Johnsen! (tweaked slightly by me) llvm-svn: 80422
2009-08-29 13:16:22 +08:00
}
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Instantiate member and base initializers. Patch by Anders Johnsen! (tweaked slightly by me) llvm-svn: 80422
2009-08-29 13:16:22 +08:00
// Assign all the initializers to the new constructor.
DeclPtrTy -> Decl * llvm-svn: 111733
2010-08-21 17:40:31 +08:00
ActOnMemInitializers(New,
Instantiate member and base initializers. Patch by Anders Johnsen! (tweaked slightly by me) llvm-svn: 80422
2009-08-29 13:16:22 +08:00
/*FIXME: ColonLoc */
SourceLocation(),
ArrayRef-ize some ctor initializer related APIs llvm-svn: 172701
2013-01-17 13:26:25 +08:00
NewInits,
Rework base and member initialization in constructors, with several (necessarily simultaneous) changes: - CXXBaseOrMemberInitializer now contains only a single initializer rather than a set of initialiation arguments + a constructor. The single initializer covers all aspects of initialization, including constructor calls as necessary but also cleanup of temporaries created by the initializer (which we never handled before!). - Rework + simplify code generation for CXXBaseOrMemberInitializers, since we can now just emit the initializer as an initializer. - Switched base and member initialization over to the new initialization code (InitializationSequence), so that it - Improved diagnostics for the new initialization code when initializing bases and members, to match the diagnostics produced by the previous (special-purpose) code. - Simplify the representation of type-checked constructor initializers in templates; instead of keeping the fully-type-checked AST, which is rather hard to undo at template instantiation time, throw away the type-checked AST and store the raw expressions in the AST. This simplifies instantiation, but loses a little but of information in the AST. - When type-checking implicit base or member initializers within a dependent context, don't add the generated initializers into the AST, because they'll look like they were explicit. - Record in CXXConstructExpr when the constructor call is to initialize a base class, so that CodeGen does not have to infer it from context. This ensures that we call the right kind of constructor. There are also a few "opportunity" fixes here that were needed to not regress, for example: - Diagnose default-initialization of a const-qualified class that does not have a user-declared default constructor. We had this diagnostic specifically for bases and members, but missed it for variables. That's fixed now. - When defining the implicit constructors, destructor, and copy-assignment operator, set the CurContext to that constructor when we're defining the body. llvm-svn: 94952
2010-01-31 17:12:51 +08:00
AnyErrors);
Instantiate member and base initializers. Patch by Anders Johnsen! (tweaked slightly by me) llvm-svn: 80422
2009-08-29 13:16:22 +08:00
}
Fix the breakage by handling indirect instantiations. This would be much improved if there were a consistent name for getInstantiatedFromMemberX() across all classes. Cheap refactor if someone wants to do it, but let's get the buildbots happy first. llvm-svn: 80425
2009-08-29 16:11:13 +08:00
// TODO: this could be templated if the various decl types used the
// same method name.
static bool isInstantiationOf(ClassTemplateDecl *Pattern,
ClassTemplateDecl *Instance) {
Pattern = Pattern->getCanonicalDecl();
do {
Instance = Instance->getCanonicalDecl();
if (Pattern == Instance) return true;
Instance = Instance->getInstantiatedFromMemberTemplate();
} while (Instance);
return false;
}
Properly match instantiations of member function templates to the function templates from which they were instantiated llvm-svn: 82969
2009-09-28 14:34:35 +08:00
static bool isInstantiationOf(FunctionTemplateDecl *Pattern,
FunctionTemplateDecl *Instance) {
Pattern = Pattern->getCanonicalDecl();
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Properly match instantiations of member function templates to the function templates from which they were instantiated llvm-svn: 82969
2009-09-28 14:34:35 +08:00
do {
Instance = Instance->getCanonicalDecl();
if (Pattern == Instance) return true;
Instance = Instance->getInstantiatedFromMemberTemplate();
} while (Instance);
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Properly match instantiations of member function templates to the function templates from which they were instantiated llvm-svn: 82969
2009-09-28 14:34:35 +08:00
return false;
}
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
static bool
Implement support for semantic checking and template instantiation of class template partial specializations of member templates. Also, fixes a silly little bug in the marking of "used" template parameters in member templates. Fixes PR5236. llvm-svn: 85447
2009-10-29 08:04:11 +08:00
isInstantiationOf(ClassTemplatePartialSpecializationDecl *Pattern,
ClassTemplatePartialSpecializationDecl *Instance) {
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Pattern
Implement support for semantic checking and template instantiation of class template partial specializations of member templates. Also, fixes a silly little bug in the marking of "used" template parameters in member templates. Fixes PR5236. llvm-svn: 85447
2009-10-29 08:04:11 +08:00
= cast<ClassTemplatePartialSpecializationDecl>(Pattern->getCanonicalDecl());
do {
Instance = cast<ClassTemplatePartialSpecializationDecl>(
Instance->getCanonicalDecl());
if (Pattern == Instance)
return true;
Instance = Instance->getInstantiatedFromMember();
} while (Instance);
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Implement support for semantic checking and template instantiation of class template partial specializations of member templates. Also, fixes a silly little bug in the marking of "used" template parameters in member templates. Fixes PR5236. llvm-svn: 85447
2009-10-29 08:04:11 +08:00
return false;
}
Fix the breakage by handling indirect instantiations. This would be much improved if there were a consistent name for getInstantiatedFromMemberX() across all classes. Cheap refactor if someone wants to do it, but let's get the buildbots happy first. llvm-svn: 80425
2009-08-29 16:11:13 +08:00
static bool isInstantiationOf(CXXRecordDecl *Pattern,
CXXRecordDecl *Instance) {
Pattern = Pattern->getCanonicalDecl();
do {
Instance = Instance->getCanonicalDecl();
if (Pattern == Instance) return true;
Instance = Instance->getInstantiatedFromMemberClass();
} while (Instance);
return false;
}
static bool isInstantiationOf(FunctionDecl *Pattern,
FunctionDecl *Instance) {
Pattern = Pattern->getCanonicalDecl();
do {
Instance = Instance->getCanonicalDecl();
if (Pattern == Instance) return true;
Instance = Instance->getInstantiatedFromMemberFunction();
} while (Instance);
return false;
}
static bool isInstantiationOf(EnumDecl *Pattern,
EnumDecl *Instance) {
Pattern = Pattern->getCanonicalDecl();
do {
Instance = Instance->getCanonicalDecl();
if (Pattern == Instance) return true;
Instance = Instance->getInstantiatedFromMemberEnum();
} while (Instance);
return false;
}
Fix "using typename" and the instantiation of non-dependent using declarations. llvm-svn: 90614
2009-12-05 06:46:56 +08:00
static bool isInstantiationOf(UsingShadowDecl *Pattern,
UsingShadowDecl *Instance,
ASTContext &C) {
[modules] Merging for class-scope using-declarations. llvm-svn: 219657
2014-10-14 10:00:47 +08:00
return declaresSameEntity(C.getInstantiatedFromUsingShadowDecl(Instance),
Pattern);
Fix "using typename" and the instantiation of non-dependent using declarations. llvm-svn: 90614
2009-12-05 06:46:56 +08:00
}
[c++1z] P0195R2: Support pack-expansion of using-declarations. This change introduces UsingPackDecl as a marker for the set of UsingDecls produced by pack expansion of a single (unresolved) using declaration. This is not strictly necessary (we just need to be able to map from the original using declaration to its expansions somehow), but it's useful to maintain the invariant that each declaration reference instantiates to refer to one declaration. This is a re-commit of r290080 (reverted in r290092) with a fix for a use-after-lifetime bug. llvm-svn: 290203
2016-12-21 05:35:28 +08:00
static bool isInstantiationOf(UsingDecl *Pattern, UsingDecl *Instance,
Revert "[c++1z] P0195R2: Support pack-expansion of using-declarations." This reverts commit r290080 as it leads to many Clang crashes, e.g.: http://lab.llvm.org:8011/builders/clang-cmake-aarch64-quick/builds/1814 llvm-svn: 290092
2016-12-19 18:09:25 +08:00
ASTContext &C) {
return declaresSameEntity(C.getInstantiatedFromUsingDecl(Instance), Pattern);
}
[c++1z] P0195R2: Support pack-expansion of using-declarations. This change introduces UsingPackDecl as a marker for the set of UsingDecls produced by pack expansion of a single (unresolved) using declaration. This is not strictly necessary (we just need to be able to map from the original using declaration to its expansions somehow), but it's useful to maintain the invariant that each declaration reference instantiates to refer to one declaration. This is a re-commit of r290080 (reverted in r290092) with a fix for a use-after-lifetime bug. llvm-svn: 290203
2016-12-21 05:35:28 +08:00
template<typename T>
static bool isInstantiationOfUnresolvedUsingDecl(T *Pattern, Decl *Other,
ASTContext &Ctx) {
// An unresolved using declaration can instantiate to an unresolved using
// declaration, or to a using declaration or a using declaration pack.
//
// Multiple declarations can claim to be instantiated from an unresolved
// using declaration if it's a pack expansion. We want the UsingPackDecl
// in that case, not the individual UsingDecls within the pack.
bool OtherIsPackExpansion;
NamedDecl *OtherFrom;
if (auto *OtherUUD = dyn_cast<T>(Other)) {
OtherIsPackExpansion = OtherUUD->isPackExpansion();
OtherFrom = Ctx.getInstantiatedFromUsingDecl(OtherUUD);
} else if (auto *OtherUPD = dyn_cast<UsingPackDecl>(Other)) {
OtherIsPackExpansion = true;
OtherFrom = OtherUPD->getInstantiatedFromUsingDecl();
} else if (auto *OtherUD = dyn_cast<UsingDecl>(Other)) {
OtherIsPackExpansion = false;
OtherFrom = Ctx.getInstantiatedFromUsingDecl(OtherUD);
} else {
return false;
}
return Pattern->isPackExpansion() == OtherIsPackExpansion &&
declaresSameEntity(OtherFrom, Pattern);
Improve instantiation of UnresolvedUsingDecls. llvm-svn: 80434
2009-08-30 03:37:28 +08:00
}
Fix the breakage by handling indirect instantiations. This would be much improved if there were a consistent name for getInstantiatedFromMemberX() across all classes. Cheap refactor if someone wants to do it, but let's get the buildbots happy first. llvm-svn: 80425
2009-08-29 16:11:13 +08:00
static bool isInstantiationOfStaticDataMember(VarDecl *Pattern,
VarDecl *Instance) {
assert(Instance->isStaticDataMember());
Pattern = Pattern->getCanonicalDecl();
do {
Instance = Instance->getCanonicalDecl();
if (Pattern == Instance) return true;
Instance = Instance->getInstantiatedFromStaticDataMember();
} while (Instance);
return false;
}
Fix "using typename" and the instantiation of non-dependent using declarations. llvm-svn: 90614
2009-12-05 06:46:56 +08:00
// Other is the prospective instantiation
// D is the prospective pattern
Initial stab at a generalized operation for determining the instantiation of a declaration from the template version (or version that lives in a template) and a given set of template arguments. This needs much, much more testing, but it suffices for simple examples like typedef T* iterator; iterator begin(); llvm-svn: 72461
2009-05-27 13:35:12 +08:00
static bool isInstantiationOf(ASTContext &Ctx, NamedDecl *D, Decl *Other) {
[c++1z] P0195R2: Support pack-expansion of using-declarations. This change introduces UsingPackDecl as a marker for the set of UsingDecls produced by pack expansion of a single (unresolved) using declaration. This is not strictly necessary (we just need to be able to map from the original using declaration to its expansions somehow), but it's useful to maintain the invariant that each declaration reference instantiates to refer to one declaration. This is a re-commit of r290080 (reverted in r290092) with a fix for a use-after-lifetime bug. llvm-svn: 290203
2016-12-21 05:35:28 +08:00
if (auto *UUD = dyn_cast<UnresolvedUsingTypenameDecl>(D))
return isInstantiationOfUnresolvedUsingDecl(UUD, Other, Ctx);
Incremental progress on using declarations. Split UnresolvedUsingDecl into two classes, one for typenames and one for values; this seems to have some support from Doug if not necessarily from the extremely-vague-on-this-point standard. Track the location of the 'typename' keyword in a using-typename decl. Make a new lookup result for unresolved values and deal with it in most places. llvm-svn: 89184
2009-11-18 10:36:19 +08:00
[c++1z] P0195R2: Support pack-expansion of using-declarations. This change introduces UsingPackDecl as a marker for the set of UsingDecls produced by pack expansion of a single (unresolved) using declaration. This is not strictly necessary (we just need to be able to map from the original using declaration to its expansions somehow), but it's useful to maintain the invariant that each declaration reference instantiates to refer to one declaration. This is a re-commit of r290080 (reverted in r290092) with a fix for a use-after-lifetime bug. llvm-svn: 290203
2016-12-21 05:35:28 +08:00
if (auto *UUD = dyn_cast<UnresolvedUsingValueDecl>(D))
return isInstantiationOfUnresolvedUsingDecl(UUD, Other, Ctx);
Initial stab at a generalized operation for determining the instantiation of a declaration from the template version (or version that lives in a template) and a given set of template arguments. This needs much, much more testing, but it suffices for simple examples like typedef T* iterator; iterator begin(); llvm-svn: 72461
2009-05-27 13:35:12 +08:00
[c++1z] P0195R2: Support pack-expansion of using-declarations. This change introduces UsingPackDecl as a marker for the set of UsingDecls produced by pack expansion of a single (unresolved) using declaration. This is not strictly necessary (we just need to be able to map from the original using declaration to its expansions somehow), but it's useful to maintain the invariant that each declaration reference instantiates to refer to one declaration. This is a re-commit of r290080 (reverted in r290092) with a fix for a use-after-lifetime bug. llvm-svn: 290203
2016-12-21 05:35:28 +08:00
if (D->getKind() != Other->getKind())
Improve instantiation of UnresolvedUsingDecls. llvm-svn: 80434
2009-08-30 03:37:28 +08:00
return false;
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Fix some interactions between C++11 and C++14 features and using-declarations: * a dependent non-type using-declaration within a function template can be valid, as it can refer to an enumerator, so don't reject it in the template definition * we can partially substitute into a dependent using-declaration if it appears within a (local class in a) generic lambda within a function template, which means an UnresolvedUsing*Decl doesn't necessarily instantiate to a UsingDecl. llvm-svn: 290071
2016-12-19 05:39:37 +08:00
if (auto *Record = dyn_cast<CXXRecordDecl>(Other))
Fix the breakage by handling indirect instantiations. This would be much improved if there were a consistent name for getInstantiatedFromMemberX() across all classes. Cheap refactor if someone wants to do it, but let's get the buildbots happy first. llvm-svn: 80425
2009-08-29 16:11:13 +08:00
return isInstantiationOf(cast<CXXRecordDecl>(D), Record);
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Fix some interactions between C++11 and C++14 features and using-declarations: * a dependent non-type using-declaration within a function template can be valid, as it can refer to an enumerator, so don't reject it in the template definition * we can partially substitute into a dependent using-declaration if it appears within a (local class in a) generic lambda within a function template, which means an UnresolvedUsing*Decl doesn't necessarily instantiate to a UsingDecl. llvm-svn: 290071
2016-12-19 05:39:37 +08:00
if (auto *Function = dyn_cast<FunctionDecl>(Other))
Fix the breakage by handling indirect instantiations. This would be much improved if there were a consistent name for getInstantiatedFromMemberX() across all classes. Cheap refactor if someone wants to do it, but let's get the buildbots happy first. llvm-svn: 80425
2009-08-29 16:11:13 +08:00
return isInstantiationOf(cast<FunctionDecl>(D), Function);
Initial stab at a generalized operation for determining the instantiation of a declaration from the template version (or version that lives in a template) and a given set of template arguments. This needs much, much more testing, but it suffices for simple examples like typedef T* iterator; iterator begin(); llvm-svn: 72461
2009-05-27 13:35:12 +08:00
Fix some interactions between C++11 and C++14 features and using-declarations: * a dependent non-type using-declaration within a function template can be valid, as it can refer to an enumerator, so don't reject it in the template definition * we can partially substitute into a dependent using-declaration if it appears within a (local class in a) generic lambda within a function template, which means an UnresolvedUsing*Decl doesn't necessarily instantiate to a UsingDecl. llvm-svn: 290071
2016-12-19 05:39:37 +08:00
if (auto *Enum = dyn_cast<EnumDecl>(Other))
Fix the breakage by handling indirect instantiations. This would be much improved if there were a consistent name for getInstantiatedFromMemberX() across all classes. Cheap refactor if someone wants to do it, but let's get the buildbots happy first. llvm-svn: 80425
2009-08-29 16:11:13 +08:00
return isInstantiationOf(cast<EnumDecl>(D), Enum);
Initial stab at a generalized operation for determining the instantiation of a declaration from the template version (or version that lives in a template) and a given set of template arguments. This needs much, much more testing, but it suffices for simple examples like typedef T* iterator; iterator begin(); llvm-svn: 72461
2009-05-27 13:35:12 +08:00
Fix some interactions between C++11 and C++14 features and using-declarations: * a dependent non-type using-declaration within a function template can be valid, as it can refer to an enumerator, so don't reject it in the template definition * we can partially substitute into a dependent using-declaration if it appears within a (local class in a) generic lambda within a function template, which means an UnresolvedUsing*Decl doesn't necessarily instantiate to a UsingDecl. llvm-svn: 290071
2016-12-19 05:39:37 +08:00
if (auto *Var = dyn_cast<VarDecl>(Other))
Fix the breakage by handling indirect instantiations. This would be much improved if there were a consistent name for getInstantiatedFromMemberX() across all classes. Cheap refactor if someone wants to do it, but let's get the buildbots happy first. llvm-svn: 80425
2009-08-29 16:11:13 +08:00
if (Var->isStaticDataMember())
return isInstantiationOfStaticDataMember(cast<VarDecl>(D), Var);
Fix some interactions between C++11 and C++14 features and using-declarations: * a dependent non-type using-declaration within a function template can be valid, as it can refer to an enumerator, so don't reject it in the template definition * we can partially substitute into a dependent using-declaration if it appears within a (local class in a) generic lambda within a function template, which means an UnresolvedUsing*Decl doesn't necessarily instantiate to a UsingDecl. llvm-svn: 290071
2016-12-19 05:39:37 +08:00
if (auto *Temp = dyn_cast<ClassTemplateDecl>(Other))
Fix the breakage by handling indirect instantiations. This would be much improved if there were a consistent name for getInstantiatedFromMemberX() across all classes. Cheap refactor if someone wants to do it, but let's get the buildbots happy first. llvm-svn: 80425
2009-08-29 16:11:13 +08:00
return isInstantiationOf(cast<ClassTemplateDecl>(D), Temp);
Don't crash when instantiating templates containing anonymous structs/unions llvm-svn: 80397
2009-08-29 06:03:51 +08:00
Fix some interactions between C++11 and C++14 features and using-declarations: * a dependent non-type using-declaration within a function template can be valid, as it can refer to an enumerator, so don't reject it in the template definition * we can partially substitute into a dependent using-declaration if it appears within a (local class in a) generic lambda within a function template, which means an UnresolvedUsing*Decl doesn't necessarily instantiate to a UsingDecl. llvm-svn: 290071
2016-12-19 05:39:37 +08:00
if (auto *Temp = dyn_cast<FunctionTemplateDecl>(Other))
Properly match instantiations of member function templates to the function templates from which they were instantiated llvm-svn: 82969
2009-09-28 14:34:35 +08:00
return isInstantiationOf(cast<FunctionTemplateDecl>(D), Temp);
Fix some interactions between C++11 and C++14 features and using-declarations: * a dependent non-type using-declaration within a function template can be valid, as it can refer to an enumerator, so don't reject it in the template definition * we can partially substitute into a dependent using-declaration if it appears within a (local class in a) generic lambda within a function template, which means an UnresolvedUsing*Decl doesn't necessarily instantiate to a UsingDecl. llvm-svn: 290071
2016-12-19 05:39:37 +08:00
if (auto *PartialSpec =
dyn_cast<ClassTemplatePartialSpecializationDecl>(Other))
Implement support for semantic checking and template instantiation of class template partial specializations of member templates. Also, fixes a silly little bug in the marking of "used" template parameters in member templates. Fixes PR5236. llvm-svn: 85447
2009-10-29 08:04:11 +08:00
return isInstantiationOf(cast<ClassTemplatePartialSpecializationDecl>(D),
PartialSpec);
Fix some interactions between C++11 and C++14 features and using-declarations: * a dependent non-type using-declaration within a function template can be valid, as it can refer to an enumerator, so don't reject it in the template definition * we can partially substitute into a dependent using-declaration if it appears within a (local class in a) generic lambda within a function template, which means an UnresolvedUsing*Decl doesn't necessarily instantiate to a UsingDecl. llvm-svn: 290071
2016-12-19 05:39:37 +08:00
if (auto *Field = dyn_cast<FieldDecl>(Other)) {
Don't assert when instantiating member references to fields in anonymous structs. llvm-svn: 80657
2009-09-01 12:26:58 +08:00
if (!Field->getDeclName()) {
// This is an unnamed field.
[modules] Merging for class-scope using-declarations. llvm-svn: 219657
2014-10-14 10:00:47 +08:00
return declaresSameEntity(Ctx.getInstantiatedFromUnnamedFieldDecl(Field),
cast<FieldDecl>(D));
Don't assert when instantiating member references to fields in anonymous structs. llvm-svn: 80657
2009-09-01 12:26:58 +08:00
}
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Fix some interactions between C++11 and C++14 features and using-declarations: * a dependent non-type using-declaration within a function template can be valid, as it can refer to an enumerator, so don't reject it in the template definition * we can partially substitute into a dependent using-declaration if it appears within a (local class in a) generic lambda within a function template, which means an UnresolvedUsing*Decl doesn't necessarily instantiate to a UsingDecl. llvm-svn: 290071
2016-12-19 05:39:37 +08:00
if (auto *Using = dyn_cast<UsingDecl>(Other))
Fix "using typename" and the instantiation of non-dependent using declarations. llvm-svn: 90614
2009-12-05 06:46:56 +08:00
return isInstantiationOf(cast<UsingDecl>(D), Using, Ctx);
Fix some interactions between C++11 and C++14 features and using-declarations: * a dependent non-type using-declaration within a function template can be valid, as it can refer to an enumerator, so don't reject it in the template definition * we can partially substitute into a dependent using-declaration if it appears within a (local class in a) generic lambda within a function template, which means an UnresolvedUsing*Decl doesn't necessarily instantiate to a UsingDecl. llvm-svn: 290071
2016-12-19 05:39:37 +08:00
if (auto *Shadow = dyn_cast<UsingShadowDecl>(Other))
Fix "using typename" and the instantiation of non-dependent using declarations. llvm-svn: 90614
2009-12-05 06:46:56 +08:00
return isInstantiationOf(cast<UsingShadowDecl>(D), Shadow, Ctx);
Fix some interactions between C++11 and C++14 features and using-declarations: * a dependent non-type using-declaration within a function template can be valid, as it can refer to an enumerator, so don't reject it in the template definition * we can partially substitute into a dependent using-declaration if it appears within a (local class in a) generic lambda within a function template, which means an UnresolvedUsing*Decl doesn't necessarily instantiate to a UsingDecl. llvm-svn: 290071
2016-12-19 05:39:37 +08:00
return D->getDeclName() &&
D->getDeclName() == cast<NamedDecl>(Other)->getDeclName();
Initial stab at a generalized operation for determining the instantiation of a declaration from the template version (or version that lives in a template) and a given set of template arguments. This needs much, much more testing, but it suffices for simple examples like typedef T* iterator; iterator begin(); llvm-svn: 72461
2009-05-27 13:35:12 +08:00
}
template<typename ForwardIterator>
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
static NamedDecl *findInstantiationOf(ASTContext &Ctx,
Initial stab at a generalized operation for determining the instantiation of a declaration from the template version (or version that lives in a template) and a given set of template arguments. This needs much, much more testing, but it suffices for simple examples like typedef T* iterator; iterator begin(); llvm-svn: 72461
2009-05-27 13:35:12 +08:00
NamedDecl *D,
ForwardIterator first,
ForwardIterator last) {
for (; first != last; ++first)
if (isInstantiationOf(Ctx, D, *first))
return cast<NamedDecl>(*first);
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Initial stab at a generalized operation for determining the instantiation of a declaration from the template version (or version that lives in a template) and a given set of template arguments. This needs much, much more testing, but it suffices for simple examples like typedef T* iterator; iterator begin(); llvm-svn: 72461
2009-05-27 13:35:12 +08:00
}
Omnibus friend decl refactoring. Instead of cloning AST classes for friend declarations of same, introduce a single AST class and add appropriate bits (encoded in the namespace) for whether a decl is "real" or not. Much hackery about previously-declared / not-previously-declared, but it's essentially mandated by the standard that friends alter lookup, and this is at least fairly non-intrusive. Refactor the Sema methods specific to friends for cleaner flow and less nesting. Incidentally solve a few bugs, but I remain confident that we can put them back. llvm-svn: 80353
2009-08-28 15:59:38 +08:00
/// \brief Finds the instantiation of the given declaration context
/// within the current instantiation.
///
/// \returns NULL if there was an error
When looking for the instantiated declaration that corresponds to a given declaration in a template, make sure that the context we're searching through is complete. Fixes PR6376. llvm-svn: 97444
2010-03-01 23:56:25 +08:00
DeclContext *Sema::FindInstantiatedContext(SourceLocation Loc, DeclContext* DC,
Teach Sema::FindInstantiatedDecl to find instantiated RecordDecls even when we are not instantiating the corresponding "current instantiation." This happens, e.g., when we are instantiating a declaration reference that refers into the "current instantiation" but occurs in a default function argument. The libstdc++ vector default constructor now instantiates properly. llvm-svn: 82069
2009-09-17 02:34:49 +08:00
const MultiLevelTemplateArgumentList &TemplateArgs) {
Omnibus friend decl refactoring. Instead of cloning AST classes for friend declarations of same, introduce a single AST class and add appropriate bits (encoded in the namespace) for whether a decl is "real" or not. Much hackery about previously-declared / not-previously-declared, but it's essentially mandated by the standard that friends alter lookup, and this is at least fairly non-intrusive. Refactor the Sema methods specific to friends for cleaner flow and less nesting. Incidentally solve a few bugs, but I remain confident that we can put them back. llvm-svn: 80353
2009-08-28 15:59:38 +08:00
if (NamedDecl *D = dyn_cast<NamedDecl>(DC)) {
Weaken restriction in r304862 to allow implicit deduction guides to reference the injected-class-name of a specialization that uses a partial / explicit specialization. llvm-svn: 304957
2017-06-08 09:08:50 +08:00
Decl* ID = FindInstantiatedDecl(Loc, D, TemplateArgs, true);
Omnibus friend decl refactoring. Instead of cloning AST classes for friend declarations of same, introduce a single AST class and add appropriate bits (encoded in the namespace) for whether a decl is "real" or not. Much hackery about previously-declared / not-previously-declared, but it's essentially mandated by the standard that friends alter lookup, and this is at least fairly non-intrusive. Refactor the Sema methods specific to friends for cleaner flow and less nesting. Incidentally solve a few bugs, but I remain confident that we can put them back. llvm-svn: 80353
2009-08-28 15:59:38 +08:00
return cast_or_null<DeclContext>(ID);
} else return DC;
}
Simplify, and improve the performance of, template instantiation for declaration references. The key realization is that dependent Decls, which actually require instantiation, can only refer to the current instantiation or members thereof. And, since the current context during instantiation contains all of those members of the current instantiation, we can simply find the real instantiate that matches up with the "current instantiation" template. llvm-svn: 72486
2009-05-28 01:54:46 +08:00
/// \brief Find the instantiation of the given declaration within the
/// current instantiation.
Initial stab at a generalized operation for determining the instantiation of a declaration from the template version (or version that lives in a template) and a given set of template arguments. This needs much, much more testing, but it suffices for simple examples like typedef T* iterator; iterator begin(); llvm-svn: 72461
2009-05-27 13:35:12 +08:00
///
/// This routine is intended to be used when \p D is a declaration
/// referenced from within a template, that needs to mapped into the
/// corresponding declaration within an instantiation. For example,
/// given:
///
/// \code
/// template<typename T>
/// struct X {
/// enum Kind {
/// KnownValue = sizeof(T)
/// };
///
/// bool getKind() const { return KnownValue; }
/// };
///
/// template struct X<int>;
/// \endcode
///
Fixed comment of Sema::FindInstantiatedDecl. llvm-svn: 185997
2013-07-10 12:59:14 +08:00
/// In the instantiation of <tt>X<int>::getKind()</tt>, we need to map the
/// \p EnumConstantDecl for \p KnownValue (which refers to
/// <tt>X<T>::<Kind>::KnownValue</tt>) to its instantiation
/// (<tt>X<int>::<Kind>::KnownValue</tt>). \p FindInstantiatedDecl performs
/// this mapping from within the instantiation of <tt>X<int></tt>.
When looking for the instantiated declaration that corresponds to a given declaration in a template, make sure that the context we're searching through is complete. Fixes PR6376. llvm-svn: 97444
2010-03-01 23:56:25 +08:00
NamedDecl *Sema::FindInstantiatedDecl(SourceLocation Loc, NamedDecl *D,
Weaken restriction in r304862 to allow implicit deduction guides to reference the injected-class-name of a specialization that uses a partial / explicit specialization. llvm-svn: 304957
2017-06-08 09:08:50 +08:00
const MultiLevelTemplateArgumentList &TemplateArgs,
bool FindingInstantiatedContext) {
Initial stab at a generalized operation for determining the instantiation of a declaration from the template version (or version that lives in a template) and a given set of template arguments. This needs much, much more testing, but it suffices for simple examples like typedef T* iterator; iterator begin(); llvm-svn: 72461
2009-05-27 13:35:12 +08:00
DeclContext *ParentDC = D->getDeclContext();
And Again: Teach TreeTransform how to transform nested generic lambdas. A previous attempt http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130930/090049.html resulted in PR 17476, and was reverted, The original TransformLambdaExpr (pre generic-lambdas) transformed the TypeSourceInfo of the Call operator in its own instantiation scope via TransformType. This resulted in the parameters of the call operator being mapped to their transformed counterparts in an instantiation scope that would get popped off. Then a call to TransformFunctionParameters would add the parameters and their transformed mappings (but newly created ones!) to the current instantiation scope. This would result in a disconnect between the new call operator's TSI parameters and those used to construct the call operator declaration. This was ok in the non-generic lambda world - but would cause issues with nested transformations (when non-generic and generics were interleaved) in the generic lambda world - that I somewhat kludged around initially - but this resulted in PR17476. The new approach seems cleaner. We only do the transformation of the TypeSourceInfo - but we make sure to do it in the current instantiation scope so we don't lose the untransformed to transformed mappings of the ParmVarDecls when they get created. Another attempt caused a test to fail (http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20131021/091533.html) and also had to be reverted - my apologies - in my haste, i did not run all the tests - argh! Now all the tests seem to pass - but a Fixme has been added - since I suspect Richard will find the fix a little inelegant ;) I shall try and work on a more elegant fix once I have had a chance to discuss with Richard or Doug at a later date. Hopefully the third time;s a charm *fingers crossed* This does not yet include capturing. Please see test file for examples. This patch was LGTM'd by Doug: http://llvm-reviews.chandlerc.com/D1784 llvm-svn: 193230
2013-10-23 14:44:28 +08:00
// FIXME: Parmeters of pointer to functions (y below) that are themselves
// parameters (p below) can have their ParentDC set to the translation-unit
// - thus we can not consistently check if the ParentDC of such a parameter
// is Dependent or/and a FunctionOrMethod.
// For e.g. this code, during Template argument deduction tries to
// find an instantiated decl for (T y) when the ParentDC for y is
// the translation unit.
// e.g. template <class T> void Foo(auto (*p)(T y) -> decltype(y())) {}
Distinguish between attributes explicitly written at the request of the user, and attributes implicitly generated to assist in bookkeeping by the compiler. This is done so by table generating a CreateImplicit method for each attribute. Additionally, remove the optional nature of the spelling list index when creating attributes. This is supported by table generating a Spelling enumeration when the spellings for an attribute are distinct enough to warrant it. llvm-svn: 199378
2014-01-16 21:03:14 +08:00
// float baz(float(*)()) { return 0.0; }
And Again: Teach TreeTransform how to transform nested generic lambdas. A previous attempt http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130930/090049.html resulted in PR 17476, and was reverted, The original TransformLambdaExpr (pre generic-lambdas) transformed the TypeSourceInfo of the Call operator in its own instantiation scope via TransformType. This resulted in the parameters of the call operator being mapped to their transformed counterparts in an instantiation scope that would get popped off. Then a call to TransformFunctionParameters would add the parameters and their transformed mappings (but newly created ones!) to the current instantiation scope. This would result in a disconnect between the new call operator's TSI parameters and those used to construct the call operator declaration. This was ok in the non-generic lambda world - but would cause issues with nested transformations (when non-generic and generics were interleaved) in the generic lambda world - that I somewhat kludged around initially - but this resulted in PR17476. The new approach seems cleaner. We only do the transformation of the TypeSourceInfo - but we make sure to do it in the current instantiation scope so we don't lose the untransformed to transformed mappings of the ParmVarDecls when they get created. Another attempt caused a test to fail (http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20131021/091533.html) and also had to be reverted - my apologies - in my haste, i did not run all the tests - argh! Now all the tests seem to pass - but a Fixme has been added - since I suspect Richard will find the fix a little inelegant ;) I shall try and work on a more elegant fix once I have had a chance to discuss with Richard or Doug at a later date. Hopefully the third time;s a charm *fingers crossed* This does not yet include capturing. Please see test file for examples. This patch was LGTM'd by Doug: http://llvm-reviews.chandlerc.com/D1784 llvm-svn: 193230
2013-10-23 14:44:28 +08:00
// Foo(baz);
// The better fix here is perhaps to ensure that a ParmVarDecl, by the time
// it gets here, always has a FunctionOrMethod as its ParentDC??
// For now:
// - as long as we have a ParmVarDecl whose parent is non-dependent and
// whose type is not instantiation dependent, do nothing to the decl
// - otherwise find its instantiated decl.
if (isa<ParmVarDecl>(D) && !ParentDC->isDependentContext() &&
!cast<ParmVarDecl>(D)->getType()->isInstantiationDependentType())
return D;
Revert r193223 and r193216. They were causing CodeGenCXX/mangle-exprs.cpp to fail. Revert "Remove the circular reference to LambdaExpr in CXXRecordDecl." Revert "Again: Teach TreeTransform and family how to transform generic lambdas nested within templates and themselves." llvm-svn: 193226
2013-10-23 12:12:23 +08:00
if (isa<ParmVarDecl>(D) || isa<NonTypeTemplateParmDecl>(D) ||
Fix two issues with the substitution of template template parameters when instantiating the declaration of a member template: - Only check if the have a template template argument at a specific position when we already know that we have template arguments at that level; otherwise, we're substituting for a level-reduced template template parameter. - When trying to find an instantiated declaration for a template template parameter, look into the instantiated scope. This was a typo, where we had two checks for TemplateTypeParmDecl, one of which should have been a TemplateTemplateParmDecl. With these changes, tramp3d-v4 passes -fsyntax-only. llvm-svn: 95421
2010-02-06 03:54:12 +08:00
isa<TemplateTypeParmDecl>(D) || isa<TemplateTemplateParmDecl>(D) ||
Lambda closure types are always considered to be like "local" classes, even if they are not within a function scope. Teach template instantiation to treat them as such, and make sure that we have a local instantiation scope when instantiating default arguments and static data members. llvm-svn: 150725
2012-02-17 05:36:18 +08:00
(ParentDC->isFunctionOrMethod() && ParentDC->isDependentContext()) ||
(isa<CXXRecordDecl>(D) && cast<CXXRecordDecl>(D)->isLambda())) {
Improve name lookup for and template instantiation of declaration references. There are several smallish fixes here: - Make sure we look through template parameter scope when determining whether we're parsing a nested class (or nested class *template*). This makes sure that we delay parsing the bodies of inline member functions until after we're out of the outermost class (template) scope. - Since the bodies of member functions are always parsed "out-of-line", even when they were declared in-line, teach unqualified name lookup to look into the (semantic) parents. - Use the new InstantiateDeclRef to handle the instantiation of a reference to a declaration (in DeclRefExpr), which drastically simplifies template instantiation for DeclRefExprs. - When we're instantiating a ParmVarDecl, it must be in the current instantiation scope, so only look there. Also, remove the #if 0's and FIXME's from the dynarray example, which now compiles and executes thanks to Anders and Eli. llvm-svn: 72481
2009-05-28 01:07:49 +08:00
// D is a local of some kind. Look into the map of local
// declarations to their instantiations.
Fix member function call on null pointer in Sema::FindInstantiatedDecl. This bug was reported by UBSan. llvm-svn: 217059
2014-09-04 02:45:45 +08:00
if (CurrentInstantiationScope) {
if (auto Found = CurrentInstantiationScope->findInstantiationOf(D)) {
if (Decl *FD = Found->dyn_cast<Decl *>())
return cast<NamedDecl>(FD);
int PackIdx = ArgumentPackSubstitutionIndex;
assert(PackIdx != -1 &&
"found declaration pack but not pack expanding");
typedef LocalInstantiationScope::DeclArgumentPack DeclArgumentPack;
return cast<NamedDecl>((*Found->get<DeclArgumentPack *>())[PackIdx]);
}
Step #2/N of __label__ support: keep pushing LabelDecl forward, making them be template instantiated in a more normal way and make them handle attributes like other decls. This fixes the used/unused label handling stuff, making it use the same infrastructure as other decls. llvm-svn: 125771
2011-02-18 04:34:02 +08:00
}
Fix to PR12262 - assertion when substituting explicit template arguments does not substitute a sizeof-pack expression. The solution is proposed by Richard Smith. Differential Revision: http://llvm-reviews.chandlerc.com/D869 llvm-svn: 186306
2013-07-15 14:14:07 +08:00
// If we're performing a partial substitution during template argument
// deduction, we may not have values for template parameters yet. They
// just map to themselves.
if (isa<NonTypeTemplateParmDecl>(D) || isa<TemplateTypeParmDecl>(D) ||
isa<TemplateTemplateParmDecl>(D))
return D;
Fix to PR16225 (Assert-on-invalid: isa<LabelDecl>(D) && "declaration not instantiated in this scope") Differential Revision: http://llvm-reviews.chandlerc.com/D920 llvm-svn: 188137
2013-08-10 20:00:21 +08:00
if (D->isInvalidDecl())
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Fix to PR16225 (Assert-on-invalid: isa<LabelDecl>(D) && "declaration not instantiated in this scope") Differential Revision: http://llvm-reviews.chandlerc.com/D920 llvm-svn: 188137
2013-08-10 20:00:21 +08:00
Limit set of types instantiated in FindInstantiatedDecl. Starting from r236426 FindInstantiatedDecl may instantiate types that are referenced before definition. This change limit the set of types that can be instantiated by this function. llvm-svn: 237434
2015-05-15 18:10:28 +08:00
// Normally this function only searches for already instantiated declaration
// however we have to make an exclusion for local types used before
// definition as in the code:
//
// template<typename T> void f1() {
// void g1(struct x1);
// struct x1 {};
// }
//
// In this case instantiation of the type of 'g1' requires definition of
// 'x1', which is defined later. Error recovery may produce an enum used
// before definition. In these cases we need to instantiate relevant
// declarations here.
bool NeedInstantiate = false;
if (CXXRecordDecl *RD = dyn_cast<CXXRecordDecl>(D))
NeedInstantiate = RD->isLocalClass();
else
NeedInstantiate = isa<EnumDecl>(D);
if (NeedInstantiate) {
Instantiate incomplete class used in template method. If a class is absent from instantiation and is incomplete, instantiate it as an incomplete class thus avoiding compiler crash. This change fixes PR18653. Differential Revision: http://reviews.llvm.org/D8281 llvm-svn: 236426
2015-05-05 00:44:39 +08:00
Decl *Inst = SubstDecl(D, CurContext, TemplateArgs);
CurrentInstantiationScope->InstantiatedLocal(D, Inst);
return cast<TypeDecl>(Inst);
}
Step #2/N of __label__ support: keep pushing LabelDecl forward, making them be template instantiated in a more normal way and make them handle attributes like other decls. This fixes the used/unused label handling stuff, making it use the same infrastructure as other decls. llvm-svn: 125771
2011-02-18 04:34:02 +08:00
// If we didn't find the decl, then we must have a label decl that hasn't
// been found yet. Lazily instantiate it and return it now.
assert(isa<LabelDecl>(D));
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Step #2/N of __label__ support: keep pushing LabelDecl forward, making them be template instantiated in a more normal way and make them handle attributes like other decls. This fixes the used/unused label handling stuff, making it use the same infrastructure as other decls. llvm-svn: 125771
2011-02-18 04:34:02 +08:00
Decl *Inst = SubstDecl(D, CurContext, TemplateArgs);
assert(Inst && "Failed to instantiate label??");
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Step #2/N of __label__ support: keep pushing LabelDecl forward, making them be template instantiated in a more normal way and make them handle attributes like other decls. This fixes the used/unused label handling stuff, making it use the same infrastructure as other decls. llvm-svn: 125771
2011-02-18 04:34:02 +08:00
CurrentInstantiationScope->InstantiatedLocal(D, Inst);
return cast<LabelDecl>(Inst);
Improve name lookup for and template instantiation of declaration references. There are several smallish fixes here: - Make sure we look through template parameter scope when determining whether we're parsing a nested class (or nested class *template*). This makes sure that we delay parsing the bodies of inline member functions until after we're out of the outermost class (template) scope. - Since the bodies of member functions are always parsed "out-of-line", even when they were declared in-line, teach unqualified name lookup to look into the (semantic) parents. - Use the new InstantiateDeclRef to handle the instantiation of a reference to a declaration (in DeclRefExpr), which drastically simplifies template instantiation for DeclRefExprs. - When we're instantiating a ParmVarDecl, it must be in the current instantiation scope, so only look there. Also, remove the #if 0's and FIXME's from the dynarray example, which now compiles and executes thanks to Anders and Eli. llvm-svn: 72481
2009-05-28 01:07:49 +08:00
}
Initial stab at a generalized operation for determining the instantiation of a declaration from the template version (or version that lives in a template) and a given set of template arguments. This needs much, much more testing, but it suffices for simple examples like typedef T* iterator; iterator begin(); llvm-svn: 72461
2009-05-27 13:35:12 +08:00
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
// For variable template specializations, update those that are still
// type-dependent.
if (VarTemplateSpecializationDecl *VarSpec =
dyn_cast<VarTemplateSpecializationDecl>(D)) {
bool InstantiationDependent = false;
const TemplateArgumentListInfo &VarTemplateArgs =
VarSpec->getTemplateArgsInfo();
if (TemplateSpecializationType::anyDependentTemplateArguments(
VarTemplateArgs, InstantiationDependent))
D = cast<NamedDecl>(
SubstDecl(D, VarSpec->getDeclContext(), TemplateArgs));
return D;
}
Teach Sema::FindInstantiatedDecl to find instantiated RecordDecls even when we are not instantiating the corresponding "current instantiation." This happens, e.g., when we are instantiating a declaration reference that refers into the "current instantiation" but occurs in a default function argument. The libstdc++ vector default constructor now instantiates properly. llvm-svn: 82069
2009-09-17 02:34:49 +08:00
if (CXXRecordDecl *Record = dyn_cast<CXXRecordDecl>(D)) {
if (!Record->isDependentContext())
return D;
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Drastically simplify the mapping from the declaration corresponding to the injected-class-name of a class (or class template) to the declaration that results from substituting the given template arguments. Previously, we would actually perform a substitution into the injected-class-name type and then retrieve the resulting declaration. However, in certain, rare circumstances involving deeply-nested member templates, we would get the wrong substitution arguments. This new approach just matches up the declaration with a declaration that's part of the current context (or one of its parents), which will either be an instantiation (during template instantiation) or the declaration itself (during the definition of the template). This is both more efficient (we're avoiding a substitution) and more correct (we can't get the template arguments wrong in the member-template case). Fixes <rdar://problem/9676205>. Reinstated, now that we have the fix in r143967. llvm-svn: 143968
2011-11-08 01:43:18 +08:00
// Determine whether this record is the "templated" declaration describing
// a class template or class template partial specialization.
Teach Sema::FindInstantiatedDecl to find instantiated RecordDecls even when we are not instantiating the corresponding "current instantiation." This happens, e.g., when we are instantiating a declaration reference that refers into the "current instantiation" but occurs in a default function argument. The libstdc++ vector default constructor now instantiates properly. llvm-svn: 82069
2009-09-17 02:34:49 +08:00
ClassTemplateDecl *ClassTemplate = Record->getDescribedClassTemplate();
Drastically simplify the mapping from the declaration corresponding to the injected-class-name of a class (or class template) to the declaration that results from substituting the given template arguments. Previously, we would actually perform a substitution into the injected-class-name type and then retrieve the resulting declaration. However, in certain, rare circumstances involving deeply-nested member templates, we would get the wrong substitution arguments. This new approach just matches up the declaration with a declaration that's part of the current context (or one of its parents), which will either be an instantiation (during template instantiation) or the declaration itself (during the definition of the template). This is both more efficient (we're avoiding a substitution) and more correct (we can't get the template arguments wrong in the member-template case). Fixes <rdar://problem/9676205>. Reinstated, now that we have the fix in r143967. llvm-svn: 143968
2011-11-08 01:43:18 +08:00
if (ClassTemplate)
ClassTemplate = ClassTemplate->getCanonicalDecl();
else if (ClassTemplatePartialSpecializationDecl *PartialSpec
= dyn_cast<ClassTemplatePartialSpecializationDecl>(Record))
ClassTemplate = PartialSpec->getSpecializedTemplate()->getCanonicalDecl();
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
Drastically simplify the mapping from the declaration corresponding to the injected-class-name of a class (or class template) to the declaration that results from substituting the given template arguments. Previously, we would actually perform a substitution into the injected-class-name type and then retrieve the resulting declaration. However, in certain, rare circumstances involving deeply-nested member templates, we would get the wrong substitution arguments. This new approach just matches up the declaration with a declaration that's part of the current context (or one of its parents), which will either be an instantiation (during template instantiation) or the declaration itself (during the definition of the template). This is both more efficient (we're avoiding a substitution) and more correct (we can't get the template arguments wrong in the member-template case). Fixes <rdar://problem/9676205>. Reinstated, now that we have the fix in r143967. llvm-svn: 143968
2011-11-08 01:43:18 +08:00
// Walk the current context to find either the record or an instantiation of
// it.
DeclContext *DC = CurContext;
while (!DC->isFileContext()) {
// If we're performing substitution while we're inside the template
// definition, we'll find our own context. We're done.
if (DC->Equals(Record))
return Record;
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
Drastically simplify the mapping from the declaration corresponding to the injected-class-name of a class (or class template) to the declaration that results from substituting the given template arguments. Previously, we would actually perform a substitution into the injected-class-name type and then retrieve the resulting declaration. However, in certain, rare circumstances involving deeply-nested member templates, we would get the wrong substitution arguments. This new approach just matches up the declaration with a declaration that's part of the current context (or one of its parents), which will either be an instantiation (during template instantiation) or the declaration itself (during the definition of the template). This is both more efficient (we're avoiding a substitution) and more correct (we can't get the template arguments wrong in the member-template case). Fixes <rdar://problem/9676205>. Reinstated, now that we have the fix in r143967. llvm-svn: 143968
2011-11-08 01:43:18 +08:00
if (CXXRecordDecl *InstRecord = dyn_cast<CXXRecordDecl>(DC)) {
// Check whether we're in the process of instantiating a class template
// specialization of the template we're mapping.
if (ClassTemplateSpecializationDecl *InstSpec
= dyn_cast<ClassTemplateSpecializationDecl>(InstRecord)){
ClassTemplateDecl *SpecTemplate = InstSpec->getSpecializedTemplate();
if (ClassTemplate && isInstantiationOf(ClassTemplate, SpecTemplate))
return InstRecord;
}
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
Drastically simplify the mapping from the declaration corresponding to the injected-class-name of a class (or class template) to the declaration that results from substituting the given template arguments. Previously, we would actually perform a substitution into the injected-class-name type and then retrieve the resulting declaration. However, in certain, rare circumstances involving deeply-nested member templates, we would get the wrong substitution arguments. This new approach just matches up the declaration with a declaration that's part of the current context (or one of its parents), which will either be an instantiation (during template instantiation) or the declaration itself (during the definition of the template). This is both more efficient (we're avoiding a substitution) and more correct (we can't get the template arguments wrong in the member-template case). Fixes <rdar://problem/9676205>. Reinstated, now that we have the fix in r143967. llvm-svn: 143968
2011-11-08 01:43:18 +08:00
// Check whether we're in the process of instantiating a member class.
if (isInstantiationOf(Record, InstRecord))
return InstRecord;
Teach Sema::FindInstantiatedDecl to find instantiated RecordDecls even when we are not instantiating the corresponding "current instantiation." This happens, e.g., when we are instantiating a declaration reference that refers into the "current instantiation" but occurs in a default function argument. The libstdc++ vector default constructor now instantiates properly. llvm-svn: 82069
2009-09-17 02:34:49 +08:00
}
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
Drastically simplify the mapping from the declaration corresponding to the injected-class-name of a class (or class template) to the declaration that results from substituting the given template arguments. Previously, we would actually perform a substitution into the injected-class-name type and then retrieve the resulting declaration. However, in certain, rare circumstances involving deeply-nested member templates, we would get the wrong substitution arguments. This new approach just matches up the declaration with a declaration that's part of the current context (or one of its parents), which will either be an instantiation (during template instantiation) or the declaration itself (during the definition of the template). This is both more efficient (we're avoiding a substitution) and more correct (we can't get the template arguments wrong in the member-template case). Fixes <rdar://problem/9676205>. Reinstated, now that we have the fix in r143967. llvm-svn: 143968
2011-11-08 01:43:18 +08:00
// Move to the outer template scope.
if (FunctionDecl *FD = dyn_cast<FunctionDecl>(DC)) {
if (FD->getFriendObjectKind() && FD->getDeclContext()->isFileContext()){
DC = FD->getLexicalDeclContext();
continue;
}
[c++1z] Synthesize implicit deduction guides from constructors on demand. Rank such guides below explicit ones, and ensure that references to the class's template parameters are not treated as forwarding references. We make a few tweaks to the wording in the current standard: 1) The constructor parameter list is copied faithfully to the deduction guide, without losing default arguments or a varargs ellipsis (which the standard wording loses by omission). 2) If the class template declares no constructors, we add a T() -> T<...> guide (which will only ever work if T has default arguments for all non-pack template parameters). 3) If the class template declares nothing that looks like a copy or move constructor, we add a T(T<...>) -> T<...> guide. #2 and #3 follow from the "pretend we had a class type with these constructors" philosophy for deduction guides. llvm-svn: 295007
2017-02-14 08:25:28 +08:00
// An implicit deduction guide acts as if it's within the class template
// specialization described by its name and first N template params.
Add an explicit derived class of FunctionDecl to model deduction guides rather than just treating them as FunctionDecls with a funny name. No functionality change intended. llvm-svn: 295491
2017-02-18 04:05:37 +08:00
auto *Guide = dyn_cast<CXXDeductionGuideDecl>(FD);
if (Guide && Guide->isImplicit()) {
TemplateDecl *TD = Guide->getDeducedTemplate();
Fix lookup through injected-class-names in implicit deduction guides in the case where the class template has a parameter pack. Checking of the template arguments expects an "as-written" template argument list, which in particular does not have any parameter packs. So flatten the packs into separate arguments before passing them in. llvm-svn: 295710
2017-02-21 16:42:39 +08:00
// Convert the arguments to an "as-written" list.
[c++1z] Synthesize implicit deduction guides from constructors on demand. Rank such guides below explicit ones, and ensure that references to the class's template parameters are not treated as forwarding references. We make a few tweaks to the wording in the current standard: 1) The constructor parameter list is copied faithfully to the deduction guide, without losing default arguments or a varargs ellipsis (which the standard wording loses by omission). 2) If the class template declares no constructors, we add a T() -> T<...> guide (which will only ever work if T has default arguments for all non-pack template parameters). 3) If the class template declares nothing that looks like a copy or move constructor, we add a T(T<...>) -> T<...> guide. #2 and #3 follow from the "pretend we had a class type with these constructors" philosophy for deduction guides. llvm-svn: 295007
2017-02-14 08:25:28 +08:00
TemplateArgumentListInfo Args(Loc, Loc);
Fix lookup through injected-class-names in implicit deduction guides in the case where the class template has a parameter pack. Checking of the template arguments expects an "as-written" template argument list, which in particular does not have any parameter packs. So flatten the packs into separate arguments before passing them in. llvm-svn: 295710
2017-02-21 16:42:39 +08:00
for (TemplateArgument Arg : TemplateArgs.getInnermost().take_front(
TD->getTemplateParameters()->size())) {
ArrayRef<TemplateArgument> Unpacked(Arg);
if (Arg.getKind() == TemplateArgument::Pack)
Unpacked = Arg.pack_elements();
for (TemplateArgument UnpackedArg : Unpacked)
Args.addArgument(
getTrivialTemplateArgumentLoc(UnpackedArg, QualType(), Loc));
}
[c++1z] Synthesize implicit deduction guides from constructors on demand. Rank such guides below explicit ones, and ensure that references to the class's template parameters are not treated as forwarding references. We make a few tweaks to the wording in the current standard: 1) The constructor parameter list is copied faithfully to the deduction guide, without losing default arguments or a varargs ellipsis (which the standard wording loses by omission). 2) If the class template declares no constructors, we add a T() -> T<...> guide (which will only ever work if T has default arguments for all non-pack template parameters). 3) If the class template declares nothing that looks like a copy or move constructor, we add a T(T<...>) -> T<...> guide. #2 and #3 follow from the "pretend we had a class type with these constructors" philosophy for deduction guides. llvm-svn: 295007
2017-02-14 08:25:28 +08:00
QualType T = CheckTemplateIdType(TemplateName(TD), Loc, Args);
if (T.isNull())
return nullptr;
Fix a couple of class template argument deduction crashes with libc++'s tuple. RecursiveASTVisitor was not properly recursing through a SubstTemplateTypeParmTypes, resulting in crashes in pack expansion where we couldn't always find an unexpanded pack within a pack expansion. We also have an issue where substitution of deduced template arguments for an implicit deduction guide creates the "impossible" case of naming a non-dependent member of the current instantiation, but within a specialization that is actually instantiated from a different (partial/explicit) specialization of the template. We resolve this by declaring that constructors that do so can only be used to deduce specializations of the primary template. I'm running this past CWG to see if people agree this is the right thing to do. llvm-svn: 304862
2017-06-07 10:42:27 +08:00
auto *SubstRecord = T->getAsCXXRecordDecl();
assert(SubstRecord && "class template id not a class type?");
// Check that this template-id names the primary template and not a
// partial or explicit specialization. (In the latter cases, it's
// meaningless to attempt to find an instantiation of D within the
// specialization.)
// FIXME: The standard doesn't say what should happen here.
Weaken restriction in r304862 to allow implicit deduction guides to reference the injected-class-name of a specialization that uses a partial / explicit specialization. llvm-svn: 304957
2017-06-08 09:08:50 +08:00
if (FindingInstantiatedContext &&
usesPartialOrExplicitSpecialization(
Loc, cast<ClassTemplateSpecializationDecl>(SubstRecord))) {
Fix a couple of class template argument deduction crashes with libc++'s tuple. RecursiveASTVisitor was not properly recursing through a SubstTemplateTypeParmTypes, resulting in crashes in pack expansion where we couldn't always find an unexpanded pack within a pack expansion. We also have an issue where substitution of deduced template arguments for an implicit deduction guide creates the "impossible" case of naming a non-dependent member of the current instantiation, but within a specialization that is actually instantiated from a different (partial/explicit) specialization of the template. We resolve this by declaring that constructors that do so can only be used to deduce specializations of the primary template. I'm running this past CWG to see if people agree this is the right thing to do. llvm-svn: 304862
2017-06-07 10:42:27 +08:00
Diag(Loc, diag::err_specialization_not_primary_template)
<< T << (SubstRecord->getTemplateSpecializationKind() ==
TSK_ExplicitSpecialization);
return nullptr;
}
DC = SubstRecord;
[c++1z] Synthesize implicit deduction guides from constructors on demand. Rank such guides below explicit ones, and ensure that references to the class's template parameters are not treated as forwarding references. We make a few tweaks to the wording in the current standard: 1) The constructor parameter list is copied faithfully to the deduction guide, without losing default arguments or a varargs ellipsis (which the standard wording loses by omission). 2) If the class template declares no constructors, we add a T() -> T<...> guide (which will only ever work if T has default arguments for all non-pack template parameters). 3) If the class template declares nothing that looks like a copy or move constructor, we add a T(T<...>) -> T<...> guide. #2 and #3 follow from the "pretend we had a class type with these constructors" philosophy for deduction guides. llvm-svn: 295007
2017-02-14 08:25:28 +08:00
continue;
}
Fix the breakage by handling indirect instantiations. This would be much improved if there were a consistent name for getInstantiatedFromMemberX() across all classes. Cheap refactor if someone wants to do it, but let's get the buildbots happy first. llvm-svn: 80425
2009-08-29 16:11:13 +08:00
}
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
Drastically simplify the mapping from the declaration corresponding to the injected-class-name of a class (or class template) to the declaration that results from substituting the given template arguments. Previously, we would actually perform a substitution into the injected-class-name type and then retrieve the resulting declaration. However, in certain, rare circumstances involving deeply-nested member templates, we would get the wrong substitution arguments. This new approach just matches up the declaration with a declaration that's part of the current context (or one of its parents), which will either be an instantiation (during template instantiation) or the declaration itself (during the definition of the template). This is both more efficient (we're avoiding a substitution) and more correct (we can't get the template arguments wrong in the member-template case). Fixes <rdar://problem/9676205>. Reinstated, now that we have the fix in r143967. llvm-svn: 143968
2011-11-08 01:43:18 +08:00
DC = DC->getParent();
Fix the breakage by handling indirect instantiations. This would be much improved if there were a consistent name for getInstantiatedFromMemberX() across all classes. Cheap refactor if someone wants to do it, but let's get the buildbots happy first. llvm-svn: 80425
2009-08-29 16:11:13 +08:00
}
Cope with finding the "instantiated" declaration when we are type-checking within a template definition. In this case, the "instantiated" declaration is just the declaration itself, found within the current instantiation. Fixes PR6239. llvm-svn: 95442
2010-02-06 06:40:03 +08:00
Teach Sema::FindInstantiatedDecl to find instantiated RecordDecls even when we are not instantiating the corresponding "current instantiation." This happens, e.g., when we are instantiating a declaration reference that refers into the "current instantiation" but occurs in a default function argument. The libstdc++ vector default constructor now instantiates properly. llvm-svn: 82069
2009-09-17 02:34:49 +08:00
// Fall through to deal with other dependent record types (e.g.,
// anonymous unions in class templates).
}
Fix the breakage by handling indirect instantiations. This would be much improved if there were a consistent name for getInstantiatedFromMemberX() across all classes. Cheap refactor if someone wants to do it, but let's get the buildbots happy first. llvm-svn: 80425
2009-08-29 16:11:13 +08:00
Teach Sema::FindInstantiatedDecl to find instantiated RecordDecls even when we are not instantiating the corresponding "current instantiation." This happens, e.g., when we are instantiating a declaration reference that refers into the "current instantiation" but occurs in a default function argument. The libstdc++ vector default constructor now instantiates properly. llvm-svn: 82069
2009-09-17 02:34:49 +08:00
if (!ParentDC->isDependentContext())
return D;
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
When looking for the instantiated declaration that corresponds to a given declaration in a template, make sure that the context we're searching through is complete. Fixes PR6376. llvm-svn: 97444
2010-03-01 23:56:25 +08:00
ParentDC = FindInstantiatedContext(Loc, ParentDC, TemplateArgs);
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
if (!ParentDC)
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Initial stab at a generalized operation for determining the instantiation of a declaration from the template version (or version that lives in a template) and a given set of template arguments. This needs much, much more testing, but it suffices for simple examples like typedef T* iterator; iterator begin(); llvm-svn: 72461
2009-05-27 13:35:12 +08:00
if (ParentDC != D->getDeclContext()) {
// We performed some kind of instantiation in the parent context,
// so now we need to look into the instantiated parent context to
// find the instantiation of the declaration D.
When looking for the instantiated declaration that corresponds to a given declaration in a template, make sure that the context we're searching through is complete. Fixes PR6376. llvm-svn: 97444
2010-03-01 23:56:25 +08:00
Create a new InjectedClassNameType to represent bare-word references to the injected class name of a class template or class template partial specialization. This is a non-canonical type; the canonical type is still a template specialization type. This becomes the TypeForDecl of the pattern declaration, which cleans up some amount of code (and complicates some other parts, but whatever). Fixes PR6326 and probably a few others, primarily by re-establishing a few invariants about TypeLoc sizes. llvm-svn: 98134
2010-03-10 11:28:59 +08:00
// If our context used to be dependent, we may need to instantiate
// it before performing lookup into that context.
We may fail to map a declaration in a template to its instantiated declaration because of interesting ordering dependencies while instantiating a class template or member class thereof. Complain, rather than asserting (+Asserts) or silently rejecting the code (-Asserts). Fixes the crash-on-invalid in PR8965. llvm-svn: 127129
2011-03-07 04:12:45 +08:00
bool IsBeingInstantiated = false;
Create a new InjectedClassNameType to represent bare-word references to the injected class name of a class template or class template partial specialization. This is a non-canonical type; the canonical type is still a template specialization type. This becomes the TypeForDecl of the pattern declaration, which cleans up some amount of code (and complicates some other parts, but whatever). Fixes PR6326 and probably a few others, primarily by re-establishing a few invariants about TypeLoc sizes. llvm-svn: 98134
2010-03-10 11:28:59 +08:00
if (CXXRecordDecl *Spec = dyn_cast<CXXRecordDecl>(ParentDC)) {
When looking for the instantiated declaration that corresponds to a given declaration in a template, make sure that the context we're searching through is complete. Fixes PR6376. llvm-svn: 97444
2010-03-01 23:56:25 +08:00
if (!Spec->isDependentContext()) {
QualType T = Context.getTypeDeclType(Spec);
Create a new InjectedClassNameType to represent bare-word references to the injected class name of a class template or class template partial specialization. This is a non-canonical type; the canonical type is still a template specialization type. This becomes the TypeForDecl of the pattern declaration, which cleans up some amount of code (and complicates some other parts, but whatever). Fixes PR6326 and probably a few others, primarily by re-establishing a few invariants about TypeLoc sizes. llvm-svn: 98134
2010-03-10 11:28:59 +08:00
const RecordType *Tag = T->getAs<RecordType>();
assert(Tag && "type of non-dependent record is not a RecordType");
We may fail to map a declaration in a template to its instantiated declaration because of interesting ordering dependencies while instantiating a class template or member class thereof. Complain, rather than asserting (+Asserts) or silently rejecting the code (-Asserts). Fixes the crash-on-invalid in PR8965. llvm-svn: 127129
2011-03-07 04:12:45 +08:00
if (Tag->isBeingDefined())
IsBeingInstantiated = true;
Create a new InjectedClassNameType to represent bare-word references to the injected class name of a class template or class template partial specialization. This is a non-canonical type; the canonical type is still a template specialization type. This becomes the TypeForDecl of the pattern declaration, which cleans up some amount of code (and complicates some other parts, but whatever). Fixes PR6326 and probably a few others, primarily by re-establishing a few invariants about TypeLoc sizes. llvm-svn: 98134
2010-03-10 11:28:59 +08:00
if (!Tag->isBeingDefined() &&
RequireCompleteType(Loc, T, diag::err_incomplete_type))
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
When searching for an instantiated declaration requires instantiation of its parent context, be sure to update the parent-context pointer after instantiation. Fixes two anonymous-union instantiation issues in <rdar://problem/8635664>. llvm-svn: 118313
2010-11-06 07:22:45 +08:00
ParentDC = Tag->getDecl();
When looking for the instantiated declaration that corresponds to a given declaration in a template, make sure that the context we're searching through is complete. Fixes PR6376. llvm-svn: 97444
2010-03-01 23:56:25 +08:00
}
}
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
NamedDecl *Result = nullptr;
[c++1z] P0195R2: Support pack-expansion of using-declarations. This change introduces UsingPackDecl as a marker for the set of UsingDecls produced by pack expansion of a single (unresolved) using declaration. This is not strictly necessary (we just need to be able to map from the original using declaration to its expansions somehow), but it's useful to maintain the invariant that each declaration reference instantiates to refer to one declaration. This is a re-commit of r290080 (reverted in r290092) with a fix for a use-after-lifetime bug. llvm-svn: 290203
2016-12-21 05:35:28 +08:00
// FIXME: If the name is a dependent name, this lookup won't necessarily
// find it. Does that ever matter?
[Sema] Transform a templated name before looking it up in FindInstantiatedDecl or passing it to RebuildMemberExpr. This fixes PR30361. rdar://problem/17341274 Differential Revision: https://reviews.llvm.org/D24969 llvm-svn: 293678
2017-02-01 03:53:32 +08:00
if (auto Name = D->getDeclName()) {
DeclarationNameInfo NameInfo(Name, D->getLocation());
Name = SubstDeclarationNameInfo(NameInfo, TemplateArgs).getName();
if (!Name)
return nullptr;
DeclContext::lookup_result Found = ParentDC->lookup(Name);
Change DeclContextLookup(Const)Result to (Mutable)ArrayRef<NamedDecl*>, as per review discussion in r170365 This does limit these typedefs to being sequences, but no current usage requires them to be contiguous (we could expand this to a more general iterator pair range concept at some point). Also, it'd be nice if SmallVector were constructible directly from an ArrayRef but this is a bit tricky since ArrayRef depends on SmallVectorBaseImpl for the inverse conversion. (& generalizing over all range-like things, while nice, would require some nontrivial SFINAE I haven't thought about yet) llvm-svn: 170482
2012-12-19 08:45:41 +08:00
Result = findInstantiationOf(Context, D, Found.begin(), Found.end());
Initial stab at a generalized operation for determining the instantiation of a declaration from the template version (or version that lives in a template) and a given set of template arguments. This needs much, much more testing, but it suffices for simple examples like typedef T* iterator; iterator begin(); llvm-svn: 72461
2009-05-27 13:35:12 +08:00
} else {
// Since we don't have a name for the entity we're looking for,
// our only option is to walk through all of the declarations to
// find that name. This will occur in a few cases:
//
// - anonymous struct/union within a template
// - unnamed class/struct/union/enum within a template
//
// FIXME: Find a better way to find these instantiations!
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Result = findInstantiationOf(Context, D,
De-ASTContext-ify DeclContext. Remove ASTContext parameter from DeclContext's methods. This change cascaded down to other Decl's methods and changes to call sites started "escalating". Timings using pre-tokenized "cocoa.h" showed only a ~1% increase in time run between and after this commit. llvm-svn: 74506
2009-06-30 10:36:12 +08:00
ParentDC->decls_begin(),
ParentDC->decls_end());
Initial stab at a generalized operation for determining the instantiation of a declaration from the template version (or version that lives in a template) and a given set of template arguments. This needs much, much more testing, but it suffices for simple examples like typedef T* iterator; iterator begin(); llvm-svn: 72461
2009-05-27 13:35:12 +08:00
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
We may fail to map a declaration in a template to its instantiated declaration because of interesting ordering dependencies while instantiating a class template or member class thereof. Complain, rather than asserting (+Asserts) or silently rejecting the code (-Asserts). Fixes the crash-on-invalid in PR8965. llvm-svn: 127129
2011-03-07 04:12:45 +08:00
if (!Result) {
if (isa<UsingShadowDecl>(D)) {
// UsingShadowDecls can instantiate to nothing because of using hiding.
} else if (Diags.hasErrorOccurred()) {
// We've already complained about something, so most likely this
// declaration failed to instantiate. There's no point in complaining
// further, since this is normal in invalid code.
} else if (IsBeingInstantiated) {
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
// The class in which this member exists is currently being
We may fail to map a declaration in a template to its instantiated declaration because of interesting ordering dependencies while instantiating a class template or member class thereof. Complain, rather than asserting (+Asserts) or silently rejecting the code (-Asserts). Fixes the crash-on-invalid in PR8965. llvm-svn: 127129
2011-03-07 04:12:45 +08:00
// instantiated, and we haven't gotten around to instantiating this
// member yet. This can happen when the code uses forward declarations
// of member classes, and introduces ordering dependencies via
// template instantiation.
Diag(Loc, diag::err_member_not_yet_instantiated)
<< D->getDeclName()
<< Context.getTypeDeclType(cast<CXXRecordDecl>(ParentDC));
Diag(D->getLocation(), diag::note_non_instantiated_member_here);
Add a special-case diagnostic for one of the more obnoxious special cases of unscoped enumeration members: an enumerator name which is visible in the out-of-class definition of a member of a templated class might not actually exist in the instantiation of that class, if the enumeration is also lexically defined outside the class definition and is explicitly specialized. Depending on the result of a CWG discussion, we may have a different resolution for a class of problems in this area, but this fixes the immediate issue of a crash-on-invalid / accepts-invalid (depending on +Asserts). Thanks to Johannes Schaub for digging into the standard wording to find how this case is currently specified to behave. llvm-svn: 153461
2012-03-27 04:28:16 +08:00
} else if (EnumConstantDecl *ED = dyn_cast<EnumConstantDecl>(D)) {
// This enumeration constant was found when the template was defined,
// but can't be found in the instantiation. This can happen if an
// unscoped enumeration member is explicitly specialized.
EnumDecl *Enum = cast<EnumDecl>(ED->getLexicalDeclContext());
EnumDecl *Spec = cast<EnumDecl>(FindInstantiatedDecl(Loc, Enum,
TemplateArgs));
assert(Spec->getTemplateSpecializationKind() ==
TSK_ExplicitSpecialization);
Diag(Loc, diag::err_enumerator_does_not_exist)
<< D->getDeclName()
<< Context.getTypeDeclType(cast<TypeDecl>(Spec->getDeclContext()));
Diag(Spec->getLocation(), diag::note_enum_specialized_here)
<< Context.getTypeDeclType(Spec);
We may fail to map a declaration in a template to its instantiated declaration because of interesting ordering dependencies while instantiating a class template or member class thereof. Complain, rather than asserting (+Asserts) or silently rejecting the code (-Asserts). Fixes the crash-on-invalid in PR8965. llvm-svn: 127129
2011-03-07 04:12:45 +08:00
} else {
// We should have found something, but didn't.
llvm_unreachable("Unable to find instantiation of declaration!");
}
}
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Initial stab at a generalized operation for determining the instantiation of a declaration from the template version (or version that lives in a template) and a given set of template arguments. This needs much, much more testing, but it suffices for simple examples like typedef T* iterator; iterator begin(); llvm-svn: 72461
2009-05-27 13:35:12 +08:00
D = Result;
}
return D;
}
Implement implicit instantiation of the member functions of a class template specialization. At present, all implicit instantiations occur at the end of the translation unit. llvm-svn: 73915
2009-06-23 07:06:13 +08:00
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
/// \brief Performs template instantiation for all implicit template
Implement implicit instantiation of the member functions of a class template specialization. At present, all implicit instantiations occur at the end of the translation unit. llvm-svn: 73915
2009-06-23 07:06:13 +08:00
/// instantiations we have seen until this point.
Whenever we instantiate a static data member, make sure to define any new vtables! Fixes PR10020 This also allows us to revert the part of r130023 which added a big loop around the template instantiation. llvm-svn: 132331
2011-05-31 15:58:42 +08:00
void Sema::PerformPendingInstantiations(bool LocalOnly) {
Introduce a second queue of "local" pending implicit instantiation, which are instantiations of the member functions of local classes. These implicit instantiations have to occur at the same time as---and in the same local instantiation scope as---the enclosing function, since the member functions of the local class can refer to locals within the enclosing function. This should really, really fix PR5764. llvm-svn: 93666
2010-01-17 06:29:39 +08:00
while (!PendingLocalImplicitInstantiations.empty() ||
Rename *PendingImplicitInstantiations to *PendingInstantiations. No functionality changed. llvm-svn: 112040
2010-08-25 16:44:16 +08:00
(!LocalOnly && !PendingInstantiations.empty())) {
Introduce a second queue of "local" pending implicit instantiation, which are instantiations of the member functions of local classes. These implicit instantiations have to occur at the same time as---and in the same local instantiation scope as---the enclosing function, since the member functions of the local class can refer to locals within the enclosing function. This should really, really fix PR5764. llvm-svn: 93666
2010-01-17 06:29:39 +08:00
PendingImplicitInstantiation Inst;
if (PendingLocalImplicitInstantiations.empty()) {
Rename *PendingImplicitInstantiations to *PendingInstantiations. No functionality changed. llvm-svn: 112040
2010-08-25 16:44:16 +08:00
Inst = PendingInstantiations.front();
PendingInstantiations.pop_front();
Introduce a second queue of "local" pending implicit instantiation, which are instantiations of the member functions of local classes. These implicit instantiations have to occur at the same time as---and in the same local instantiation scope as---the enclosing function, since the member functions of the local class can refer to locals within the enclosing function. This should really, really fix PR5764. llvm-svn: 93666
2010-01-17 06:29:39 +08:00
} else {
Inst = PendingLocalImplicitInstantiations.front();
PendingLocalImplicitInstantiations.pop_front();
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Template instantiation for static data members that are defined out-of-line. Note that this also fixes a bug that affects non-template code, where we were not treating out-of-line static data members are "file-scope" variables, and therefore not checking their initializers. llvm-svn: 77002
2009-07-25 04:34:43 +08:00
// Instantiate function definitions
if (FunctionDecl *Function = dyn_cast<FunctionDecl>(Inst.first)) {
Support explicit instantiation of function templates and members of class templates when only the declaration is in scope. This requires deferring the instantiation to be lazy, and ensuring the definition is required for that translation unit. We re-use the existing pending instantiation queue, previously only used to track implicit instantiations which were required to be lazy. Fixes PR7979. A subsequent change will rename *PendingImplicitInstantiations to *PendingInstatiations for clarity given its broader role. llvm-svn: 112037
2010-08-25 16:27:02 +08:00
bool DefinitionRequired = Function->getTemplateSpecializationKind() ==
TSK_ExplicitInstantiationDefinition;
InstantiateFunctionDefinition(/*FIXME:*/Inst.second, Function, true,
Warn if function or variable cannot be implicitly instantiated With this patch compiler emits warning if it tries to make implicit instantiation of a template but cannot find the template definition. The warning can be suppressed by explicit instantiation declaration or by command line options -Wundefined-var-template and -Wundefined-func-template. The implementation follows the discussion of http://reviews.llvm.org/D12326. Differential Revision: http://reviews.llvm.org/D16396 llvm-svn: 266719
2016-04-19 14:19:52 +08:00
DefinitionRequired, true);
Template instantiation for static data members that are defined out-of-line. Note that this also fixes a bug that affects non-template code, where we were not treating out-of-line static data members are "file-scope" variables, and therefore not checking their initializers. llvm-svn: 77002
2009-07-25 04:34:43 +08:00
continue;
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
// Instantiate variable definitions
Template instantiation for static data members that are defined out-of-line. Note that this also fixes a bug that affects non-template code, where we were not treating out-of-line static data members are "file-scope" variables, and therefore not checking their initializers. llvm-svn: 77002
2009-07-25 04:34:43 +08:00
VarDecl *Var = cast<VarDecl>(Inst.first);
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
assert((Var->isStaticDataMember() ||
isa<VarTemplateSpecializationDecl>(Var)) &&
"Not a static data member, nor a variable template"
" specialization?");
Add pretty stack traces when instantiating functions and static data members. llvm-svn: 80661
2009-09-01 13:12:24 +08:00
Skip implicit instantiation of templated variables where a more recent redeclaration provides an explicit instantiation or is invalid. llvm-svn: 96097
2010-02-13 18:17:50 +08:00
// Don't try to instantiate declarations if the most recent redeclaration
// is invalid.
De-virtualize getPreviousDecl() and getMostRecentDecl() when we know we have a redeclarable type, and only use the new virtual versions (getPreviousDeclImpl() and getMostRecentDeclImpl()) when we don't have that type information. This keeps us from penalizing users with strict type information (and is the moral equivalent of a "final" method). Plus, settle on the names getPreviousDecl() and getMostRecentDecl() throughout. llvm-svn: 148187
2012-01-15 00:38:05 +08:00
if (Var->getMostRecentDecl()->isInvalidDecl())
Skip implicit instantiation of templated variables where a more recent redeclaration provides an explicit instantiation or is invalid. llvm-svn: 96097
2010-02-13 18:17:50 +08:00
continue;
// Check if the most recent declaration has changed the specialization kind
// and removed the need for implicit instantiation.
De-virtualize getPreviousDecl() and getMostRecentDecl() when we know we have a redeclarable type, and only use the new virtual versions (getPreviousDeclImpl() and getMostRecentDeclImpl()) when we don't have that type information. This keeps us from penalizing users with strict type information (and is the moral equivalent of a "final" method). Plus, settle on the names getPreviousDecl() and getMostRecentDecl() throughout. llvm-svn: 148187
2012-01-15 00:38:05 +08:00
switch (Var->getMostRecentDecl()->getTemplateSpecializationKind()) {
Skip implicit instantiation of templated variables where a more recent redeclaration provides an explicit instantiation or is invalid. llvm-svn: 96097
2010-02-13 18:17:50 +08:00
case TSK_Undeclared:
Switch assert(0/false) llvm_unreachable. llvm-svn: 140367
2011-09-23 13:06:16 +08:00
llvm_unreachable("Cannot instantitiate an undeclared specialization.");
Skip implicit instantiation of templated variables where a more recent redeclaration provides an explicit instantiation or is invalid. llvm-svn: 96097
2010-02-13 18:17:50 +08:00
case TSK_ExplicitInstantiationDeclaration:
case TSK_ExplicitSpecialization:
Support explicit instantiation of function templates and members of class templates when only the declaration is in scope. This requires deferring the instantiation to be lazy, and ensuring the definition is required for that translation unit. We re-use the existing pending instantiation queue, previously only used to track implicit instantiations which were required to be lazy. Fixes PR7979. A subsequent change will rename *PendingImplicitInstantiations to *PendingInstatiations for clarity given its broader role. llvm-svn: 112037
2010-08-25 16:27:02 +08:00
continue; // No longer need to instantiate this type.
case TSK_ExplicitInstantiationDefinition:
// We only need an instantiation if the pending instantiation *is* the
// explicit instantiation.
De-virtualize getPreviousDecl() and getMostRecentDecl() when we know we have a redeclarable type, and only use the new virtual versions (getPreviousDeclImpl() and getMostRecentDeclImpl()) when we don't have that type information. This keeps us from penalizing users with strict type information (and is the moral equivalent of a "final" method). Plus, settle on the names getPreviousDecl() and getMostRecentDecl() throughout. llvm-svn: 148187
2012-01-15 00:38:05 +08:00
if (Var != Var->getMostRecentDecl()) continue;
Skip implicit instantiation of templated variables where a more recent redeclaration provides an explicit instantiation or is invalid. llvm-svn: 96097
2010-02-13 18:17:50 +08:00
case TSK_ImplicitInstantiation:
break;
}
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
PrettyDeclStackTraceEntry CrashInfo(*this, Var, SourceLocation(),
"instantiating variable definition");
Support explicit instantiation of function templates and members of class templates when only the declaration is in scope. This requires deferring the instantiation to be lazy, and ensuring the definition is required for that translation unit. We re-use the existing pending instantiation queue, previously only used to track implicit instantiations which were required to be lazy. Fixes PR7979. A subsequent change will rename *PendingImplicitInstantiations to *PendingInstatiations for clarity given its broader role. llvm-svn: 112037
2010-08-25 16:27:02 +08:00
bool DefinitionRequired = Var->getTemplateSpecializationKind() ==
TSK_ExplicitInstantiationDefinition;
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
// Instantiate static data member definitions or variable template
// specializations.
InstantiateVariableDefinition(/*FIXME:*/ Inst.second, Var, true,
Warn if function or variable cannot be implicitly instantiated With this patch compiler emits warning if it tries to make implicit instantiation of a template but cannot find the template definition. The warning can be suppressed by explicit instantiation declaration or by command line options -Wundefined-var-template and -Wundefined-func-template. The implementation follows the discussion of http://reviews.llvm.org/D12326. Differential Revision: http://reviews.llvm.org/D16396 llvm-svn: 266719
2016-04-19 14:19:52 +08:00
DefinitionRequired, true);
Implement implicit instantiation of the member functions of a class template specialization. At present, all implicit instantiations occur at the end of the translation unit. llvm-svn: 73915
2009-06-23 07:06:13 +08:00
}
}
Implement a framework for the delay of arbitrary diagnostics within templates. So delay access-control diagnostics when (for example) the target of a friend declaration is a specific specialization of a template. I was surprised to find that this was required for an access-controlled selfhost. llvm-svn: 99383
2010-03-24 13:22:00 +08:00
void Sema::PerformDependentDiagnostics(const DeclContext *Pattern,
const MultiLevelTemplateArgumentList &TemplateArgs) {
[C++11] Replacing iterators ddiag_begin() and ddiag_end() with iterator_range ddiags(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203240
2014-03-07 22:09:15 +08:00
for (auto DD : Pattern->ddiags()) {
Implement a framework for the delay of arbitrary diagnostics within templates. So delay access-control diagnostics when (for example) the target of a friend declaration is a specific specialization of a template. I was surprised to find that this was required for an access-controlled selfhost. llvm-svn: 99383
2010-03-24 13:22:00 +08:00
switch (DD->getKind()) {
case DependentDiagnostic::Access:
HandleDependentAccessCheck(*DD, TemplateArgs);
break;
}
}
}