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

4502 lines
175 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"
#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"
Implement support for C++ direct initializers that involve dependent types or type-dependent expressions. llvm-svn: 80143
2009-08-27 05:14:46 +08:00
#include "clang/Lex/Preprocessor.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;
}
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 DeclaratorDecl *OldDecl,
DeclaratorDecl *NewDecl) {
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
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
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
= SemaRef.SubstNestedNameSpecifierLoc(OldDecl->getQualifierLoc(),
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
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;
}
bool TemplateDeclInstantiator::SubstQualifier(const TagDecl *OldDecl,
TagDecl *NewDecl) {
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
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
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
= SemaRef.SubstNestedNameSpecifierLoc(OldDecl->getQualifierLoc(),
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
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;
}
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.
EnterExpressionEvaluationContext Unevaluated(S, Sema::ConstantEvaluated);
ExprResult Result = S.SubstExpr(Aligned->getAlignmentExpr(), TemplateArgs);
if (!Result.isInvalid())
S.AddAlignedAttr(Aligned->getLocation(), New, Result.takeAs<Expr>(),
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);
}
}
}
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) {
Generate Attr subclasses with TableGen. Now all classes derived from Attr are generated from TableGen. Additionally, Attr* is no longer its own linked list; SmallVectors or Attr* are used. The accompanying LLVM commit contains the updates to TableGen necessary for this. Some other notes about newly-generated attribute classes: - The constructor arguments are a SourceLocation and a Context&, followed by the attributes arguments in the order that they were defined in Attr.td - Every argument in Attr.td has an appropriate accessor named getFoo, and there are sometimes a few extra ones (such as to get the length of a variadic argument). Additionally, specific_attr_iterator has been introduced, which will iterate over an AttrVec, but only over attributes of a certain type. It can be accessed through either Decl::specific_attr_begin/end or the global functions of the same name. llvm-svn: 111455
2010-08-19 07:23:40 +08:00
for (AttrVec::const_iterator i = Tmpl->attr_begin(), e = Tmpl->attr_end();
i != e; ++i) {
const Attr *TmplAttr = *i;
Delayed template instantiation of late-parsed attributes. llvm-svn: 148595
2012-01-21 06:50:54 +08:00
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
}
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.
LocalInstantiationScope *Saved = 0;
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);
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
if (NewAttr)
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
}
}
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
}
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
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 (TypedefNameDecl *Prev = D->getPreviousDecl()) {
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)
return 0;
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);
Owner->addDecl(Typedef);
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);
Owner->addDecl(Typedef);
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)
return 0;
TypeAliasDecl *Pattern = D->getTemplatedDecl();
TypeAliasTemplateDecl *PrevAliasTemplate = 0;
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 (Pattern->getPreviousDecl()) {
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)
return 0;
TypeAliasTemplateDecl *Inst
= TypeAliasTemplateDecl::Create(SemaRef.Context, Owner, D->getLocation(),
D->getDeclName(), InstParams, AliasInst);
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
}
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,
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
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 this is the variable for an anonymous struct or union,
// instantiate the anonymous struct/union type first.
if (const RecordType *RecordTy = D->getType()->getAs<RecordType>())
if (RecordTy->getDecl()->isAnonymousStructOrUnion())
if (!VisitCXXRecordDecl(cast<CXXRecordDecl>(RecordTy->getDecl())))
return 0;
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
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 = SemaRef.SubstType(D->getTypeSourceInfo(),
Preserve source information when substituting into VarDecls. llvm-svn: 84733
2009-10-21 10:39:02 +08:00
TemplateArgs,
D->getTypeSpecStartLoc(),
D->getDeclName());
if (!DI)
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 0;
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();
return 0;
}
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.
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
VarDecl *Var = VarDecl::Create(SemaRef.Context, DC, D->getInnerLocStart(),
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
D->getLocation(), D->getIdentifier(),
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
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))
return 0;
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);
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)
BitWidth = 0;
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.
EnterExpressionEvaluationContext Unevaluated(SemaRef,
Sema::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;
BitWidth = 0;
} else
Replace more release+static_cast with takeAs. llvm-svn: 70567
2009-05-02 03:49:17 +08:00
BitWidth = InstantiatedBitWidth.takeAs<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(),
0);
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();
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
return 0;
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)
<< D->getName();
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;
for (IndirectFieldDecl::chain_iterator PI =
D->chain_begin(), PE = D->chain_end();
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
PI != PE; ++PI) {
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +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)
return 0;
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();
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
IndirectFieldDecl* IndirectField
= IndirectFieldDecl::Create(SemaRef.Context, Owner, D->getLocation(),
Fix PR8760: IndirectFieldDecl Type was not updated during template instantiation. llvm-svn: 121363
2010-12-09 18:07:54 +08:00
D->getIdentifier(), T,
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
NamedChain, D->getChainingSize());
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)
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
return 0;
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)
return 0;
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);
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 (!NewND) return 0;
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.
EnterExpressionEvaluationContext Unevaluated(SemaRef,
Sema::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())
return 0;
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) {
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
EnumDecl *PrevDecl = 0;
if (D->getPreviousDecl()) {
NamedDecl *Prev = SemaRef.FindInstantiatedDecl(D->getLocation(),
D->getPreviousDecl(),
TemplateArgs);
if (!Prev) return 0;
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());
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
if (SubstQualifier(D, Enum)) return 0;
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(),
DefnUnderlying, Enum);
}
}
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
EnumConstantDecl *LastEnumConst = 0;
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
for (EnumDecl::enumerator_iterator EC = Pattern->enumerator_begin(),
ECEnd = Pattern->enumerator_end();
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
EC != ECEnd; ++EC) {
// The specified value for the enumerator.
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 Value = SemaRef.Owned((Expr *)0);
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.
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
EnterExpressionEvaluationContext Unevaluated(SemaRef,
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
Sema::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()) {
Value = SemaRef.Owned((Expr *)0);
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) {
Revert Decl's iterators back to pointer value_type rather than reference value_type In addition, I've made the pointer and reference typedef 'void' rather than T* just so they can't get misused. I would've omitted them entirely but std::distance likes them to be there even if it doesn't use them. This rolls back r155808 and r155869. Review by Doug Gregor incorporating feedback from Chandler Carruth. llvm-svn: 158104
2012-06-07 04:45:41 +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.
Revert Decl's iterators back to pointer value_type rather than reference value_type In addition, I've made the pointer and reference typedef 'void' rather than T* just so they can't get misused. I would've omitted them entirely but std::distance likes them to be there even if it doesn't use them. This rolls back r155808 and r155869. Review by Doug Gregor incorporating feedback from Chandler Carruth. llvm-svn: 158104
2012-06-07 04:45:41 +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
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
// FIXME: Fixup LBraceLoc
SemaRef.ActOnEnumBody(Enum->getLocation(), SourceLocation(),
Enum->getRBraceLoc(), Enum,
ArrayRef'ize Sema::ActOnEnumBody. No functionality change. Patch by Robert Wilhelm. llvm-svn: 180682
2013-04-28 04:23:52 +08:00
Enumerators,
Patch should implement packed enums - PR4098. Credit to Anders Johnsen. llvm-svn: 78471
2009-08-08 22:36:57 +08:00
0, 0);
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
}
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)
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 NULL;
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)
return 0;
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 *PrevDecl = 0;
ClassTemplateDecl *PrevClassTemplate = 0;
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 (!isFriend && Pattern->getPreviousDecl()) {
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);
if (!DC) return 0;
} 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();
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
return 0;
}
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")) {
DeclContext *DCParent2 = DCParent->getParent();
if (DCParent2->isNamespace() &&
cast<NamespaceDecl>(DCParent2)->getIdentifier() &&
cast<NamespaceDecl>(DCParent2)->getIdentifier()->isStr("std") &&
DCParent2->getParent()->isTranslationUnit())
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)
return 0;
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))
return 0;
}
}
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(),
D->getIdentifier(), InstParams, RecordInst,
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())
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 0;
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)
return 0;
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)
return NULL;
VarDecl *Pattern = D->getTemplatedDecl();
VarTemplateDecl *PrevVarTemplate = 0;
if (Pattern->getPreviousDecl()) {
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));
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,
VarInst, PrevVarTemplate);
VarInst->setDescribedVarTemplate(Inst);
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)
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 NULL;
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
FunctionDecl *Instantiated = 0;
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)
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 0;
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() &&
!D->getPreviousDecl()) {
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) {
CXXRecordDecl *PrevDecl = 0;
if (D->isInjectedClassName())
PrevDecl = cast<CXXRecordDecl>(Owner);
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
else if (D->getPreviousDecl()) {
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(),
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
D->getPreviousDecl(),
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);
if (!Prev) return 0;
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))
return 0;
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
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()) {
if (SemaRef.InstantiateClass(D->getLocation(), Record, D, TemplateArgs,
TSK_ImplicitInstantiation,
/*Complain=*/true)) {
llvm_unreachable("InstantiateClass shouldn't fail here!");
} else {
SemaRef.InstantiateClassMembers(D->getLocation(), Record, TemplateArgs,
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
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();
return Context.getFunctionType(NewFunc->getResultType(),
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
NewFunc->getArgTypes(), 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
/// FIXME: preserve function definitions in case #2
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
When we form a new function/class template specialization, we first search for the specialization (in a folding set) and, if not found form a *Decl that is then inserted into that folding set. In rare cases, the folding set may be reallocated between the search and the insertion, causing a crash. No test case, because triggering rehashing consistently in a small test case is not feasible. Fixes <rdar://problem/11115071>. llvm-svn: 153575
2012-03-28 22:34:23 +08:00
void *InsertPos = 0;
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
ArrayRef'ize MultiLevelTemplateArgumentList::ArgList. Patch by Faisal Vali! llvm-svn: 181077
2013-05-04 07:46:09 +08:00
= FunctionTemplate->findSpecialization(Innermost.begin(), Innermost.size(),
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
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);
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
bool MergeWithParentScope = (TemplateParams != 0) ||
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)
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 0;
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)
return 0;
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);
if (!DC) return 0;
} 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
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
FunctionDecl *Function =
Fixed source range for all DeclaratorDecl's. llvm-svn: 127225
2011-03-08 16:55:46 +08:00
FunctionDecl::Create(SemaRef.Context, DC, D->getInnerLocStart(),
Fixed instantiated operators source range. llvm-svn: 165258
2012-10-05 05:40:42 +08:00
D->getNameInfo(), T, TInfo,
Correctly propagate the storage class to function template instantiations. This fixes pr15753. This is another case of the fuzzy definition of the "as written" storage class of an instantiation. llvm-svn: 179581
2013-04-16 10:29:15 +08:00
D->getCanonicalDecl()->getStorageClass(),
Track in the AST whether a function is constexpr. llvm-svn: 137653
2011-08-16 05:04:07 +08:00
D->isInlineSpecified(), D->hasWrittenPrototype(),
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());
Fix source range of implicitly instantiated friend declaration. llvm-svn: 186702
2013-07-20 02:02:36 +08:00
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()) {
// TODO: should we remember this connection regardless of whether
// the friend declaration provided a body?
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,
ArrayRef'ize MultiLevelTemplateArgumentList::ArgList. Patch by Faisal Vali! llvm-svn: 181077
2013-05-04 07:46:09 +08:00
Innermost.begin(),
Innermost.size()),
When we form a new function/class template specialization, we first search for the specialization (in a folding set) and, if not found form a *Decl that is then inserted into that folding set. In rare cases, the folding set may be reallocated between the search and the insertion, causing a crash. No test case, because triggering rehashing consistently in a small test case is not feasible. Fixes <rdar://problem/11115071>. llvm-svn: 153575
2012-03-28 22:34:23 +08:00
/*InsertPos=*/0);
Always mark friend function declarations in class templates as implicitly instantiable, even if we don't see a body on the friend function declaration. The body may simply have not yet been attached. This fixes PR10666. There may be an alternate, preferred implementation strategy, see my FIXME. Review would definitely be appreciated Doug. =D llvm-svn: 137934
2011-08-18 17:09:59 +08:00
} else if (isFriend) {
// Note, we need this connection even if the friend doesn't have a body.
// Its body may exist but not have been attached yet due to deferred
// parsing.
// FIXME: It might be cleaner to set this when attaching the body to the
// friend function declaration, however that would require finding all the
// instantiations and modifying them.
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))
return 0;
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);
if (!Temp) return 0;
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
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.CheckFunctionDeclaration(/*Scope*/ 0, 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) {
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
PrincipalDecl->setObjectOfFriendDecl();
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
zap tabs llvm-svn: 112541
2010-08-31 06:25:56 +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
Add a -Wc++98-compat warning for friend functions of class templates which would be implicitly instantiated (resulting in a redefinition) in C++98. llvm-svn: 142468
2011-10-19 08:54:10 +08:00
// C++98 [temp.friend]p5: When a function is defined in a friend function
// declaration in a class template, the function is defined at each
// instantiation of the class template. The function is defined even if it
// is never used.
// C++11 [temp.friend]p4: When a function is defined in a friend function
// declaration in a class template, the function is instantiated when the
// function is odr-used.
//
// If -Wc++98-compat is enabled, we go through the motions of checking for a
// redefinition, but don't instantiate the function.
s/CPlusPlus0x/CPlusPlus11/g llvm-svn: 171367
2013-01-02 19:42:31 +08:00
if ((!SemaRef.getLangOpts().CPlusPlus11 ||
Add a -Wc++98-compat warning for friend functions of class templates which would be implicitly instantiated (resulting in a redefinition) in C++98. llvm-svn: 142468
2011-10-19 08:54:10 +08:00
SemaRef.Diags.getDiagnosticLevel(
diag::warn_cxx98_compat_friend_redefinition,
Function->getLocation())
!= DiagnosticsEngine::Ignored) &&
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
D->isThisDeclarationADefinition()) {
// Check for a function body.
const FunctionDecl *Definition = 0;
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) {
Add a -Wc++98-compat warning for friend functions of class templates which would be implicitly instantiated (resulting in a redefinition) in C++98. llvm-svn: 142468
2011-10-19 08:54:10 +08:00
SemaRef.Diag(Function->getLocation(),
s/CPlusPlus0x/CPlusPlus11/g llvm-svn: 171367
2013-01-02 19:42:31 +08:00
SemaRef.getLangOpts().CPlusPlus11 ?
Add a -Wc++98-compat warning for friend functions of class templates which would be implicitly instantiated (resulting in a redefinition) in C++98. llvm-svn: 142468
2011-10-19 08:54:10 +08:00
diag::warn_cxx98_compat_friend_redefinition :
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);
s/CPlusPlus0x/CPlusPlus11/g llvm-svn: 171367
2013-01-02 19:42:31 +08:00
if (!SemaRef.getLangOpts().CPlusPlus11)
Add a -Wc++98-compat warning for friend functions of class templates which would be implicitly instantiated (resulting in a redefinition) in C++98. llvm-svn: 142468
2011-10-19 08:54:10 +08:00
Function->setInvalidDecl();
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.
else for (FunctionDecl::redecl_iterator R = Function->redecls_begin(),
REnd = Function->redecls_end();
R != REnd; ++R) {
simplify llvm-svn: 112372
2010-08-28 23:42:30 +08:00
if (*R == Function)
continue;
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
switch (R->getFriendObjectKind()) {
case Decl::FOK_None:
s/CPlusPlus0x/CPlusPlus11/g llvm-svn: 171367
2013-01-02 19:42:31 +08:00
if (!SemaRef.getLangOpts().CPlusPlus11 &&
Add a -Wc++98-compat warning for friend functions of class templates which would be implicitly instantiated (resulting in a redefinition) in C++98. llvm-svn: 142468
2011-10-19 08:54:10 +08:00
!queuedInstantiation && R->isUsed(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
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;
}
}
}
break;
default:
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
if (const FunctionDecl *RPattern
simplify by relying on cascading operator-> llvm-svn: 112373
2010-08-28 23:46:56 +08:00
= 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)) {
Add a -Wc++98-compat warning for friend functions of class templates which would be implicitly instantiated (resulting in a redefinition) in C++98. llvm-svn: 142468
2011-10-19 08:54:10 +08:00
SemaRef.Diag(Function->getLocation(),
s/CPlusPlus0x/CPlusPlus11/g llvm-svn: 171367
2013-01-02 19:42:31 +08:00
SemaRef.getLangOpts().CPlusPlus11 ?
Add a -Wc++98-compat warning for friend functions of class templates which would be implicitly instantiated (resulting in a redefinition) in C++98. llvm-svn: 142468
2011-10-19 08:54:10 +08:00
diag::warn_cxx98_compat_friend_redefinition :
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);
s/CPlusPlus0x/CPlusPlus11/g llvm-svn: 171367
2013-01-02 19:42:31 +08:00
if (!SemaRef.getLangOpts().CPlusPlus11)
Add a -Wc++98-compat warning for friend functions of class templates which would be implicitly instantiated (resulting in a redefinition) in C++98. llvm-svn: 142468
2011-10-19 08:54:10 +08:00
Function->setInvalidDecl();
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;
}
}
}
}
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
When we form a new function/class template specialization, we first search for the specialization (in a folding set) and, if not found form a *Decl that is then inserted into that folding set. In rare cases, the folding set may be reallocated between the search and the insertion, causing a crash. No test case, because triggering rehashing consistently in a small test case is not feasible. Fixes <rdar://problem/11115071>. llvm-svn: 153575
2012-03-28 22:34:23 +08:00
void *InsertPos = 0;
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
ArrayRef'ize MultiLevelTemplateArgumentList::ArgList. Patch by Faisal Vali! llvm-svn: 181077
2013-05-04 07:46:09 +08:00
= FunctionTemplate->findSpecialization(Innermost.begin(),
Innermost.size(),
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
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);
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
bool MergeWithParentScope = (TemplateParams != 0) ||
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())) {
TempParamLists.set_size(NumTempParamLists);
for (unsigned I = 0; I != NumTempParamLists; ++I) {
TemplateParameterList *TempParams = D->getTemplateParameterList(I);
TemplateParameterList *InstParams = SubstTemplateParams(TempParams);
if (!InstParams)
return NULL;
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)
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 0;
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)
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
return 0;
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))
return 0;
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);
}
if (!DC) return 0;
}
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);
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
CXXMethodDecl *Method = 0;
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(),
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
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());
PR15757: When we instantiate an inheriting constructor template, also instantiate the inherited constructor template and mark that as the constructor which the instantiated specialization is inheriting. This fixes a crash-on-valid when trying to compute the exception specification of a specialization of the inheriting constructor. llvm-svn: 182072
2013-05-17 10:19:35 +08:00
C++11 inheriting constructors: support for inheriting constructor templates. llvm-svn: 179151
2013-04-10 13:48:59 +08:00
// Claim that the instantiation of a constructor or constructor template
// inherits the same constructor that the template does.
PR15757: When we instantiate an inheriting constructor template, also instantiate the inherited constructor template and mark that as the constructor which the instantiated specialization is inheriting. This fixes a crash-on-valid when trying to compute the exception specification of a specialization of the inheriting constructor. llvm-svn: 182072
2013-05-17 10:19:35 +08:00
if (CXXConstructorDecl *Inh = const_cast<CXXConstructorDecl *>(
Constructor->getInheritedConstructor())) {
// If we're instantiating a specialization of a function template, our
// "inherited constructor" will actually itself be a function template.
// Instantiate a declaration of it, too.
if (FunctionTemplate) {
assert(!TemplateParams && Inh->getDescribedFunctionTemplate() &&
!Inh->getParent()->isDependentContext() &&
"inheriting constructor template in dependent context?");
Sema::InstantiatingTemplate Inst(SemaRef, Constructor->getLocation(),
Inh);
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())
PR15757: When we instantiate an inheriting constructor template, also instantiate the inherited constructor template and mark that as the constructor which the instantiated specialization is inheriting. This fixes a crash-on-valid when trying to compute the exception specification of a specialization of the inheriting constructor. llvm-svn: 182072
2013-05-17 10:19:35 +08:00
return 0;
Sema::ContextRAII SavedContext(SemaRef, Inh->getDeclContext());
LocalInstantiationScope LocalScope(SemaRef);
// Use the same template arguments that we deduced for the inheriting
// constructor. There's no way they could be deduced differently.
MultiLevelTemplateArgumentList InheritedArgs;
InheritedArgs.addOuterTemplateArguments(TemplateArgs.getInnermost());
Inh = cast_or_null<CXXConstructorDecl>(
SemaRef.SubstDecl(Inh, Inh->getDeclContext(), InheritedArgs));
if (!Inh)
return 0;
}
C++11 inheriting constructors: support for inheriting constructor templates. llvm-svn: 179151
2013-04-10 13:48:59 +08:00
cast<CXXConstructorDecl>(Method)->setInheritedConstructor(Inh);
PR15757: When we instantiate an inheriting constructor template, also instantiate the inherited constructor template and mark that as the constructor which the instantiated specialization is inheriting. This fixes a crash-on-valid when trying to compute the exception specification of a specialization of the inheriting constructor. llvm-svn: 182072
2013-05-17 10:19:35 +08:00
}
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,
Added locations and type source info for DeclarationName. llvm-svn: 110860
2010-08-12 06:01:17 +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);
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,
Rename FunctionDecl::isInline/setInline to FunctionDecl::isInlineSpecified/setInlineSpecified. llvm-svn: 85305
2009-10-28 05:01:01 +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,
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
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,
ArrayRef'ize MultiLevelTemplateArgumentList::ArgList. Patch by Faisal Vali! llvm-svn: 181077
2013-05-04 07:46:09 +08:00
Innermost.begin(),
Innermost.size()),
When we form a new function/class template specialization, we first search for the specialization (in a folding set) and, if not found form a *Decl that is then inserted into that folding set. In rare cases, the folding set may be reallocated between the search and the insertion, causing a crash. No test case, because triggering rehashing consistently in a small test case is not feasible. Fixes <rdar://problem/11115071>. llvm-svn: 153575
2012-03-28 22:34:23 +08:00
/*InsertPos=*/0);
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)
Method->setTemplateParameterListsInfo(SemaRef.Context,
NumTempParamLists,
TempParamLists.data());
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)
Move some bool flags out of function parameter lists. llvm-svn: 141610
2011-10-11 08:28:45 +08:00
SemaRef.CheckFunctionDeclaration(0, 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
Basic nested-template implementation. llvm-svn: 79504
2009-08-20 09:44:21 +08:00
TemplateTypeParmDecl *Inst =
Fixed TypedefDecl and TemplateTypeParameter source range. llvm-svn: 127119
2011-03-06 23:48:19 +08:00
TemplateTypeParmDecl::Create(SemaRef.Context, Owner,
D->getLocStart(), D->getLocation(),
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
D->getDepth() - TemplateArgs.getNumLevels(),
D->getIndex(), D->getIdentifier(),
Basic nested-template implementation. llvm-svn: 79504
2009-08-20 09:44:21 +08:00
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
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
if (D->hasDefaultArgument()) {
TypeSourceInfo *InstantiatedDefaultArg =
SemaRef.SubstType(D->getDefaultArgumentInfo(), TemplateArgs,
D->getDefaultArgumentLoc(), D->getDeclName());
if (InstantiatedDefaultArg)
Inst->setDefaultArgument(InstantiatedDefaultArg, false);
}
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) {
TypeSourceInfo *NewDI =SemaRef.SubstType(D->getExpansionTypeSourceInfo(I),
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)
return 0;
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
ExpandedParameterPackTypesAsWritten.push_back(NewDI);
QualType NewT =SemaRef.CheckNonTypeTemplateParameterType(NewDI->getType(),
D->getLocation());
if (NewT.isNull())
return 0;
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))
return 0;
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)
return 0;
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
ExpandedParameterPackTypesAsWritten.push_back(NewDI);
QualType NewT = SemaRef.CheckNonTypeTemplateParameterType(
NewDI->getType(),
D->getLocation());
if (NewT.isNull())
return 0;
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)
return 0;
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
DI = SemaRef.CheckPackExpansion(NewPattern, Expansion.getEllipsisLoc(),
NumExpansions);
if (!DI)
return 0;
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)
return 0;
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.
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
T = SemaRef.CheckNonTypeTemplateParameterType(DI->getType(),
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());
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)
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Param = NonTypeTemplateParmDecl::Create(SemaRef.Context, Owner,
Fixed source range for all DeclaratorDecl's. llvm-svn: 127225
2011-03-08 16:55:46 +08:00
D->getInnerLocStart(),
D->getLocation(),
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
D->getDepth() - TemplateArgs.getNumLevels(),
D->getPosition(),
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->getIdentifier(), T,
DI,
ExpandedParameterPackTypes.data(),
ExpandedParameterPackTypes.size(),
ExpandedParameterPackTypesAsWritten.data());
else
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Param = NonTypeTemplateParmDecl::Create(SemaRef.Context, Owner,
Fixed source range for all DeclaratorDecl's. llvm-svn: 127225
2011-03-08 16:55:46 +08:00
D->getInnerLocStart(),
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(),
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
D->getDepth() - TemplateArgs.getNumLevels(),
D->getPosition(),
D->getIdentifier(), T,
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->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
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
if (D->hasDefaultArgument()) {
ExprResult Value = SemaRef.SubstExpr(D->getDefaultArgument(), TemplateArgs);
if (!Value.isInvalid())
Param->setDefaultArgument(Value.get(), false);
}
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) {
for (TemplateParameterList::const_iterator I = Params->begin(),
E = Params->end(); I != E; ++I) {
if ((*I)->isTemplateParameterPack())
continue;
if (NonTypeTemplateParmDecl *NTTP = dyn_cast<NonTypeTemplateParmDecl>(*I))
S.collectUnexpandedParameterPacks(NTTP->getTypeSourceInfo()->getTypeLoc(),
Unexpanded);
if (TemplateTemplateParmDecl *TTP = dyn_cast<TemplateTemplateParmDecl>(*I))
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)
return 0;
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))
return 0;
if (Expand) {
for (unsigned I = 0; I != *NumExpansions; ++I) {
Sema::ArgumentPackSubstitutionIndexRAII SubstIndex(SemaRef, I);
LocalInstantiationScope Scope(SemaRef);
TemplateParameterList *Expansion = SubstTemplateParams(TempParams);
if (!Expansion)
return 0;
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)
return 0;
}
} 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)
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
return 0;
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)
Param = TemplateTemplateParmDecl::Create(SemaRef.Context, Owner,
D->getLocation(),
D->getDepth() - TemplateArgs.getNumLevels(),
D->getPosition(),
D->getIdentifier(), InstParams,
ExpandedParams);
else
Param = TemplateTemplateParmDecl::Create(SemaRef.Context, Owner,
D->getLocation(),
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
D->getDepth() - TemplateArgs.getNumLevels(),
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
D->getPosition(),
D->isParameterPack(),
D->getIdentifier(), InstParams);
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
if (D->hasDefaultArgument()) {
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(
TemplateArgumentLoc(TemplateArgument(TName),
D->getDefaultArgument().getTemplateQualifierLoc(),
D->getDefaultArgument().getTemplateNameLoc()),
false);
}
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)
Update UsingDecl, UnresolvedUsingTypenameDecl, and UnresolvedUsingValueDecl to use NestedNameSpecifierLoc rather than the extremely-lossy NestedNameSpecifier/SourceRange pair it used to use, improving source-location information. Various infrastructure updates to support NestedNameSpecifierLoc: - AST/PCH (de-)serialization - Recursive AST visitor - libclang traversal (including the first tests of this functionality) llvm-svn: 126459
2011-02-25 08:36:19 +08:00
return 0;
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 name info is non-dependent, so no transformation
// is required.
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();
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() &&
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
SemaRef.CheckUsingDeclQualifier(D->getUsingLoc(), SS,
Fix "using typename" and the instantiation of non-dependent using declarations. llvm-svn: 90614
2009-12-05 06:46:56 +08:00
D->getLocation()))
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;
Basic semantic analysis support for inheriting constructor declarations in dependent contexts. llvm-svn: 153858
2012-04-02 09:30:27 +08:00
if (NameInfo.getName().getNameKind() == DeclarationName::CXXConstructorName) {
if (SemaRef.CheckInheritingConstructorUsingDecl(NewUD))
NewUD->setInvalidDecl();
return NewUD;
}
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.
for (UsingDecl::shadow_iterator I = D->shadow_begin(), E = D->shadow_end();
I != E; ++I) {
UsingShadowDecl *Shadow = *I;
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(
Shadow->getLocation(), Shadow->getTargetDecl(), 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)
return 0;
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 *PrevDecl = 0;
if (CheckRedeclaration) {
if (SemaRef.CheckUsingShadowDecl(NewUD, InstTarget, Prev, PrevDecl))
continue;
} else if (UsingShadowDecl *OldPrev = Shadow->getPreviousDecl()) {
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 =
SemaRef.BuildUsingShadowDecl(/*Scope*/0, 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.
return 0;
Fix "using typename" and the instantiation of non-dependent using declarations. llvm-svn: 90614
2009-12-05 06:46:56 +08:00
}
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
Decl * TemplateDeclInstantiator
::VisitUnresolvedUsingTypenameDecl(UnresolvedUsingTypenameDecl *D) {
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
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
= SemaRef.SubstNestedNameSpecifierLoc(D->getQualifierLoc(),
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
TemplateArgs);
if (!QualifierLoc)
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
return 0;
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);
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
Added locations and type source info for DeclarationName inside UsingDecl. llvm-svn: 110912
2010-08-12 19:46:03 +08:00
// Since NameInfo refers to a typename, it cannot be a C++ special name.
s/tranform/transform/ llvm-svn: 167929
2012-11-14 23:08:31 +08:00
// Hence, no transformation is required for it.
Added locations and type source info for DeclarationName inside UsingDecl. llvm-svn: 110912
2010-08-12 19:46:03 +08:00
DeclarationNameInfo NameInfo(D->getDeclName(), D->getLocation());
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
NamedDecl *UD =
SemaRef.BuildUsingDeclaration(/*Scope*/ 0, D->getAccess(),
Added locations and type source info for DeclarationName inside UsingDecl. llvm-svn: 110912
2010-08-12 19:46:03 +08:00
D->getUsingLoc(), SS, NameInfo, 0,
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
/*instantiation*/ true,
/*typename*/ true, D->getTypenameLoc());
Revert r104106; it's breaking linking of Boost.Serialization. llvm-svn: 104121
2010-05-20 01:02:24 +08:00
if (UD)
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(cast<UsingDecl>(UD), D);
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
return UD;
}
Decl * TemplateDeclInstantiator
::VisitUnresolvedUsingValueDecl(UnresolvedUsingValueDecl *D) {
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)
Instantiate unresolved using declarations. llvm-svn: 80366
2009-08-28 23:18:15 +08:00
return 0;
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);
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
NamedDecl *UD =
Instead of hanging a using declaration's target decls directly off the using decl, create shadow declarations and put them in scope like normal. Work in progress. llvm-svn: 89048
2009-11-17 13:59:44 +08:00
SemaRef.BuildUsingDeclaration(/*Scope*/ 0, D->getAccess(),
Added locations and type source info for DeclarationName inside UsingDecl. llvm-svn: 110912
2010-08-12 19:46:03 +08:00
D->getUsingLoc(), SS, NameInfo, 0,
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
/*instantiation*/ true,
/*typename*/ false, SourceLocation());
Revert r104106; it's breaking linking of Boost.Serialization. llvm-svn: 104121
2010-05-20 01:02:24 +08:00
if (UD)
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(cast<UsingDecl>(UD), D);
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
}
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();
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
CXXMethodDecl *NewFD = cast<CXXMethodDecl>(VisitCXXMethodDecl(OldFD,
0, true));
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;
TemplateArgumentListInfo* TemplateArgsPtr = 0;
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;
for (ArrayRef<Expr *>::iterator I = D->varlist_begin(),
E = D->varlist_end();
OpenMP threadprivate directive parsing and semantic analysis llvm-svn: 177705
2013-03-22 14:34:35 +08:00
I != E; ++I) {
Expr *Var = SemaRef.SubstExpr(*I, TemplateArgs).take();
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);
return TD;
}
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) {
return VisitFunctionDecl(D, 0);
}
Decl *TemplateDeclInstantiator::VisitCXXMethodDecl(CXXMethodDecl *D) {
return VisitCXXMethodDecl(D, 0);
}
Decl *TemplateDeclInstantiator::VisitRecordDecl(RecordDecl *D) {
llvm_unreachable("There are only CXXRecordDecls in C++");
}
Decl *
TemplateDeclInstantiator::VisitClassTemplateSpecializationDecl(
ClassTemplateSpecializationDecl *D) {
llvm_unreachable("Only ClassTemplatePartialSpecializationDecls occur"
"inside templates");
}
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))
return 0;
// Check that the template argument list is well-formed for this template.
SmallVector<TemplateArgument, 4> Converted;
bool ExpansionIntoFixedList = false;
if (SemaRef.CheckTemplateArgumentList(
VarTemplate, VarTemplate->getLocStart(),
const_cast<TemplateArgumentListInfo &>(VarTemplateArgsInfo), false,
Converted, &ExpansionIntoFixedList))
return 0;
// Find the variable template specialization declaration that
// corresponds to these arguments.
void *InsertPos = 0;
if (VarTemplateSpecializationDecl *VarSpec = VarTemplate->findSpecialization(
Converted.data(), Converted.size(), InsertPos))
// 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,
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
llvm::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
// If this is the variable for an anonymous struct or union,
// instantiate the anonymous struct/union type first.
if (const RecordType *RecordTy = D->getType()->getAs<RecordType>())
if (RecordTy->getDecl()->isAnonymousStructOrUnion())
if (!VisitCXXRecordDecl(cast<CXXRecordDecl>(RecordTy->getDecl())))
return 0;
// Do substitution on the type of the declaration
TypeSourceInfo *DI =
SemaRef.SubstType(D->getTypeSourceInfo(), TemplateArgs,
D->getTypeSpecStartLoc(), D->getDeclName());
if (!DI)
return 0;
if (DI->getType()->isFunctionType()) {
SemaRef.Diag(D->getLocation(), diag::err_variable_instantiates_to_function)
<< D->isStaticDataMember() << DI->getType();
return 0;
}
// Build the instantiated declaration
VarTemplateSpecializationDecl *Var = VarTemplateSpecializationDecl::Create(
SemaRef.Context, Owner, D->getInnerLocStart(), D->getLocation(),
VarTemplate, DI->getType(), DI, D->getStorageClass(), Converted.data(),
Converted.size());
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))
return 0;
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();
return 0;
}
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())
return 0;
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);
for (TemplateParameterList::iterator PI = L->begin(), PE = L->end();
PI != PE; ++PI) {
Implement partial ordering of class template partial specializations (C++ [temp.class.order]). llvm-svn: 81866
2009-09-16 00:23:51 +08:00
NamedDecl *D = cast_or_null<NamedDecl>(Visit(*PI));
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)
Basic nested-template implementation. llvm-svn: 79504
2009-08-20 09:44:21 +08:00
return NULL;
TemplateParameterList *InstL
= TemplateParameterList::Create(SemaRef.Context, L->getTemplateLoc(),
L->getLAngleLoc(), &Params.front(), N,
L->getRAngleLoc());
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)
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 0;
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))
return 0;
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))
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 0;
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.
void *InsertPos = 0;
ClassTemplateSpecializationDecl *PrevDecl
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
= ClassTemplate->findPartialSpecialization(Converted.data(),
Converted.size(), 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),
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
Converted.data(),
Converted.size());
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);
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 0;
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,
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
Converted.data(),
Converted.size(),
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,
Remove SequenceNumber from class/variable template partial specializations. This was only used to ensure that the traversal order was the same as the insertion order, but that guarantee was already being provided by the use of a FoldingSetVector. llvm-svn: 189075
2013-08-23 07:27:37 +08:00
0);
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))
return 0;
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
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.
When we form a new function/class template specialization, we first search for the specialization (in a folding set) and, if not found form a *Decl that is then inserted into that folding set. In rare cases, the folding set may be reallocated between the search and the insertion, causing a crash. No test case, because triggering rehashing consistently in a small test case is not feasible. Fixes <rdar://problem/11115071>. llvm-svn: 153575
2012-03-28 22:34:23 +08:00
ClassTemplate->AddPartialSpecialization(InstPartialSpec, /*InsertPos=*/0);
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)
return 0;
// 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))
return 0;
// 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))
return 0;
// Figure out where to insert this variable template partial specialization
// in the member template's set of variable template partial specializations.
void *InsertPos = 0;
VarTemplateSpecializationDecl *PrevDecl =
VarTemplate->findPartialSpecialization(Converted.data(), Converted.size(),
InsertPos);
// Build the canonical type that describes the converted template
// arguments of the variable template partial specialization.
QualType CanonType = SemaRef.Context.getTemplateSpecializationType(
TemplateName(VarTemplate), Converted.data(), Converted.size());
// 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);
return 0;
}
// Do substitution on the type of the declaration
TypeSourceInfo *DI = SemaRef.SubstType(
PartialSpec->getTypeSourceInfo(), TemplateArgs,
PartialSpec->getTypeSpecStartLoc(), PartialSpec->getDeclName());
if (!DI)
return 0;
if (DI->getType()->isFunctionType()) {
SemaRef.Diag(PartialSpec->getLocation(),
diag::err_variable_instantiates_to_function)
<< PartialSpec->isStaticDataMember() << DI->getType();
return 0;
}
// Create the variable template partial specialization declaration.
VarTemplatePartialSpecializationDecl *InstPartialSpec =
VarTemplatePartialSpecializationDecl::Create(
SemaRef.Context, Owner, PartialSpec->getInnerLocStart(),
PartialSpec->getLocation(), InstParams, VarTemplate, DI->getType(),
DI, PartialSpec->getStorageClass(), Converted.data(),
Remove SequenceNumber from class/variable template partial specializations. This was only used to ensure that the traversal order was the same as the insertion order, but that guarantee was already being provided by the use of a FoldingSetVector. llvm-svn: 189075
2013-08-23 07:27:37 +08:00
Converted.size(), 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))
return 0;
InstPartialSpec->setInstantiatedFromMember(PartialSpec);
InstPartialSpec->setTypeAsWritten(WrittenTy);
// Add this partial specialization to the set of variable template partial
// specializations. The instantiation of the initializer is not necessary.
VarTemplate->AddPartialSpecialization(InstPartialSpec, /*InsertPos=*/0);
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");
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
CXXRecordDecl *ThisContext = 0;
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)
return 0;
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;
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
for (unsigned OldIdx = 0, NumOldParams = OldProtoLoc.getNumArgs();
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) {
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
ParmVarDecl *OldParam = OldProtoLoc.getArg(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.
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
ParmVarDecl *NewParam = NewProtoLoc.getArg(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) {
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
ParmVarDecl *NewParam = NewProtoLoc.getArg(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());
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
for (unsigned i = 0, i_end = OldProtoLoc.getNumArgs(); i != i_end; ++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
ParmVarDecl *OldParam = OldProtoLoc.getArg(i);
if (!OldParam) {
Params.push_back(SemaRef.BuildParmVarDeclForTypedef(
D, D->getLocation(), OldProto->getArgType(i)));
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)
return 0;
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;
if (SemaRef.SubstParmTypes(D->getLocation(), D->param_begin(),
D->getNumParams(), TemplateArgs, ParamTypes,
&Params))
return 0;
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.
static void addInstantiatedParametersToScope(Sema &S, FunctionDecl *Function,
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);
FunctionParam->setDeclName(PatternParam->getDeclName());
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");
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());
Scope.InstantiatedLocalPackArg(PatternParam, FunctionParam);
++FParamIdx;
}
}
}
static void InstantiateExceptionSpec(Sema &SemaRef, FunctionDecl *New,
const FunctionProtoType *Proto,
const MultiLevelTemplateArgumentList &TemplateArgs) {
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
assert(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
// C++11 [expr.prim.general]p3:
// If a declaration declares a member function or member function
// template of a class X, the expression this is a prvalue of type
// "pointer to cv-qualifier-seq X" between the optional cv-qualifer-seq
// and the end of the function-definition, member-declarator, or
// declarator.
CXXRecordDecl *ThisContext = 0;
unsigned ThisTypeQuals = 0;
if (CXXMethodDecl *Method = dyn_cast<CXXMethodDecl>(New)) {
ThisContext = Method->getParent();
ThisTypeQuals = Method->getTypeQualifiers();
}
Sema::CXXThisScopeRAII ThisScope(SemaRef, ThisContext, ThisTypeQuals,
s/CPlusPlus0x/CPlusPlus11/g llvm-svn: 171367
2013-01-02 19:42:31 +08:00
SemaRef.getLangOpts().CPlusPlus11);
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
// The function has an exception specification or a "noreturn"
// attribute. Substitute into each of the exception types.
SmallVector<QualType, 4> Exceptions;
for (unsigned I = 0, N = Proto->getNumExceptions(); I != N; ++I) {
// FIXME: Poor location information!
if (const PackExpansionType *PackExpansion
= Proto->getExceptionType(I)->getAs<PackExpansionType>()) {
// We have a pack expansion. Instantiate it.
SmallVector<UnexpandedParameterPack, 2> Unexpanded;
SemaRef.collectUnexpandedParameterPacks(PackExpansion->getPattern(),
Unexpanded);
assert(!Unexpanded.empty() &&
"Pack expansion without parameter packs?");
bool Expand = false;
bool RetainExpansion = false;
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
Optional<unsigned> NumExpansions = PackExpansion->getNumExpansions();
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 (SemaRef.CheckParameterPacksForExpansion(New->getLocation(),
SourceRange(),
Unexpanded,
TemplateArgs,
Expand,
RetainExpansion,
NumExpansions))
break;
if (!Expand) {
// We can't expand this pack expansion into separate arguments yet;
// just substitute into the pattern and create a new pack expansion
// type.
Sema::ArgumentPackSubstitutionIndexRAII SubstIndex(SemaRef, -1);
QualType T = SemaRef.SubstType(PackExpansion->getPattern(),
TemplateArgs,
New->getLocation(), New->getDeclName());
if (T.isNull())
break;
T = SemaRef.Context.getPackExpansionType(T, NumExpansions);
Exceptions.push_back(T);
continue;
}
// Substitute into the pack expansion pattern for each template
bool Invalid = false;
for (unsigned ArgIdx = 0; ArgIdx != *NumExpansions; ++ArgIdx) {
Sema::ArgumentPackSubstitutionIndexRAII SubstIndex(SemaRef, ArgIdx);
QualType T = SemaRef.SubstType(PackExpansion->getPattern(),
TemplateArgs,
New->getLocation(), New->getDeclName());
if (T.isNull()) {
Invalid = true;
break;
}
Exceptions.push_back(T);
}
if (Invalid)
break;
continue;
}
QualType T
= SemaRef.SubstType(Proto->getExceptionType(I), TemplateArgs,
New->getLocation(), New->getDeclName());
if (T.isNull() ||
SemaRef.CheckSpecifiedExceptionType(T, New->getLocation()))
continue;
Exceptions.push_back(T);
}
Expr *NoexceptExpr = 0;
if (Expr *OldNoexceptExpr = Proto->getNoexceptExpr()) {
EnterExpressionEvaluationContext Unevaluated(SemaRef,
Sema::ConstantEvaluated);
ExprResult E = SemaRef.SubstExpr(OldNoexceptExpr, TemplateArgs);
if (E.isUsable())
E = SemaRef.CheckBooleanCondition(E.get(), E.get()->getLocStart());
if (E.isUsable()) {
NoexceptExpr = E.take();
if (!NoexceptExpr->isTypeDependent() &&
!NoexceptExpr->isValueDependent())
Move Sema::VerifyIntegerConstantExpression() and Sema::ConvertToIntegralOrEnumerationType() from PartialDiagnostics to abstract "diagnoser" classes. Not much of a win here, but we're -several PartialDiagnostics. llvm-svn: 156217
2012-05-05 06:38:52 +08:00
NoexceptExpr
= SemaRef.VerifyIntegerConstantExpression(NoexceptExpr,
0, diag::err_noexcept_needs_constant_expression,
/*AllowFold*/ false).take();
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
}
}
// Rebuild the function type
const FunctionProtoType *NewProto
= New->getType()->getAs<FunctionProtoType>();
assert(NewProto && "Template instantiation without function prototype?");
FunctionProtoType::ExtProtoInfo EPI = NewProto->getExtProtoInfo();
EPI.ExceptionSpecType = Proto->getExceptionSpecType();
EPI.NumExceptions = Exceptions.size();
EPI.Exceptions = Exceptions.data();
EPI.NoexceptExpr = NoexceptExpr;
New->setType(SemaRef.Context.getFunctionType(NewProto->getResultType(),
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
NewProto->getArgTypes(), 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
}
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.
FunctionProtoType::ExtProtoInfo EPI = Proto->getExtProtoInfo();
EPI.ExceptionSpecType = EST_None;
Decl->setType(Context.getFunctionType(Proto->getResultType(),
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
Proto->getArgTypes(), 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
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
}
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 =
getTemplateInstantiationArgs(Decl, 0, /*RelativeToPrimary*/true);
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();
addInstantiatedParametersToScope(*this, Decl, Template, Scope, 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
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
::InstantiateExceptionSpec(*this, 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
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.
typedef Sema::ActiveTemplateInstantiation ActiveInstType;
ActiveInstType &ActiveInst = SemaRef.ActiveTemplateInstantiations.back();
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.
s/CPlusPlus0x/CPlusPlus11/g llvm-svn: 171367
2013-01-02 19:42:31 +08:00
if (SemaRef.getLangOpts().CPlusPlus11 &&
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
EPI.ExceptionSpecType != EST_None &&
EPI.ExceptionSpecType != EST_DynamicNone &&
EPI.ExceptionSpecType != EST_BasicNoexcept) {
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;
if (EPI.ExceptionSpecType == EST_Uninstantiated)
ExceptionSpecTemplate = EPI.ExceptionSpecTemplate;
C++11 inheriting constructors: support for inheriting constructor templates. llvm-svn: 179151
2013-04-10 13:48:59 +08:00
ExceptionSpecificationType NewEST = EST_Uninstantiated;
if (EPI.ExceptionSpecType == EST_Unevaluated)
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();
C++11 inheriting constructors: support for inheriting constructor templates. llvm-svn: 179151
2013-04-10 13:48:59 +08:00
EPI.ExceptionSpecType = NewEST;
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
EPI.ExceptionSpecDecl = New;
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
EPI.ExceptionSpecTemplate = 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(
NewProto->getResultType(), NewProto->getArgTypes(), 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 {
::InstantiateExceptionSpec(SemaRef, New, Proto, TemplateArgs);
}
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
/// \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,
bool DefinitionRequired) {
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.
if (Function->getTemplateSpecializationKind() == TSK_ExplicitSpecialization &&
!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");
Stmt *Pattern = PatternDecl->getBody(PatternDecl);
assert(PatternDecl && "template definition is not a template");
if (!Pattern) {
// Try to find a defaulted definition
PatternDecl->isDefined(PatternDecl);
Fix a minor thinko that leads to a crash if PatternDecl is null but Pattern is not. Thanks Nick for catching this! llvm-svn: 132089
2011-05-26 06:02:25 +08:00
}
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 && "template definition is not a template");
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
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;
}
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);
LateParsedTemplate *LPT = LateParsedTemplateMap.lookup(PatternDecl);
assert(LPT && "missing LateParsedTemplate");
LateTemplateParser(OpaqueParser, *LPT);
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);
}
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->isDefaulted()) {
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
if (DefinitionRequired) {
if (Function->getPrimaryTemplate())
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Diag(PointOfInstantiation,
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
diag::err_explicit_instantiation_undefined_func_template)
<< Function->getPrimaryTemplate();
else
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Diag(PointOfInstantiation,
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
diag::err_explicit_instantiation_undefined_member)
<< 1 << Function->getDeclName() << Function->getDeclContext();
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
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
if (PatternDecl)
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
Diag(PatternDecl->getLocation(),
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
diag::note_explicit_instantiation_here);
Diagnose a redefinition error when there are two instantiations of friend functions defined inside a class template. Fixes PR6952, the last Boost.Units failure. llvm-svn: 103952
2010-05-18 01:57:54 +08:00
Function->setInvalidDecl();
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
} else if (Function->getTemplateSpecializationKind()
== 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(Function, PointOfInstantiation));
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
}
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
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
return;
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
}
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.
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
if (Function->getTemplateSpecializationKind()
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
== 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() &&
PR16875: The return type of a dependent function type is visible when it's referenced as a member of the current instantiation. In that case, deduce the type of the function to a dependent type rather than exposing an undeduced auto type to the rest of the current instantiation. The standard doesn't really say that the type is dependent in this case; I'll bring this up with CWG. llvm-svn: 188410
2013-08-15 04:16:31 +08:00
!PatternDecl->getResultType()->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
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 (PatternDecl->isInlined())
Function->setImplicitlyInline();
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);
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())
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
return;
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());
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
// 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.
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<VTableUse, 16> SavedVTableUses;
Rename *PendingImplicitInstantiations to *PendingInstantiations. No functionality changed. llvm-svn: 112040
2010-08-25 16:44:16 +08:00
std::deque<PendingImplicitInstantiation> SavedPendingInstantiations;
Sema: Instantiation of variable definitions weren't local enough We wouldn't properly save and restore the pending local instantiations we had built up prior to instantiation of a variable definition. This would lead to us instantiating too much causing crashes and other general badness. This fixes PR14374. llvm-svn: 195887
2013-11-28 06:57:44 +08:00
SavePendingLocalImplicitInstantiationsRAII
SavedPendingLocalImplicitInstantiations(*this);
Tie DefineVTablesUsed() in with recursive function instantiation so that we emit a useful template instantiation stack. Fixes PR8640. This also causes a slight change to where the "instantianted from" note shows up in truly esoteric cases (see the change to test/SemaCXX/destructor.cpp), but that isn't directly the fault of this patch. llvm-svn: 120135
2010-11-25 08:35:20 +08:00
if (Recursive) {
VTableUses.swap(SavedVTableUses);
Rename *PendingImplicitInstantiations to *PendingInstantiations. No functionality changed. llvm-svn: 112040
2010-08-25 16:44:16 +08:00
PendingInstantiations.swap(SavedPendingInstantiations);
Tie DefineVTablesUsed() in with recursive function instantiation so that we emit a useful template instantiation stack. Fixes PR8640. This also causes a slight change to where the "instantianted from" note shows up in truly esoteric cases (see the change to test/SemaCXX/destructor.cpp), but that isn't directly the fault of this patch. llvm-svn: 120135
2010-11-25 08:35:20 +08:00
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
EnterExpressionEvaluationContext EvalContext(*this,
One who seeks knowledge learns something new every day. One who seeks the Tao unlearns something new every day. Less and less remains until you arrive at non-action. When you arrive at non-action, nothing will be left undone. llvm-svn: 112244
2010-08-27 07:41:50 +08:00
Sema::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 {
ActOnStartOfFunctionDef(0, 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
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
MultiLevelTemplateArgumentList TemplateArgs =
getTemplateInstantiationArgs(Function, 0, false, PatternDecl);
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
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
addInstantiatedParametersToScope(*this, Function, PatternDecl, Scope,
TemplateArgs);
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
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
// If this is a constructor, instantiate the member initializers.
if (const CXXConstructorDecl *Ctor =
dyn_cast<CXXConstructorDecl>(PatternDecl)) {
InstantiateMemInitializers(cast<CXXConstructorDecl>(Function), Ctor,
TemplateArgs);
}
// 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
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
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 *PendingImplicitInstantiations to *PendingInstantiations. No functionality changed. llvm-svn: 112040
2010-08-25 16:44:16 +08:00
PerformPendingInstantiations(/*LocalOnly=*/true);
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();
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
if (Recursive) {
Tie DefineVTablesUsed() in with recursive function instantiation so that we emit a useful template instantiation stack. Fixes PR8640. This also causes a slight change to where the "instantianted from" note shows up in truly esoteric cases (see the change to test/SemaCXX/destructor.cpp), but that isn't directly the fault of this patch. llvm-svn: 120135
2010-11-25 08:35:20 +08:00
// Define any pending vtables.
DefineUsedVTables();
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
// Instantiate any pending implicit instantiations found during the
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
// instantiation of this template.
Rename *PendingImplicitInstantiations to *PendingInstantiations. No functionality changed. llvm-svn: 112040
2010-08-25 16:44:16 +08:00
PerformPendingInstantiations();
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Tie DefineVTablesUsed() in with recursive function instantiation so that we emit a useful template instantiation stack. Fixes PR8640. This also causes a slight change to where the "instantianted from" note shows up in truly esoteric cases (see the change to test/SemaCXX/destructor.cpp), but that isn't directly the fault of this patch. llvm-svn: 120135
2010-11-25 08:35:20 +08:00
// Restore the set of pending vtables.
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
assert(VTableUses.empty() &&
"VTableUses should be empty before it is discarded.");
Tie DefineVTablesUsed() in with recursive function instantiation so that we emit a useful template instantiation stack. Fixes PR8640. This also causes a slight change to where the "instantianted from" note shows up in truly esoteric cases (see the change to test/SemaCXX/destructor.cpp), but that isn't directly the fault of this patch. llvm-svn: 120135
2010-11-25 08:35:20 +08:00
VTableUses.swap(SavedVTableUses);
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
// Restore the set of pending implicit instantiations.
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
assert(PendingInstantiations.empty() &&
"PendingInstantiations should be empty before it is discarded.");
Rename *PendingImplicitInstantiations to *PendingInstantiations. No functionality changed. llvm-svn: 112040
2010-08-25 16:44:16 +08:00
PendingInstantiations.swap(SavedPendingInstantiations);
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
}
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())
return 0;
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())
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 0;
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.
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
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)
return 0;
// 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());
}
Revert "Revert "[-cxx-abi microsoft] Mangle local TagDecls appropriately"" This reverts commit r190895 which reverted r190892. llvm-svn: 190904
2013-09-18 07:57:10 +08:00
// See if the old variable had a type-specifier that defined an anonymous tag.
// If it did, mark the new variable as being the declarator for the new
// anonymous tag.
if (const TagType *OldTagType = OldVar->getType()->getAs<TagType>()) {
TagDecl *OldTag = OldTagType->getDecl();
if (OldTag->getDeclaratorForAnonDecl() == OldVar) {
TagDecl *NewTag = NewVar->getType()->castAs<TagType>()->getDecl();
assert(!NewTag->hasNameForLinkage() &&
!NewTag->hasDeclaratorForAnonDecl());
NewTag->setDeclaratorForAnonDecl(NewVar);
}
}
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
InstantiateAttrs(TemplateArgs, OldVar, NewVar, LateAttrs, StartingScope);
if (NewVar->hasAttrs())
CheckAlignasUnderalignment(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
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);
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
// Delay instantiation of the initializer for variable templates until a
// definition of the variable is needed.
if (!isa<VarTemplateSpecializationDecl>(NewVar) && !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
InstantiateVariableInitializer(NewVar, OldVar, TemplateArgs);
// Diagnose unused local variables with dependent types, where the diagnostic
// will have been deferred.
if (!NewVar->isInvalidDecl() &&
NewVar->getDeclContext()->isFunctionOrMethod() && !NewVar->isUsed() &&
OldVar->getType()->isDependentType())
DiagnoseUnusedDecl(NewVar);
}
/// \brief Instantiate the initializer of a variable.
void Sema::InstantiateVariableInitializer(
VarDecl *Var, VarDecl *OldVar,
const MultiLevelTemplateArgumentList &TemplateArgs) {
if (Var->getAnyInitializer())
// We already have an initializer in the class.
return;
if (OldVar->getInit()) {
if (Var->isStaticDataMember() && !OldVar->isOutOfLine())
PushExpressionEvaluationContext(Sema::ConstantEvaluated, OldVar);
else
PushExpressionEvaluationContext(Sema::PotentiallyEvaluated, OldVar);
// Instantiate the initializer.
ExprResult Init =
SubstInitializer(OldVar->getInit(), TemplateArgs,
OldVar->getInitStyle() == VarDecl::CallInit);
if (!Init.isInvalid()) {
bool TypeMayContainAuto = true;
if (Init.get()) {
bool DirectInit = OldVar->isDirectInit();
AddInitializerToDecl(Var, Init.take(), DirectInit, TypeMayContainAuto);
} else
ActOnUninitializedDecl(Var, TypeMayContainAuto);
} else {
// FIXME: Not too happy about invalidating the declaration
// because of a bogus initializer.
Var->setInvalidDecl();
}
PopExpressionEvaluationContext();
} else if ((!Var->isStaticDataMember() || Var->isOutOfLine()) &&
!Var->isCXXForRangeDecl())
ActOnUninitializedDecl(Var, 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
/// \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,
bool DefinitionRequired) {
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);
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
VarDecl *PatternDecl = 0, *Def = 0;
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);
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())
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;
// 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.
SmallVector<VTableUse, 16> SavedVTableUses;
std::deque<PendingImplicitInstantiation> SavedPendingInstantiations;
if (Recursive) {
VTableUses.swap(SavedVTableUses);
PendingInstantiations.swap(SavedPendingInstantiations);
}
LocalInstantiationScope Local(*this);
// 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.
PerformPendingInstantiations(/*LocalOnly=*/true);
Local.Exit();
if (Recursive) {
// Define any newly required vtables.
DefineUsedVTables();
// Instantiate any pending implicit instantiations found during the
// instantiation of this template.
PerformPendingInstantiations();
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
// Restore the set of pending vtables.
assert(VTableUses.empty() &&
"VTableUses should be empty before it is discarded.");
VTableUses.swap(SavedVTableUses);
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
// Restore the set of pending implicit instantiations.
assert(PendingInstantiations.empty() &&
"PendingInstantiations should be empty before it is discarded.");
PendingInstantiations.swap(SavedPendingInstantiations);
}
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?");
Def = PatternDecl->getOutOfLineDefinition();
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
// 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.
if (!Def) {
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
if (DefinitionRequired) {
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 (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
Diag(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
diag::err_explicit_instantiation_undefined_var_template) << Var;
else
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
Diag(PointOfInstantiation,
diag::err_explicit_instantiation_undefined_member)
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
<< 2 << Var->getDeclName() << Var->getDeclContext();
Diag(PatternDecl->getLocation(),
diag::note_explicit_instantiation_here);
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)
Var->setInvalidDecl();
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
} else if (Var->getTemplateSpecializationKind()
== 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));
}
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;
}
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
TemplateSpecializationKind TSK = Var->getTemplateSpecializationKind();
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
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 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);
return;
If something already instantiated is reinstantiated as an explicit definition, keep the latter. No test. This was noticed when poking around something else with GDB. I'm not able to figure out a testcase that would break due to this bug. Sorry. llvm-svn: 153992
2012-04-04 10:38:36 +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);
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())
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;
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.
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<VTableUse, 16> SavedVTableUses;
Rename *PendingImplicitInstantiations to *PendingInstantiations. No functionality changed. llvm-svn: 112040
2010-08-25 16:44:16 +08:00
std::deque<PendingImplicitInstantiation> SavedPendingInstantiations;
Sema: Instantiation of variable definitions weren't local enough We wouldn't properly save and restore the pending local instantiations we had built up prior to instantiation of a variable definition. This would lead to us instantiating too much causing crashes and other general badness. This fixes PR14374. llvm-svn: 195887
2013-11-28 06:57:44 +08:00
SavePendingLocalImplicitInstantiationsRAII
SavedPendingLocalImplicitInstantiations(*this);
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
if (Recursive) {
VTableUses.swap(SavedVTableUses);
Rename *PendingImplicitInstantiations to *PendingInstantiations. No functionality changed. llvm-svn: 112040
2010-08-25 16:44:16 +08:00
PendingInstantiations.swap(SavedPendingInstantiations);
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
}
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
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;
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)
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));
else if (Var->isStaticDataMember() &&
Var->getLexicalDeclContext()->isRecord()) {
// 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(
VarSpec->getSpecializedTemplate(), Def, 0,
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.
PerformPendingInstantiations(/*LocalOnly=*/true);
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();
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 (Recursive) {
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
// Define any newly required vtables.
DefineUsedVTables();
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 any pending implicit instantiations found during the
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
// instantiation of this template.
Rename *PendingImplicitInstantiations to *PendingInstantiations. No functionality changed. llvm-svn: 112040
2010-08-25 16:44:16 +08:00
PerformPendingInstantiations();
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
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
// Restore the set of pending vtables.
assert(VTableUses.empty() &&
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
"VTableUses should be empty before it is discarded.");
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
VTableUses.swap(SavedVTableUses);
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
// Restore the set of pending implicit instantiations.
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
assert(PendingInstantiations.empty() &&
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
"PendingInstantiations should be empty before it is discarded.");
Rename *PendingImplicitInstantiations to *PendingInstantiations. No functionality changed. llvm-svn: 112040
2010-08-25 16:44:16 +08:00
PendingInstantiations.swap(SavedPendingInstantiations);
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +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
}
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.
for (CXXConstructorDecl::init_const_iterator Inits = Tmpl->init_begin(),
In CXXBaseOrMemberInitializer, don't confuse CtorTocall with AnonUnionMember. Fixes PR4826. llvm-svn: 80721
2009-09-02 05:04:42 +08:00
InitsEnd = Tmpl->init_end();
Inits != InitsEnd; ++Inits) {
Renamed CXXBaseOrMemberInitializer to CXXCtorInitializer. This is both shorter, more accurate, and makes it make sense for it to hold a delegating constructor call. llvm-svn: 123084
2011-01-09 04:30:50 +08:00
CXXCtorInitializer *Init = *Inits;
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 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(),
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
BaseTInfo, TempInit.take(),
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())
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
NewInit = BuildBaseInitializer(TInfo->getType(), TInfo, TempInit.take(),
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
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
NewInit = BuildDelegatingInitializer(TInfo, TempInit.take(),
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
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
NewInit = BuildMemberInitializer(Member, TempInit.take(),
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
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
NewInit = BuildMemberInitializer(IndirectMember, TempInit.take(),
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) {
return C.getInstantiatedFromUsingShadowDecl(Instance) == Pattern;
}
static bool isInstantiationOf(UsingDecl *Pattern,
UsingDecl *Instance,
ASTContext &C) {
return C.getInstantiatedFromUsingDecl(Instance) == Pattern;
}
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
static bool isInstantiationOf(UnresolvedUsingValueDecl *Pattern,
UsingDecl *Instance,
ASTContext &C) {
Fix "using typename" and the instantiation of non-dependent using declarations. llvm-svn: 90614
2009-12-05 06:46:56 +08:00
return C.getInstantiatedFromUsingDecl(Instance) == Pattern;
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
}
static bool isInstantiationOf(UnresolvedUsingTypenameDecl *Pattern,
Improve instantiation of UnresolvedUsingDecls. llvm-svn: 80434
2009-08-30 03:37:28 +08:00
UsingDecl *Instance,
ASTContext &C) {
Fix "using typename" and the instantiation of non-dependent using declarations. llvm-svn: 90614
2009-12-05 06:46:56 +08:00
return C.getInstantiatedFromUsingDecl(Instance) == 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) {
Improve instantiation of UnresolvedUsingDecls. llvm-svn: 80434
2009-08-30 03:37:28 +08:00
if (D->getKind() != Other->getKind()) {
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
if (UnresolvedUsingTypenameDecl *UUD
= dyn_cast<UnresolvedUsingTypenameDecl>(D)) {
if (UsingDecl *UD = dyn_cast<UsingDecl>(Other)) {
return isInstantiationOf(UUD, UD, Ctx);
}
}
if (UnresolvedUsingValueDecl *UUD
= dyn_cast<UnresolvedUsingValueDecl>(D)) {
Improve instantiation of UnresolvedUsingDecls. llvm-svn: 80434
2009-08-30 03:37:28 +08:00
if (UsingDecl *UD = dyn_cast<UsingDecl>(Other)) {
return isInstantiationOf(UUD, UD, 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
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 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 (CXXRecordDecl *Record = dyn_cast<CXXRecordDecl>(Other))
return isInstantiationOf(cast<CXXRecordDecl>(D), Record);
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +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
if (FunctionDecl *Function = dyn_cast<FunctionDecl>(Other))
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 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 (EnumDecl *Enum = dyn_cast<EnumDecl>(Other))
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
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 (VarDecl *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);
if (ClassTemplateDecl *Temp = dyn_cast<ClassTemplateDecl>(Other))
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
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
if (FunctionTemplateDecl *Temp = dyn_cast<FunctionTemplateDecl>(Other))
return isInstantiationOf(cast<FunctionTemplateDecl>(D), Temp);
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 (ClassTemplatePartialSpecializationDecl *PartialSpec
= dyn_cast<ClassTemplatePartialSpecializationDecl>(Other))
return isInstantiationOf(cast<ClassTemplatePartialSpecializationDecl>(D),
PartialSpec);
Don't assert when instantiating member references to fields in anonymous structs. llvm-svn: 80657
2009-09-01 12:26:58 +08:00
if (FieldDecl *Field = dyn_cast<FieldDecl>(Other)) {
if (!Field->getDeclName()) {
// This is an unnamed field.
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
return Ctx.getInstantiatedFromUnnamedFieldDecl(Field) ==
Don't assert when instantiating member references to fields in anonymous structs. llvm-svn: 80657
2009-09-01 12:26:58 +08:00
cast<FieldDecl>(D);
}
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Fix "using typename" and the instantiation of non-dependent using declarations. llvm-svn: 90614
2009-12-05 06:46:56 +08:00
if (UsingDecl *Using = dyn_cast<UsingDecl>(Other))
return isInstantiationOf(cast<UsingDecl>(D), Using, Ctx);
if (UsingShadowDecl *Shadow = dyn_cast<UsingShadowDecl>(Other))
return isInstantiationOf(cast<UsingShadowDecl>(D), Shadow, 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
return D->getDeclName() && isa<NamedDecl>(Other) &&
D->getDeclName() == cast<NamedDecl>(Other)->getDeclName();
}
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);
return 0;
}
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)) {
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
Decl* ID = FindInstantiatedDecl(Loc, D, 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
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,
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) {
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())) {}
// float baz(float(*)()) { return 0.0; }
// 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.
Inline LocalInstantiationScope::getInstantiationOf into its one client, making room for future hacking. llvm-svn: 125770
2011-02-18 03:47:42 +08:00
typedef LocalInstantiationScope::DeclArgumentPack DeclArgumentPack;
llvm::PointerUnion<Decl *, DeclArgumentPack *> *Found
= CurrentInstantiationScope->findInstantiationOf(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
if (Found) {
if (Decl *FD = Found->dyn_cast<Decl *>())
return cast<NamedDecl>(FD);
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +08:00
PR13811: Add a FunctionParmPackExpr node to handle references to function parameter packs where the reference is not being expanded but the pack has been. Previously, Clang would segfault in such cases. llvm-svn: 163672
2012-09-12 08:56:43 +08:00
int PackIdx = ArgumentPackSubstitutionIndex;
assert(PackIdx != -1 && "found declaration pack but not pack expanding");
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
return cast<NamedDecl>((*Found->get<DeclArgumentPack *>())[PackIdx]);
}
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())
return 0;
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;
}
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)
Implement proper substitution for OverloadedFunctionDecls, but substituting each of the functions in the overload set llvm-svn: 80692
2009-09-02 01:53:10 +08:00
return 0;
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))
return 0;
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
}
}
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 *Result = 0;
if (D->getDeclName()) {
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
DeclContext::lookup_result Found = ParentDC->lookup(D->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
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) {
Make the deserialization of Sema::PendingInstantiations lazy. At this point, ASTReader::InitializeSema() has very little interesting work, *except* issues stemming from preloaded declarations. That's something we'll still need to cope with. llvm-svn: 136378
2011-07-29 03:49:54 +08:00
// Load pending instantiations from the external source.
if (!LocalOnly && ExternalSource) {
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
SmallVector<PendingImplicitInstantiation, 4> Pending;
Make the deserialization of Sema::PendingInstantiations lazy. At this point, ASTReader::InitializeSema() has very little interesting work, *except* issues stemming from preloaded declarations. That's something we'll still need to cope with. llvm-svn: 136378
2011-07-29 03:49:54 +08:00
ExternalSource->ReadPendingInstantiations(Pending);
PendingInstantiations.insert(PendingInstantiations.begin(),
Pending.begin(), Pending.end());
}
Whitespace llvm-svn: 141486
2011-10-08 19:31:46 +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
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)) {
One who seeks knowledge learns something new every day. One who seeks the Tao unlearns something new every day. Less and less remains until you arrive at non-action. When you arrive at non-action, nothing will be left undone. llvm-svn: 112244
2010-08-27 07:41:50 +08:00
PrettyDeclStackTraceEntry CrashInfo(*this, Function, SourceLocation(),
"instantiating function 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 = Function->getTemplateSpecializationKind() ==
TSK_ExplicitInstantiationDefinition;
InstantiateFunctionDefinition(/*FIXME:*/Inst.second, Function, true,
DefinitionRequired);
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,
DefinitionRequired);
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) {
for (DeclContext::ddiag_iterator I = Pattern->ddiag_begin(),
E = Pattern->ddiag_end(); I != E; ++I) {
DependentDiagnostic *DD = *I;
switch (DD->getKind()) {
case DependentDiagnostic::Access:
HandleDependentAccessCheck(*DD, TemplateArgs);
break;
}
}
}