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/SemaTemplateInstantiate.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

3711 lines
150 KiB
C++
Raw Normal View History

Implement the basic approach for instantiating types, with a lot of FIXME'd stubs for those types we don't yet know how to instantiate (everything that isn't a template parameter!). We now instantiate default arguments for template type parameters when needed. This will be our testbed while I fill out the remaining type-instantiation logic. llvm-svn: 65649
2009-02-28 03:31:52 +08:00
//===------- SemaTemplateInstantiate.cpp - C++ Template Instantiation ------===/
//
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
2019-01-19 16:50:56 +08:00
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
Implement the basic approach for instantiating types, with a lot of FIXME'd stubs for those types we don't yet know how to instantiate (everything that isn't a template parameter!). We now instantiate default arguments for template type parameters when needed. This will be our testbed while I fill out the remaining type-instantiation logic. llvm-svn: 65649
2009-02-28 03:31:52 +08:00
//===----------------------------------------------------------------------===/
//
// This file implements C++ template instantiation.
//
//===----------------------------------------------------------------------===/
Refactor template instantiation for types into a generic tree transformation template (TreeTransform) that handles the transformation and reconstruction of AST nodes. Template instantiation for types is a (relatively small) customization of the generic tree transformation. llvm-svn: 78071
2009-08-05 00:50:30 +08:00
#include "TreeTransform.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/AST/ASTConsumer.h"
#include "clang/AST/ASTContext.h"
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
#include "clang/AST/ASTLambda.h"
PR29097: add an update record when we instantiate the default member initializer of an imported field. llvm-svn: 279667
2016-08-25 05:25:37 +08:00
#include "clang/AST/ASTMutationListener.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/AST/DeclTemplate.h"
#include "clang/AST/Expr.h"
Sink PrettyDeclStackTrace down to the AST library ...and add some very basic stack trace entries for module building. This would have helped track down rdar://problem/38434694 sooner. llvm-svn: 328276
2018-03-23 08:07:18 +08:00
#include "clang/AST/PrettyDeclStackTrace.h"
[Concepts] Instantiate invented template type parameter type-constraint along with function parameters We previously instantiated type-constraints of template type parameters along with the type parameter itself, this caused problems when the type-constraints created by abbreviated templates refreneced other parameters in the abbreviated templates. When encountering a template type parameter with a type constraint, if it is implicit, delay instantiation of the type-constraint until the function parameter which created the invented template type parameter is instantiated. Reland after fixing bug caused by another flow reaching SubstParmVarDecl and instantiating the TypeConstraint a second time.
2020-02-03 21:44:33 +08:00
#include "clang/AST/TypeVisitor.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/Basic/LangOptions.h"
Improve behavior in the case of stack exhaustion. Summary: Clang performs various recursive operations (such as template instantiation), and may use non-trivial amounts of stack space in each recursive step (for instance, due to recursive AST walks). While we try to keep the stack space used by such steps to a minimum and we have explicit limits on the number of such steps we perform, it's impractical to guarantee that we won't blow out the stack on deeply recursive template instantiations on complex ASTs, even with only a moderately high instantiation depth limit. The user experience in these cases is generally terrible: we crash with no hint of what went wrong. Under this patch, we attempt to do better: * Detect when the stack is nearly exhausted, and produce a warning with a nice template instantiation backtrace, telling the user that we might run slowly or crash. * For cases where we're forced to trigger recursive template instantiation in arbitrarily-deeply-nested contexts, check whether we're nearly out of stack space and allocate a new stack (by spawning a new thread) after producing the warning. Reviewers: rnk, aaron.ballman Subscribers: mgorny, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66361 llvm-svn: 369940
2019-08-27 02:18:07 +08:00
#include "clang/Basic/Stack.h"
Prune TargetInfo.h include from ParsedAttr.h, NFC Saves ~400 includes of related headers: $ diff -u <(sort thedeps-before.txt) <(sort thedeps-after.txt) \ | grep '^[-+] ' | sort | uniq -c | sort -nr 468 - llvm-project/clang/include/clang/Basic/TargetInfo.h 468 - llvm-project/clang/include/clang/Basic/TargetCXXABI.h 368 - llvm-project/llvm/include/llvm/Support/CodeGen.h 368 - llvm-project/clang/include/clang/Basic/XRayInstr.h 368 - llvm-project/clang/include/clang/Basic/CodeGenOptions.h 368 - llvm-project/clang/include/clang/Basic/CodeGenOptions.def 367 - llvm-project/llvm/include/llvm/ADT/FloatingPointMode.h 367 - llvm-project/clang/include/clang/Basic/DebugInfoOptions.h
2020-03-12 11:43:59 +08:00
#include "clang/Basic/TargetInfo.h"
Another step in the process of making the parser depend on Sema: - move DeclSpec &c into the Sema library - move ParseAST into the Parse library Reflect this change in a thousand different includes. Reflect this change in the link orders. llvm-svn: 111667
2010-08-21 02:27:03 +08:00
#include "clang/Sema/DeclSpec.h"
Implement support for C++11 in-class initialization of non-static data members. llvm-svn: 132878
2011-06-12 01:19:42 +08:00
#include "clang/Sema/Initialization.h"
Move Sema's headers into include/clang/Sema, renaming a few along the way. llvm-svn: 110945
2010-08-13 04:07:10 +08:00
#include "clang/Sema/Lookup.h"
Prune TargetInfo.h include from ParsedAttr.h, NFC Saves ~400 includes of related headers: $ diff -u <(sort thedeps-before.txt) <(sort thedeps-after.txt) \ | grep '^[-+] ' | sort | uniq -c | sort -nr 468 - llvm-project/clang/include/clang/Basic/TargetInfo.h 468 - llvm-project/clang/include/clang/Basic/TargetCXXABI.h 368 - llvm-project/llvm/include/llvm/Support/CodeGen.h 368 - llvm-project/clang/include/clang/Basic/XRayInstr.h 368 - llvm-project/clang/include/clang/Basic/CodeGenOptions.h 368 - llvm-project/clang/include/clang/Basic/CodeGenOptions.def 367 - llvm-project/llvm/include/llvm/ADT/FloatingPointMode.h 367 - llvm-project/clang/include/clang/Basic/DebugInfoOptions.h
2020-03-12 11:43:59 +08:00
#include "clang/Sema/SemaConcept.h"
#include "clang/Sema/SemaInternal.h"
Struggle mightily against header inclusion in Sema.h. llvm-svn: 111904
2010-08-24 15:21:54 +08:00
#include "clang/Sema/Template.h"
Move more stuff out of Sema.h. llvm-svn: 112026
2010-08-25 13:32:35 +08:00
#include "clang/Sema/TemplateDeduction.h"
[Templight] Template Instantiation Observer This patch adds a base-class called TemplateInstantiationObserver which gets notified whenever a template instantiation is entered or exited during semantic analysis. This is a base class used to implement the template profiling and debugging tool called Templight (https://github.com/mikael-s-persson/templight). The patch also makes a few more changes: * ActiveTemplateInstantiation class is moved out of the Sema class (so it can be used with inclusion of Sema.h). * CreateFrontendAction function in front-end utilities is given external linkage (not longer a hidden static function). * TemplateInstObserverChain data member added to Sema class to hold the list of template-inst observers. * Notifications to the template-inst observer are added at the key places where templates are instantiated. Patch by: Abel Sinkovics! Differential Revision: https://reviews.llvm.org/D5767 llvm-svn: 324808
2018-02-10 22:04:45 +08:00
#include "clang/Sema/TemplateInstCallback.h"
Adds `-ftime-trace` option to clang that produces Chrome `chrome://tracing` compatible JSON profiling output dumps. This change adds hierarchical "time trace" profiling blocks that can be visualized in Chrome, in a "flame chart" style. Each profiling block can have a "detail" string that for example indicates the file being processed, template name being instantiated, function being optimized etc. This is taken from GitHub PR: https://github.com/aras-p/llvm-project-20170507/pull/2 Patch by Aras Pranckevičius. Differential Revision: https://reviews.llvm.org/D58675 llvm-svn: 357340
2019-03-30 16:42:48 +08:00
#include "llvm/Support/TimeProfiler.h"
Implement the basic approach for instantiating types, with a lot of FIXME'd stubs for those types we don't yet know how to instantiate (everything that isn't a template parameter!). We now instantiate default arguments for template type parameters when needed. This will be our testbed while I fill out the remaining type-instantiation logic. llvm-svn: 65649
2009-02-28 03:31:52 +08:00
using namespace clang;
Move more stuff out of Sema.h. llvm-svn: 112026
2010-08-25 13:32:35 +08:00
using namespace sema;
Implement the basic approach for instantiating types, with a lot of FIXME'd stubs for those types we don't yet know how to instantiate (everything that isn't a template parameter!). We now instantiate default arguments for template type parameters when needed. This will be our testbed while I fill out the remaining type-instantiation logic. llvm-svn: 65649
2009-02-28 03:31:52 +08:00
Add a notion of "post-diagnostic hooks", which are callbacks attached to a diagnostic that will be invoked after the diagnostic (if it is not suppressed). The hooks are allowed to produce additional diagnostics (typically notes) that provide more information. We should be able to use this to help diagnostic clients link notes back to the diagnostic they clarify. Comments welcome; I'll write up documentation and convert other clients (e.g., overload resolution failures) if there are no screams of protest. As the first client of post-diagnostic hooks, we now produce a template instantiation backtrace when a failure occurs during template instantiation. There's still more work to do to make this output pretty, if that's even possible. llvm-svn: 66557
2009-03-11 02:03:33 +08:00
//===----------------------------------------------------------------------===/
// Template Instantiation Support
//===----------------------------------------------------------------------===/
Remove \brief commands from doxygen comments. This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
2018-05-09 09:00:01 +08:00
/// Retrieve the template argument list(s) that should be used to
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
/// instantiate the definition of the given declaration.
Improve instantiation of default template arguments for nested templates. The instantiation of these default arguments must be (and now, is) delayed until the template argument is actually used, at which point we substitute all levels of template arguments concurrently. llvm-svn: 86578
2009-11-10 03:17:50 +08:00
///
/// \param D the declaration for which we are computing template instantiation
/// arguments.
///
/// \param Innermost if non-NULL, the innermost template argument list.
Default function arguments for function template specializations always come from the primary template, so gather the instantiation template arguments from the primary template. llvm-svn: 95380
2010-02-05 15:33:43 +08:00
///
/// \param RelativeToPrimary true if we should get the template
/// arguments relative to the primary template, even when we're
/// dealing with a specialization. This is only relevant for function
/// template specializations.
When computing the template arguments for the instantiation of a friend function template, be sure to adjust the computed template argument lists based on the location of the definition of the function template: it's possible that the definition we're instantiating with and the template declaration that we found when creating the specialization are in different contexts, which meant that we would end up using the wrong template arguments for instantiation. Fixes PR7013; all Boost.DynamicBitset tests now pass. llvm-svn: 102974
2010-05-04 07:29:10 +08:00
///
/// \param Pattern If non-NULL, indicates the pattern from which we will be
/// instantiating the definition of the given declaration, \p D. This is
/// used to determine the proper set of template instantiation arguments for
/// friend function template specializations.
Collect multiple levels of template arguments into a new type, MultiLevelTemplateArgumentList. This is a baby step toward instantiating member templates; no intended functionality change yet. llvm-svn: 80380
2009-08-29 01:37:35 +08:00
MultiLevelTemplateArgumentList
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
Sema::getTemplateInstantiationArgs(NamedDecl *D,
Default function arguments for function template specializations always come from the primary template, so gather the instantiation template arguments from the primary template. llvm-svn: 95380
2010-02-05 15:33:43 +08:00
const TemplateArgumentList *Innermost,
When computing the template arguments for the instantiation of a friend function template, be sure to adjust the computed template argument lists based on the location of the definition of the function template: it's possible that the definition we're instantiating with and the template declaration that we found when creating the specialization are in different contexts, which meant that we would end up using the wrong template arguments for instantiation. Fixes PR7013; all Boost.DynamicBitset tests now pass. llvm-svn: 102974
2010-05-04 07:29:10 +08:00
bool RelativeToPrimary,
const FunctionDecl *Pattern) {
Collect multiple levels of template arguments into a new type, MultiLevelTemplateArgumentList. This is a baby step toward instantiating member templates; no intended functionality change yet. llvm-svn: 80380
2009-08-29 01:37:35 +08:00
// Accumulate the set of template argument lists in this structure.
MultiLevelTemplateArgumentList Result;
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Improve instantiation of default template arguments for nested templates. The instantiation of these default arguments must be (and now, is) delayed until the template argument is actually used, at which point we substitute all levels of template arguments concurrently. llvm-svn: 86578
2009-11-10 03:17:50 +08:00
if (Innermost)
Result.addOuterTemplateArguments(Innermost);
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
Collect multiple levels of template arguments into a new type, MultiLevelTemplateArgumentList. This is a baby step toward instantiating member templates; no intended functionality change yet. llvm-svn: 80380
2009-08-29 01:37:35 +08:00
DeclContext *Ctx = dyn_cast<DeclContext>(D);
Add an assertion to tell us when we're going off the deep end trying to determine outer template arguments lists for template parameters. This is actually the problem behind PR9643, which I have yet to figure out how to fix. llvm-svn: 131822
2011-05-22 08:21:10 +08:00
if (!Ctx) {
Collect multiple levels of template arguments into a new type, MultiLevelTemplateArgumentList. This is a baby step toward instantiating member templates; no intended functionality change yet. llvm-svn: 80380
2009-08-29 01:37:35 +08:00
Ctx = D->getDeclContext();
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
PR41607: Don't forget to substitute outer template arguments into a class-scope explicit specialization of a class template. llvm-svn: 359266
2019-04-26 10:11:23 +08:00
// Add template arguments from a variable template instantiation. For a
// class-scope explicit specialization, there are no template arguments
// at this level, but there may be enclosing template arguments.
VarTemplateSpecializationDecl *Spec =
dyn_cast<VarTemplateSpecializationDecl>(D);
if (Spec && !Spec->isClassScopeExplicitSpecialization()) {
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
// We're done when we hit an explicit specialization.
if (Spec->getSpecializationKind() == TSK_ExplicitSpecialization &&
!isa<VarTemplatePartialSpecializationDecl>(Spec))
return Result;
Result.addOuterTemplateArguments(&Spec->getTemplateInstantiationArgs());
// If this variable template specialization was instantiated from a
// specialized member that is a variable template, we're done.
assert(Spec->getSpecializedTemplate() && "No variable template?");
Clean up variable template handling a bit, and correct the behavior of name lookup when declaring a variable template specialization. llvm-svn: 199438
2014-01-17 07:39:20 +08:00
llvm::PointerUnion<VarTemplateDecl*,
VarTemplatePartialSpecializationDecl*> Specialized
= Spec->getSpecializedTemplateOrPartial();
if (VarTemplatePartialSpecializationDecl *Partial =
Specialized.dyn_cast<VarTemplatePartialSpecializationDecl *>()) {
if (Partial->isMemberSpecialization())
return Result;
} else {
VarTemplateDecl *Tmpl = Specialized.get<VarTemplateDecl *>();
if (Tmpl->isMemberSpecialization())
return Result;
}
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 performing substitution of default template template parameters before the template parameters have acquired a proper context (e.g., because the enclosing context has yet to be built), provide empty parameter lists for all outer template parameter scopes to inhibit any substitution for those template parameters. Fixes PR9643 / <rdar://problem/9251019>. llvm-svn: 133055
2011-06-15 22:20:42 +08:00
// If we have a template template parameter with translation unit context,
// then we're performing substitution into a default template argument of
// this template template parameter before we've constructed the template
// that will own this template template parameter. In this case, we
// use empty template parameter lists for all of the outer templates
// to avoid performing any substitutions.
if (Ctx->isTranslationUnit()) {
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
if (TemplateTemplateParmDecl *TTP
When performing substitution of default template template parameters before the template parameters have acquired a proper context (e.g., because the enclosing context has yet to be built), provide empty parameter lists for all outer template parameter scopes to inhibit any substitution for those template parameters. Fixes PR9643 / <rdar://problem/9251019>. llvm-svn: 133055
2011-06-15 22:20:42 +08:00
= dyn_cast<TemplateTemplateParmDecl>(D)) {
for (unsigned I = 0, N = TTP->getDepth() + 1; I != N; ++I)
A little ArrayRef'ization. llvm-svn: 182074
2013-05-17 11:04:50 +08:00
Result.addOuterTemplateArguments(None);
When performing substitution of default template template parameters before the template parameters have acquired a proper context (e.g., because the enclosing context has yet to be built), provide empty parameter lists for all outer template parameter scopes to inhibit any substitution for those template parameters. Fixes PR9643 / <rdar://problem/9251019>. llvm-svn: 133055
2011-06-15 22:20:42 +08:00
return Result;
}
}
Add an assertion to tell us when we're going off the deep end trying to determine outer template arguments lists for template parameters. This is actually the problem behind PR9643, which I have yet to figure out how to fix. llvm-svn: 131822
2011-05-22 08:21:10 +08:00
}
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
Ensure code generation for friend declarations in class templates. llvm-svn: 80418
2009-08-29 11:16:09 +08:00
while (!Ctx->isFileContext()) {
Collect multiple levels of template arguments into a new type, MultiLevelTemplateArgumentList. This is a baby step toward instantiating member templates; no intended functionality change yet. llvm-svn: 80380
2009-08-29 01:37:35 +08:00
// Add template arguments from a class template instantiation.
PR41607: Don't forget to substitute outer template arguments into a class-scope explicit specialization of a class template. llvm-svn: 359266
2019-04-26 10:11:23 +08:00
ClassTemplateSpecializationDecl *Spec
= dyn_cast<ClassTemplateSpecializationDecl>(Ctx);
if (Spec && !Spec->isClassScopeExplicitSpecialization()) {
Collect multiple levels of template arguments into a new type, MultiLevelTemplateArgumentList. This is a baby step toward instantiating member templates; no intended functionality change yet. llvm-svn: 80380
2009-08-29 01:37:35 +08:00
// We're done when we hit an explicit specialization.
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
if (Spec->getSpecializationKind() == TSK_ExplicitSpecialization &&
!isa<ClassTemplatePartialSpecializationDecl>(Spec))
Collect multiple levels of template arguments into a new type, MultiLevelTemplateArgumentList. This is a baby step toward instantiating member templates; no intended functionality change yet. llvm-svn: 80380
2009-08-29 01:37:35 +08:00
break;
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Collect multiple levels of template arguments into a new type, MultiLevelTemplateArgumentList. This is a baby step toward instantiating member templates; no intended functionality change yet. llvm-svn: 80380
2009-08-29 01:37:35 +08:00
Result.addOuterTemplateArguments(&Spec->getTemplateInstantiationArgs());
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
// If this class template specialization was instantiated from a
When explicitly specializing a member that is a template, mark the template as a specialization. For example, this occurs with: template<typename T> struct X { template<typename U> struct Inner { /* ... */ }; }; template<> template<typename T> struct X<int>::Inner { T member; }; We need to treat templates that are member specializations as special in two contexts: - When looking for a definition of a member template, we look through the instantiation chain until we hit the primary template *or a member specialization*. This allows us to distinguish between the primary "Inner" definition and the X<int>::Inner definition, above. - When computing all of the levels of template arguments needed to instantiate a member template, don't add template arguments from contexts outside of the instantiation of a member specialization, since the user has already manually substituted those arguments. Fix up the existing test for p18, which was actually wrong (but we didn't diagnose it because of our poor handling of member specializations of templates), and add a new test for member specializations of templates. llvm-svn: 83974
2009-10-14 00:30:37 +08:00
// specialized member that is a class template, we're done.
assert(Spec->getSpecializedTemplate() && "No class template?");
if (Spec->getSpecializedTemplate()->isMemberSpecialization())
break;
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
}
Collect multiple levels of template arguments into a new type, MultiLevelTemplateArgumentList. This is a baby step toward instantiating member templates; no intended functionality change yet. llvm-svn: 80380
2009-08-29 01:37:35 +08:00
// Add template arguments from a function template specialization.
Ensure code generation for friend declarations in class templates. llvm-svn: 80418
2009-08-29 11:16:09 +08:00
else if (FunctionDecl *Function = dyn_cast<FunctionDecl>(Ctx)) {
Default function arguments for function template specializations always come from the primary template, so gather the instantiation template arguments from the primary template. llvm-svn: 95380
2010-02-05 15:33:43 +08:00
if (!RelativeToPrimary &&
Replace ad-hoc tracking of pattern for an instantiated class-scope explicit function specialization with the MemberSpecializationInfo used everywhere else. Not NFC: the ad-hoc pattern tracking was not being serialized / deserialized properly. That's fixed here. llvm-svn: 359747
2019-05-02 08:49:14 +08:00
Function->getTemplateSpecializationKindForInstantiation() ==
TSK_ExplicitSpecialization)
When explicitly specializing a member that is a template, mark the template as a specialization. For example, this occurs with: template<typename T> struct X { template<typename U> struct Inner { /* ... */ }; }; template<> template<typename T> struct X<int>::Inner { T member; }; We need to treat templates that are member specializations as special in two contexts: - When looking for a definition of a member template, we look through the instantiation chain until we hit the primary template *or a member specialization*. This allows us to distinguish between the primary "Inner" definition and the X<int>::Inner definition, above. - When computing all of the levels of template arguments needed to instantiate a member template, don't add template arguments from contexts outside of the instantiation of a member specialization, since the user has already manually substituted those arguments. Fix up the existing test for p18, which was actually wrong (but we didn't diagnose it because of our poor handling of member specializations of templates), and add a new test for member specializations of templates. llvm-svn: 83974
2009-10-14 00:30:37 +08:00
break;
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
Properly collect template arguments from a class-scope function template specialization. Fixes a crash-on-valid if further template parameters are introduced within the specialization (by a generic lambda).
2020-11-11 07:52:36 +08:00
if (!RelativeToPrimary && Function->getTemplateSpecializationKind() ==
TSK_ExplicitSpecialization) {
// This is an implicit instantiation of an explicit specialization. We
// don't get any template arguments from this function but might get
// some from an enclosing template.
} else if (const TemplateArgumentList *TemplateArgs
When explicitly specializing a member that is a template, mark the template as a specialization. For example, this occurs with: template<typename T> struct X { template<typename U> struct Inner { /* ... */ }; }; template<> template<typename T> struct X<int>::Inner { T member; }; We need to treat templates that are member specializations as special in two contexts: - When looking for a definition of a member template, we look through the instantiation chain until we hit the primary template *or a member specialization*. This allows us to distinguish between the primary "Inner" definition and the X<int>::Inner definition, above. - When computing all of the levels of template arguments needed to instantiate a member template, don't add template arguments from contexts outside of the instantiation of a member specialization, since the user has already manually substituted those arguments. Fix up the existing test for p18, which was actually wrong (but we didn't diagnose it because of our poor handling of member specializations of templates), and add a new test for member specializations of templates. llvm-svn: 83974
2009-10-14 00:30:37 +08:00
= Function->getTemplateSpecializationArgs()) {
// Add the template arguments for this specialization.
Collect multiple levels of template arguments into a new type, MultiLevelTemplateArgumentList. This is a baby step toward instantiating member templates; no intended functionality change yet. llvm-svn: 80380
2009-08-29 01:37:35 +08:00
Result.addOuterTemplateArguments(TemplateArgs);
Ensure code generation for friend declarations in class templates. llvm-svn: 80418
2009-08-29 11:16:09 +08:00
When explicitly specializing a member that is a template, mark the template as a specialization. For example, this occurs with: template<typename T> struct X { template<typename U> struct Inner { /* ... */ }; }; template<> template<typename T> struct X<int>::Inner { T member; }; We need to treat templates that are member specializations as special in two contexts: - When looking for a definition of a member template, we look through the instantiation chain until we hit the primary template *or a member specialization*. This allows us to distinguish between the primary "Inner" definition and the X<int>::Inner definition, above. - When computing all of the levels of template arguments needed to instantiate a member template, don't add template arguments from contexts outside of the instantiation of a member specialization, since the user has already manually substituted those arguments. Fix up the existing test for p18, which was actually wrong (but we didn't diagnose it because of our poor handling of member specializations of templates), and add a new test for member specializations of templates. llvm-svn: 83974
2009-10-14 00:30:37 +08:00
// If this function was instantiated from a specialized member that is
// a function template, we're done.
assert(Function->getPrimaryTemplate() && "No function template?");
if (Function->getPrimaryTemplate()->isMemberSpecialization())
break;
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
// If this function is a generic lambda specialization, we are done.
[Concepts] Function trailing requires clauses Function trailing requires clauses now parsed, supported in overload resolution and when calling, referencing and taking the address of functions or function templates. Differential Revision: https://reviews.llvm.org/D43357
2020-01-09 21:07:51 +08:00
if (isGenericLambdaCallOperatorOrStaticInvokerSpecialization(Function))
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
break;
When determining template instantiation arguments within a function template (not a specialization!), use the "injected" function template arguments, which correspond to the template parameters of the function template. This is required when substituting into the default template parameters of template template parameters within a function template. Fixes PR9016. llvm-svn: 127092
2011-03-06 01:54:25 +08:00
} else if (FunctionTemplateDecl *FunTmpl
= Function->getDescribedFunctionTemplate()) {
// Add the "injected" template arguments.
A little ArrayRef'ization. llvm-svn: 182074
2013-05-17 11:04:50 +08:00
Result.addOuterTemplateArguments(FunTmpl->getInjectedTemplateArgs());
When explicitly specializing a member that is a template, mark the template as a specialization. For example, this occurs with: template<typename T> struct X { template<typename U> struct Inner { /* ... */ }; }; template<> template<typename T> struct X<int>::Inner { T member; }; We need to treat templates that are member specializations as special in two contexts: - When looking for a definition of a member template, we look through the instantiation chain until we hit the primary template *or a member specialization*. This allows us to distinguish between the primary "Inner" definition and the X<int>::Inner definition, above. - When computing all of the levels of template arguments needed to instantiate a member template, don't add template arguments from contexts outside of the instantiation of a member specialization, since the user has already manually substituted those arguments. Fix up the existing test for p18, which was actually wrong (but we didn't diagnose it because of our poor handling of member specializations of templates), and add a new test for member specializations of templates. llvm-svn: 83974
2009-10-14 00:30:37 +08:00
}
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
Ensure code generation for friend declarations in class templates. llvm-svn: 80418
2009-08-29 11:16:09 +08:00
// If this is a friend declaration and it declares an entity at
// namespace scope, take arguments from its lexical parent
When computing the template arguments for the instantiation of a friend function template, be sure to adjust the computed template argument lists based on the location of the definition of the function template: it's possible that the definition we're instantiating with and the template declaration that we found when creating the specialization are in different contexts, which meant that we would end up using the wrong template arguments for instantiation. Fixes PR7013; all Boost.DynamicBitset tests now pass. llvm-svn: 102974
2010-05-04 07:29:10 +08:00
// instead of its semantic parent, unless of course the pattern we're
// instantiating actually comes from the file's context!
Ensure code generation for friend declarations in class templates. llvm-svn: 80418
2009-08-29 11:16:09 +08:00
if (Function->getFriendObjectKind() &&
When computing the template arguments for the instantiation of a friend function template, be sure to adjust the computed template argument lists based on the location of the definition of the function template: it's possible that the definition we're instantiating with and the template declaration that we found when creating the specialization are in different contexts, which meant that we would end up using the wrong template arguments for instantiation. Fixes PR7013; all Boost.DynamicBitset tests now pass. llvm-svn: 102974
2010-05-04 07:29:10 +08:00
Function->getDeclContext()->isFileContext() &&
(!Pattern || !Pattern->getLexicalDeclContext()->isFileContext())) {
Ensure code generation for friend declarations in class templates. llvm-svn: 80418
2009-08-29 11:16:09 +08:00
Ctx = Function->getLexicalDeclContext();
Default function arguments for function template specializations always come from the primary template, so gather the instantiation template arguments from the primary template. llvm-svn: 95380
2010-02-05 15:33:43 +08:00
RelativeToPrimary = false;
Ensure code generation for friend declarations in class templates. llvm-svn: 80418
2009-08-29 11:16:09 +08:00
continue;
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
}
} else if (CXXRecordDecl *Rec = dyn_cast<CXXRecordDecl>(Ctx)) {
if (ClassTemplateDecl *ClassTemplate = Rec->getDescribedClassTemplate()) {
QualType T = ClassTemplate->getInjectedClassNameSpecialization();
A little ArrayRef'ization. llvm-svn: 182074
2013-05-17 11:04:50 +08:00
const TemplateSpecializationType *TST =
cast<TemplateSpecializationType>(Context.getCanonicalType(T));
Result.addOuterTemplateArguments(
llvm::makeArrayRef(TST->getArgs(), TST->getNumArgs()));
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
if (ClassTemplate->isMemberSpecialization())
break;
Ensure code generation for friend declarations in class templates. llvm-svn: 80418
2009-08-29 11:16:09 +08:00
}
Collect multiple levels of template arguments into a new type, MultiLevelTemplateArgumentList. This is a baby step toward instantiating member templates; no intended functionality change yet. llvm-svn: 80380
2009-08-29 01:37:35 +08:00
}
Ensure code generation for friend declarations in class templates. llvm-svn: 80418
2009-08-29 11:16:09 +08:00
Ctx = Ctx->getParent();
Default function arguments for function template specializations always come from the primary template, so gather the instantiation template arguments from the primary template. llvm-svn: 95380
2010-02-05 15:33:43 +08:00
RelativeToPrimary = false;
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
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Collect multiple levels of template arguments into a new type, MultiLevelTemplateArgumentList. This is a baby step toward instantiating member templates; no intended functionality change yet. llvm-svn: 80380
2009-08-29 01:37:35 +08:00
return Result;
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
}
Rename ActiveTemplateInstantiation to CodeSynthesisContext in preparation for using it for other kinds of context (where we currently produce context notes in a highly ad-hoc manner). llvm-svn: 295919
2017-02-23 09:43:54 +08:00
bool Sema::CodeSynthesisContext::isInstantiationRecord() const {
Improve diagnostics when a default template argument does not match with its corresponding template parameter. This can happen when we performed some substitution into the default template argument and what we had doesn't match any more, e.g., template<int> struct A; template<typename T, template<T> class X = A> class B; B<long> b; Previously, we'd emit a pretty but disembodied diagnostic showing how the default argument didn't match the template parameter. The diagnostic was good, but nothing tied it to the *use* of the default argument in "B<long>". This commit fixes that. Also, tweak the counting of active template instantiations to avoid counting non-instantiation records, such as those we create for (surprise!) checking default arguments, instantiating default arguments, and performing substitutions as part of template argument deduction. llvm-svn: 86884
2009-11-12 05:54:23 +08:00
switch (Kind) {
case TemplateInstantiation:
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
case ExceptionSpecInstantiation:
Improve diagnostics when a default template argument does not match with its corresponding template parameter. This can happen when we performed some substitution into the default template argument and what we had doesn't match any more, e.g., template<int> struct A; template<typename T, template<T> class X = A> class B; B<long> b; Previously, we'd emit a pretty but disembodied diagnostic showing how the default argument didn't match the template parameter. The diagnostic was good, but nothing tied it to the *use* of the default argument in "B<long>". This commit fixes that. Also, tweak the counting of active template instantiations to avoid counting non-instantiation records, such as those we create for (surprise!) checking default arguments, instantiating default arguments, and performing substitutions as part of template argument deduction. llvm-svn: 86884
2009-11-12 05:54:23 +08:00
case DefaultTemplateArgumentInstantiation:
case DefaultFunctionArgumentInstantiation:
case ExplicitTemplateArgumentSubstitution:
case DeducedTemplateArgumentSubstitution:
case PriorTemplateArgumentSubstitution:
[Concepts] Concept Specialization Expressions Part of C++20 Concepts implementation effort. Added Concept Specialization Expressions that are created when a concept is refe$ D41217 on Phabricator. (recommit after fixing failing Parser test on windows) llvm-svn: 374903
2019-10-15 23:24:26 +08:00
case ConstraintsCheck:
[Concepts] Requires Expressions Implement support for C++2a requires-expressions. Re-commit after compilation failure on some platforms due to alignment issues with PointerIntPair. Differential Revision: https://reviews.llvm.org/D50360
2020-01-18 15:11:43 +08:00
case NestedRequirementConstraintsCheck:
PR9793: Treat substitution as an instantiation step for the purpose of the -ftemplate-depth limit. There are various ways to get an infinite (or merely huge) stack of substitutions with no intervening instantiations. This is also consistent with gcc's behavior. llvm-svn: 159907
2012-07-08 10:38:24 +08:00
return true;
[Concepts] Requires Expressions Implement support for C++2a requires-expressions. Re-commit after compilation failure on some platforms due to alignment issues with PointerIntPair. Differential Revision: https://reviews.llvm.org/D50360
2020-01-18 15:11:43 +08:00
case RequirementInstantiation:
Improve diagnostics when a default template argument does not match with its corresponding template parameter. This can happen when we performed some substitution into the default template argument and what we had doesn't match any more, e.g., template<int> struct A; template<typename T, template<T> class X = A> class B; B<long> b; Previously, we'd emit a pretty but disembodied diagnostic showing how the default argument didn't match the template parameter. The diagnostic was good, but nothing tied it to the *use* of the default argument in "B<long>". This commit fixes that. Also, tweak the counting of active template instantiations to avoid counting non-instantiation records, such as those we create for (surprise!) checking default arguments, instantiating default arguments, and performing substitutions as part of template argument deduction. llvm-svn: 86884
2009-11-12 05:54:23 +08:00
case DefaultTemplateArgumentChecking:
Add context note to diagnostics that occur while declaring an implicit special member function. llvm-svn: 296020
2017-02-24 05:43:43 +08:00
case DeclaringSpecialMember:
[c++20] Implement P1185R2 (as modified by P2002R0). For each defaulted operator<=> in a class that doesn't explicitly declare any operator==, also inject a matching implicit defaulted operator==.
2019-12-11 08:45:02 +08:00
case DeclaringImplicitEqualityComparison:
Switch from using a DiagnosticTrap and a note for "while defining a special member function" context notes to registering an entry on the context stack. Also reorder the steps within defining special members to be consistent. This has a few benefits: if multiple diagnostics are produced while checking such a member, the note is now attached to the first such diagnostic rather than the last, this prepares us for persisting these diagnostics between the point at which we require the implicit instantiation of a template and the point at which that instantiation is actually performed, and this fixes some cases where we would fail to produce a full note stack leading back to user code in the case of such a diagnostic. The reordering exposed a case where we could recursively attempt to define a defaulted destructor while we're already defining one (and other such cases also appear to be possible, with or without this change), so this change also reuses the "willHaveBody" flag on function declarations to track that we're in the middle of synthesizing a body for the function and bails out if we try to define a function that we're already defining. llvm-svn: 303930
2017-05-26 06:47:05 +08:00
case DefiningSynthesizedFunction:
PR38627: Fix handling of exception specification adjustment for destructors. We previously tried to patch up the exception specification after completing the class, which went wrong when the exception specification was needed within the class body (in particular, by a friend redeclaration of the destructor in a nested class). We now mark the destructor as having a not-yet-computed exception specification immediately after creating it. This requires delaying various checks against the exception specification (where we'd previously have just got the wrong exception specification, and now find we have an exception specification that we can't compute yet) when those checks fire while the class is being defined. This also exposed an issue that we were missing a CodeSynthesisContext for computation of exception specifications (otherwise we'd fail to make the module containing the definition of the class visible when computing its members' exception specs). Adding that incidentally also gives us a diagnostic quality improvement. This has also exposed an pre-existing problem: making the exception specification evaluation context a non-SFINAE context (as it should be) results in a bootstrap failure; PR38850 filed for this. llvm-svn: 341499
2018-09-06 06:30:37 +08:00
case ExceptionSpecEvaluation:
[Concepts] Concept Specialization Expressions Part of C++20 Concepts implementation effort. Added Concept Specialization Expressions that are created when a concept is refe$ D41217 on Phabricator. (recommit after fixing failing Parser test on windows) llvm-svn: 374903
2019-10-15 23:24:26 +08:00
case ConstraintSubstitution:
[Concepts] Constrained partial specializations and function overloads. Added support for constraint satisfaction checking and partial ordering of constraints in constrained partial specialization and function template overloads. Re-commit after fixing another crash (added regression test). Differential Revision: https://reviews.llvm.org/D41910
2019-12-23 14:37:35 +08:00
case ParameterMappingSubstitution:
case ConstraintNormalization:
[c++20] Add rewriting from comparison operators to <=> / ==. This adds support for rewriting <, >, <=, and >= to a normal or reversed call to operator<=>, for rewriting != to a normal or reversed call to operator==, and for rewriting <=> and == to reversed forms of those same operators. Note that this is a breaking change for various C++17 code patterns, including some in use in LLVM. The most common patterns (where an operator== becomes ambiguous with a reversed form of itself) are still accepted under this patch, as an extension (with a warning). I'm hopeful that we can get the language rules fixed before C++20 ships, and the extension warning is aimed primarily at providing data to inform that decision. llvm-svn: 375306
2019-10-19 08:04:43 +08:00
case RewritingOperatorAsSpaceship:
Remove improper uses of DiagnosticErrorTrap and hasErrorOccurred. DiagnosticErrorTrap is usually inappropriate because it indicates whether an error message was rendered in a given region (and is therefore affected by -ferror-limit and by suppression of errors if we see an invalid declaration). hasErrorOccurred() is usually inappropriate because it indicates whethere an "error:" message was displayed, regardless of whether the message was a warning promoted to an error, and therefore depends on things like -Werror that are usually irrelevant. Where applicable, CodeSynthesisContexts are used to attach notes to the first diagnostic produced in a region of code, isnstead of using an error trap and then attaching a note to whichever diagnostic happened to be produced last (or suppressing the note if the final diagnostic is a disabled warning!). This is mostly NFC.
2020-06-09 05:04:54 +08:00
case InitializingStructuredBinding:
case MarkingClassDllexported:
Improve diagnostics when a default template argument does not match with its corresponding template parameter. This can happen when we performed some substitution into the default template argument and what we had doesn't match any more, e.g., template<int> struct A; template<typename T, template<T> class X = A> class B; B<long> b; Previously, we'd emit a pretty but disembodied diagnostic showing how the default argument didn't match the template parameter. The diagnostic was good, but nothing tied it to the *use* of the default argument in "B<long>". This commit fixes that. Also, tweak the counting of active template instantiations to avoid counting non-instantiation records, such as those we create for (surprise!) checking default arguments, instantiating default arguments, and performing substitutions as part of template argument deduction. llvm-svn: 86884
2009-11-12 05:54:23 +08:00
return false;
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
[Templight] Template Instantiation Observer This patch adds a base-class called TemplateInstantiationObserver which gets notified whenever a template instantiation is entered or exited during semantic analysis. This is a base class used to implement the template profiling and debugging tool called Templight (https://github.com/mikael-s-persson/templight). The patch also makes a few more changes: * ActiveTemplateInstantiation class is moved out of the Sema class (so it can be used with inclusion of Sema.h). * CreateFrontendAction function in front-end utilities is given external linkage (not longer a hidden static function). * TemplateInstObserverChain data member added to Sema class to hold the list of template-inst observers. * Notifications to the template-inst observer are added at the key places where templates are instantiated. Patch by: Abel Sinkovics! Differential Revision: https://reviews.llvm.org/D5767 llvm-svn: 324808
2018-02-10 22:04:45 +08:00
// This function should never be called when Kind's value is Memoization.
case Memoization:
break;
Improve diagnostics when a default template argument does not match with its corresponding template parameter. This can happen when we performed some substitution into the default template argument and what we had doesn't match any more, e.g., template<int> struct A; template<typename T, template<T> class X = A> class B; B<long> b; Previously, we'd emit a pretty but disembodied diagnostic showing how the default argument didn't match the template parameter. The diagnostic was good, but nothing tied it to the *use* of the default argument in "B<long>". This commit fixes that. Also, tweak the counting of active template instantiations to avoid counting non-instantiation records, such as those we create for (surprise!) checking default arguments, instantiating default arguments, and performing substitutions as part of template argument deduction. llvm-svn: 86884
2009-11-12 05:54:23 +08:00
}
Remove unreachable code in Clang. (replace with llvm_unreachable where appropriate or when GCC requires it) llvm-svn: 148292
2012-01-17 14:56:22 +08:00
Rename ActiveTemplateInstantiation to CodeSynthesisContext in preparation for using it for other kinds of context (where we currently produce context notes in a highly ad-hoc manner). llvm-svn: 295919
2017-02-23 09:43:54 +08:00
llvm_unreachable("Invalid SynthesisKind!");
Improve diagnostics when a default template argument does not match with its corresponding template parameter. This can happen when we performed some substitution into the default template argument and what we had doesn't match any more, e.g., template<int> struct A; template<typename T, template<T> class X = A> class B; B<long> b; Previously, we'd emit a pretty but disembodied diagnostic showing how the default argument didn't match the template parameter. The diagnostic was good, but nothing tied it to the *use* of the default argument in "B<long>". This commit fixes that. Also, tweak the counting of active template instantiations to avoid counting non-instantiation records, such as those we create for (surprise!) checking default arguments, instantiating default arguments, and performing substitutions as part of template argument deduction. llvm-svn: 86884
2009-11-12 05:54:23 +08:00
}
Sema: We can use delegating ctors now. NFC. llvm-svn: 231488
2015-03-07 00:36:50 +08:00
Sema::InstantiatingTemplate::InstantiatingTemplate(
Rename ActiveTemplateInstantiation to CodeSynthesisContext in preparation for using it for other kinds of context (where we currently produce context notes in a highly ad-hoc manner). llvm-svn: 295919
2017-02-23 09:43:54 +08:00
Sema &SemaRef, CodeSynthesisContext::SynthesisKind Kind,
Refactor InstantiatingTemplate constructors This patch factors the bodies of 9 constructors out into a single initialization method. Reviewed By: rsmith Differential Revision: http://llvm-reviews.chandlerc.com/D3059 llvm-svn: 203846
2014-03-14 04:34:22 +08:00
SourceLocation PointOfInstantiation, SourceRange InstantiationRange,
Decl *Entity, NamedDecl *Template, ArrayRef<TemplateArgument> TemplateArgs,
Sema: We can use delegating ctors now. NFC. llvm-svn: 231488
2015-03-07 00:36:50 +08:00
sema::TemplateDeductionInfo *DeductionInfo)
Add context note to diagnostics that occur while declaring an implicit special member function. llvm-svn: 296020
2017-02-24 05:43:43 +08:00
: SemaRef(SemaRef) {
[Sema] Avoid instantiating templates only when UncompilableErrorOccurred and FatalErrorOccurred are both set. This fixes a crash that occurs when a warning promoted to a fatal error leaves the AST in an incomplete state, and then later CFG analysis is run on the incomplete AST. rdar://problem/28558923 Differential Revision: https://reviews.llvm.org/D26166 llvm-svn: 285923
2016-11-03 23:04:58 +08:00
// Don't allow further instantiation if a fatal error and an uncompilable
Fix spelling mistake. llvm-svn: 285938
2016-11-04 01:11:28 +08:00
// error have occurred. Any diagnostics we might have raised will not be
[Sema] Avoid instantiating templates only when UncompilableErrorOccurred and FatalErrorOccurred are both set. This fixes a crash that occurs when a warning promoted to a fatal error leaves the AST in an incomplete state, and then later CFG analysis is run on the incomplete AST. rdar://problem/28558923 Differential Revision: https://reviews.llvm.org/D26166 llvm-svn: 285923
2016-11-03 23:04:58 +08:00
// visible, and we do not need to construct a correct AST.
if (SemaRef.Diags.hasFatalErrorOccurred() &&
Recommit "[CUDA][HIP] Defer overloading resolution diagnostics for host device functions" This recommits 7f1f89ec8d9944559042bb6d3b1132eabe3409de and 40df06cdafc010002fc9cfe1dda73d689b7d27a6 with bug fixes for memory sanitizer failure and Tensile build failure.
2020-09-24 06:00:23 +08:00
SemaRef.hasUncompilableErrorOccurred()) {
Sema: Disable template instantiation once a fatal error is raised Fatal errors disable all further diagnostics. Continuing to permit template instantiation does nothing but make it take longer for clang to finish with the TU. Instead, halt all further instantiation. Fixed in PR22396. llvm-svn: 227556
2015-01-30 13:01:23 +08:00
Invalid = true;
return;
}
Refactor InstantiatingTemplate constructors This patch factors the bodies of 9 constructors out into a single initialization method. Reviewed By: rsmith Differential Revision: http://llvm-reviews.chandlerc.com/D3059 llvm-svn: 203846
2014-03-14 04:34:22 +08:00
Invalid = CheckInstantiationDepth(PointOfInstantiation, InstantiationRange);
Extend the notion of active template instantiations to include the context of a template-id for which we need to instantiate default template arguments. In the TextDiagnosticPrinter, don't suppress the caret diagnostic if we are producing a non-note diagnostic that follows a note diagnostic with the same location, because notes are (conceptually) a part of the warning or error that comes before them. llvm-svn: 66572
2009-03-11 04:44:00 +08:00
if (!Invalid) {
Rename ActiveTemplateInstantiation to CodeSynthesisContext in preparation for using it for other kinds of context (where we currently produce context notes in a highly ad-hoc manner). llvm-svn: 295919
2017-02-23 09:43:54 +08:00
CodeSynthesisContext Inst;
Refactor InstantiatingTemplate constructors This patch factors the bodies of 9 constructors out into a single initialization method. Reviewed By: rsmith Differential Revision: http://llvm-reviews.chandlerc.com/D3059 llvm-svn: 203846
2014-03-14 04:34:22 +08:00
Inst.Kind = Kind;
Extend the notion of active template instantiations to include the context of a template-id for which we need to instantiate default template arguments. In the TextDiagnosticPrinter, don't suppress the caret diagnostic if we are producing a non-note diagnostic that follows a note diagnostic with the same location, because notes are (conceptually) a part of the warning or error that comes before them. llvm-svn: 66572
2009-03-11 04:44:00 +08:00
Inst.PointOfInstantiation = PointOfInstantiation;
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
Inst.Entity = Entity;
Refactor InstantiatingTemplate constructors This patch factors the bodies of 9 constructors out into a single initialization method. Reviewed By: rsmith Differential Revision: http://llvm-reviews.chandlerc.com/D3059 llvm-svn: 203846
2014-03-14 04:34:22 +08:00
Inst.Template = Template;
Inst.TemplateArgs = TemplateArgs.data();
Inst.NumTemplateArgs = TemplateArgs.size();
Inst.DeductionInfo = DeductionInfo;
Extend the notion of active template instantiations to include the context of a template-id for which we need to instantiate default template arguments. In the TextDiagnosticPrinter, don't suppress the caret diagnostic if we are producing a non-note diagnostic that follows a note diagnostic with the same location, because notes are (conceptually) a part of the warning or error that comes before them. llvm-svn: 66572
2009-03-11 04:44:00 +08:00
Inst.InstantiationRange = InstantiationRange;
Add context note to diagnostics that occur while declaring an implicit special member function. llvm-svn: 296020
2017-02-24 05:43:43 +08:00
SemaRef.pushCodeSynthesisContext(Inst);
[Concepts] Requires Expressions Implement support for C++2a requires-expressions. Re-commit after compilation failure on some platforms due to alignment issues with PointerIntPair. Differential Revision: https://reviews.llvm.org/D50360
2020-01-18 15:11:43 +08:00
AlreadyInstantiating = !Inst.Entity ? false :
PR12298 et al: don't recursively instantiate a template specialization from within the instantiation of that same specialization. This could previously happen for eagerly-instantiated function templates, variable templates, exception specifications, default arguments, and a handful of other cases. We still have an issue here for default template arguments that recursively make use of themselves and likewise for substitution into the type of a non-type template parameter, but in those cases we're producing a different entity each time, so they should instead be caught by the instantiation depth limit. However, currently we will typically run out of stack before we reach it. :( llvm-svn: 280190
2016-08-31 10:15:21 +08:00
!SemaRef.InstantiatingSpecializations
Ensure that we don't leave behind "InstantiatingSpecialization" entries after destroying an InstantiatingTemplate object. This previously caused us to (silently!) bail out of class template instantiation, thinking we'd produced an error, in some corner cases.
2020-12-11 08:49:27 +08:00
.insert({Inst.Entity->getCanonicalDecl(), Inst.Kind})
PR12298 et al: don't recursively instantiate a template specialization from within the instantiation of that same specialization. This could previously happen for eagerly-instantiated function templates, variable templates, exception specifications, default arguments, and a handful of other cases. We still have an issue here for default template arguments that recursively make use of themselves and likewise for substitution into the type of a non-type template parameter, but in those cases we're producing a different entity each time, so they should instead be caught by the instantiation depth limit. However, currently we will typically run out of stack before we reach it. :( llvm-svn: 280190
2016-08-31 10:15:21 +08:00
.second;
[Templight] Template Instantiation Observer This patch adds a base-class called TemplateInstantiationObserver which gets notified whenever a template instantiation is entered or exited during semantic analysis. This is a base class used to implement the template profiling and debugging tool called Templight (https://github.com/mikael-s-persson/templight). The patch also makes a few more changes: * ActiveTemplateInstantiation class is moved out of the Sema class (so it can be used with inclusion of Sema.h). * CreateFrontendAction function in front-end utilities is given external linkage (not longer a hidden static function). * TemplateInstObserverChain data member added to Sema class to hold the list of template-inst observers. * Notifications to the template-inst observer are added at the key places where templates are instantiated. Patch by: Abel Sinkovics! Differential Revision: https://reviews.llvm.org/D5767 llvm-svn: 324808
2018-02-10 22:04:45 +08:00
atTemplateBegin(SemaRef.TemplateInstCallbacks, SemaRef, Inst);
Extend the notion of active template instantiations to include the context of a template-id for which we need to instantiate default template arguments. In the TextDiagnosticPrinter, don't suppress the caret diagnostic if we are producing a non-note diagnostic that follows a note diagnostic with the same location, because notes are (conceptually) a part of the warning or error that comes before them. llvm-svn: 66572
2009-03-11 04:44:00 +08:00
}
}
Sema: We can use delegating ctors now. NFC. llvm-svn: 231488
2015-03-07 00:36:50 +08:00
Sema::InstantiatingTemplate::InstantiatingTemplate(
Sema &SemaRef, SourceLocation PointOfInstantiation, Decl *Entity,
SourceRange InstantiationRange)
: InstantiatingTemplate(SemaRef,
Rename ActiveTemplateInstantiation to CodeSynthesisContext in preparation for using it for other kinds of context (where we currently produce context notes in a highly ad-hoc manner). llvm-svn: 295919
2017-02-23 09:43:54 +08:00
CodeSynthesisContext::TemplateInstantiation,
Sema: We can use delegating ctors now. NFC. llvm-svn: 231488
2015-03-07 00:36:50 +08:00
PointOfInstantiation, InstantiationRange, Entity) {}
Refactor InstantiatingTemplate constructors This patch factors the bodies of 9 constructors out into a single initialization method. Reviewed By: rsmith Differential Revision: http://llvm-reviews.chandlerc.com/D3059 llvm-svn: 203846
2014-03-14 04:34:22 +08:00
Sema: We can use delegating ctors now. NFC. llvm-svn: 231488
2015-03-07 00:36:50 +08:00
Sema::InstantiatingTemplate::InstantiatingTemplate(
Sema &SemaRef, SourceLocation PointOfInstantiation, FunctionDecl *Entity,
ExceptionSpecification, SourceRange InstantiationRange)
: InstantiatingTemplate(
Rename ActiveTemplateInstantiation to CodeSynthesisContext in preparation for using it for other kinds of context (where we currently produce context notes in a highly ad-hoc manner). llvm-svn: 295919
2017-02-23 09:43:54 +08:00
SemaRef, CodeSynthesisContext::ExceptionSpecInstantiation,
Sema: We can use delegating ctors now. NFC. llvm-svn: 231488
2015-03-07 00:36:50 +08:00
PointOfInstantiation, InstantiationRange, Entity) {}
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
Sema: We can use delegating ctors now. NFC. llvm-svn: 231488
2015-03-07 00:36:50 +08:00
Sema::InstantiatingTemplate::InstantiatingTemplate(
PR12298 et al: don't recursively instantiate a template specialization from within the instantiation of that same specialization. This could previously happen for eagerly-instantiated function templates, variable templates, exception specifications, default arguments, and a handful of other cases. We still have an issue here for default template arguments that recursively make use of themselves and likewise for substitution into the type of a non-type template parameter, but in those cases we're producing a different entity each time, so they should instead be caught by the instantiation depth limit. However, currently we will typically run out of stack before we reach it. :( llvm-svn: 280190
2016-08-31 10:15:21 +08:00
Sema &SemaRef, SourceLocation PointOfInstantiation, TemplateParameter Param,
TemplateDecl *Template, ArrayRef<TemplateArgument> TemplateArgs,
SourceRange InstantiationRange)
Sema: We can use delegating ctors now. NFC. llvm-svn: 231488
2015-03-07 00:36:50 +08:00
: InstantiatingTemplate(
SemaRef,
Rename ActiveTemplateInstantiation to CodeSynthesisContext in preparation for using it for other kinds of context (where we currently produce context notes in a highly ad-hoc manner). llvm-svn: 295919
2017-02-23 09:43:54 +08:00
CodeSynthesisContext::DefaultTemplateArgumentInstantiation,
PR12298 et al: don't recursively instantiate a template specialization from within the instantiation of that same specialization. This could previously happen for eagerly-instantiated function templates, variable templates, exception specifications, default arguments, and a handful of other cases. We still have an issue here for default template arguments that recursively make use of themselves and likewise for substitution into the type of a non-type template parameter, but in those cases we're producing a different entity each time, so they should instead be caught by the instantiation depth limit. However, currently we will typically run out of stack before we reach it. :( llvm-svn: 280190
2016-08-31 10:15:21 +08:00
PointOfInstantiation, InstantiationRange, getAsNamedDecl(Param),
Template, TemplateArgs) {}
Limit the template instantiation depth to some user-configurable value (default: 99). Beyond this limit, produce an error and consider the current template instantiation a failure. The stack we're building to track the instantiations will, eventually, be used to produce instantiation backtraces from diagnostics within template instantiation. However, we're not quite there yet. This adds a new Clang driver option -ftemplate-depth=NNN, which should eventually be generated from the GCC command-line operation -ftemplate-depth-NNN (note the '-' rather than the '='!). I did not make the driver changes to do this mapping. llvm-svn: 66513
2009-03-10 08:06:19 +08:00
Sema: We can use delegating ctors now. NFC. llvm-svn: 231488
2015-03-07 00:36:50 +08:00
Sema::InstantiatingTemplate::InstantiatingTemplate(
Sema &SemaRef, SourceLocation PointOfInstantiation,
FunctionTemplateDecl *FunctionTemplate,
ArrayRef<TemplateArgument> TemplateArgs,
Rename ActiveTemplateInstantiation to CodeSynthesisContext in preparation for using it for other kinds of context (where we currently produce context notes in a highly ad-hoc manner). llvm-svn: 295919
2017-02-23 09:43:54 +08:00
CodeSynthesisContext::SynthesisKind Kind,
Sema: We can use delegating ctors now. NFC. llvm-svn: 231488
2015-03-07 00:36:50 +08:00
sema::TemplateDeductionInfo &DeductionInfo, SourceRange InstantiationRange)
: InstantiatingTemplate(SemaRef, Kind, PointOfInstantiation,
InstantiationRange, FunctionTemplate, nullptr,
PR12298 et al: don't recursively instantiate a template specialization from within the instantiation of that same specialization. This could previously happen for eagerly-instantiated function templates, variable templates, exception specifications, default arguments, and a handful of other cases. We still have an issue here for default template arguments that recursively make use of themselves and likewise for substitution into the type of a non-type template parameter, but in those cases we're producing a different entity each time, so they should instead be caught by the instantiation depth limit. However, currently we will typically run out of stack before we reach it. :( llvm-svn: 280190
2016-08-31 10:15:21 +08:00
TemplateArgs, &DeductionInfo) {
assert(
Rename ActiveTemplateInstantiation to CodeSynthesisContext in preparation for using it for other kinds of context (where we currently produce context notes in a highly ad-hoc manner). llvm-svn: 295919
2017-02-23 09:43:54 +08:00
Kind == CodeSynthesisContext::ExplicitTemplateArgumentSubstitution ||
Kind == CodeSynthesisContext::DeducedTemplateArgumentSubstitution);
PR12298 et al: don't recursively instantiate a template specialization from within the instantiation of that same specialization. This could previously happen for eagerly-instantiated function templates, variable templates, exception specifications, default arguments, and a handful of other cases. We still have an issue here for default template arguments that recursively make use of themselves and likewise for substitution into the type of a non-type template parameter, but in those cases we're producing a different entity each time, so they should instead be caught by the instantiation depth limit. However, currently we will typically run out of stack before we reach it. :( llvm-svn: 280190
2016-08-31 10:15:21 +08:00
}
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
DR1495: A partial specialization is ill-formed if it is not (strictly) more specialized than the primary template. (Put another way, if we imagine there were a partial specialization matching the primary template, we should never select it if some other partial specialization also matches.) llvm-svn: 290593
2016-12-27 15:56:27 +08:00
Sema::InstantiatingTemplate::InstantiatingTemplate(
Sema &SemaRef, SourceLocation PointOfInstantiation,
TemplateDecl *Template,
ArrayRef<TemplateArgument> TemplateArgs,
sema::TemplateDeductionInfo &DeductionInfo, SourceRange InstantiationRange)
: InstantiatingTemplate(
SemaRef,
Rename ActiveTemplateInstantiation to CodeSynthesisContext in preparation for using it for other kinds of context (where we currently produce context notes in a highly ad-hoc manner). llvm-svn: 295919
2017-02-23 09:43:54 +08:00
CodeSynthesisContext::DeducedTemplateArgumentSubstitution,
DR1495: A partial specialization is ill-formed if it is not (strictly) more specialized than the primary template. (Put another way, if we imagine there were a partial specialization matching the primary template, we should never select it if some other partial specialization also matches.) llvm-svn: 290593
2016-12-27 15:56:27 +08:00
PointOfInstantiation, InstantiationRange, Template, nullptr,
TemplateArgs, &DeductionInfo) {}
Sema: We can use delegating ctors now. NFC. llvm-svn: 231488
2015-03-07 00:36:50 +08:00
Sema::InstantiatingTemplate::InstantiatingTemplate(
Sema &SemaRef, SourceLocation PointOfInstantiation,
ClassTemplatePartialSpecializationDecl *PartialSpec,
ArrayRef<TemplateArgument> TemplateArgs,
sema::TemplateDeductionInfo &DeductionInfo, SourceRange InstantiationRange)
: InstantiatingTemplate(
SemaRef,
Rename ActiveTemplateInstantiation to CodeSynthesisContext in preparation for using it for other kinds of context (where we currently produce context notes in a highly ad-hoc manner). llvm-svn: 295919
2017-02-23 09:43:54 +08:00
CodeSynthesisContext::DeducedTemplateArgumentSubstitution,
Sema: We can use delegating ctors now. NFC. llvm-svn: 231488
2015-03-07 00:36:50 +08:00
PointOfInstantiation, InstantiationRange, PartialSpec, nullptr,
TemplateArgs, &DeductionInfo) {}
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::InstantiatingTemplate::InstantiatingTemplate(
Sema &SemaRef, SourceLocation PointOfInstantiation,
VarTemplatePartialSpecializationDecl *PartialSpec,
ArrayRef<TemplateArgument> TemplateArgs,
sema::TemplateDeductionInfo &DeductionInfo, SourceRange InstantiationRange)
Sema: We can use delegating ctors now. NFC. llvm-svn: 231488
2015-03-07 00:36:50 +08:00
: InstantiatingTemplate(
SemaRef,
Rename ActiveTemplateInstantiation to CodeSynthesisContext in preparation for using it for other kinds of context (where we currently produce context notes in a highly ad-hoc manner). llvm-svn: 295919
2017-02-23 09:43:54 +08:00
CodeSynthesisContext::DeducedTemplateArgumentSubstitution,
Sema: We can use delegating ctors now. NFC. llvm-svn: 231488
2015-03-07 00:36:50 +08:00
PointOfInstantiation, InstantiationRange, PartialSpec, nullptr,
TemplateArgs, &DeductionInfo) {}
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
Sema: We can use delegating ctors now. NFC. llvm-svn: 231488
2015-03-07 00:36:50 +08:00
Sema::InstantiatingTemplate::InstantiatingTemplate(
Sema &SemaRef, SourceLocation PointOfInstantiation, ParmVarDecl *Param,
ArrayRef<TemplateArgument> TemplateArgs, SourceRange InstantiationRange)
: InstantiatingTemplate(
SemaRef,
Rename ActiveTemplateInstantiation to CodeSynthesisContext in preparation for using it for other kinds of context (where we currently produce context notes in a highly ad-hoc manner). llvm-svn: 295919
2017-02-23 09:43:54 +08:00
CodeSynthesisContext::DefaultFunctionArgumentInstantiation,
Sema: We can use delegating ctors now. NFC. llvm-svn: 231488
2015-03-07 00:36:50 +08:00
PointOfInstantiation, InstantiationRange, Param, nullptr,
TemplateArgs) {}
Refactor InstantiatingTemplate constructors This patch factors the bodies of 9 constructors out into a single initialization method. Reviewed By: rsmith Differential Revision: http://llvm-reviews.chandlerc.com/D3059 llvm-svn: 203846
2014-03-14 04:34:22 +08:00
Sema: We can use delegating ctors now. NFC. llvm-svn: 231488
2015-03-07 00:36:50 +08:00
Sema::InstantiatingTemplate::InstantiatingTemplate(
Sema &SemaRef, SourceLocation PointOfInstantiation, NamedDecl *Template,
NonTypeTemplateParmDecl *Param, ArrayRef<TemplateArgument> TemplateArgs,
SourceRange InstantiationRange)
: InstantiatingTemplate(
SemaRef,
Rename ActiveTemplateInstantiation to CodeSynthesisContext in preparation for using it for other kinds of context (where we currently produce context notes in a highly ad-hoc manner). llvm-svn: 295919
2017-02-23 09:43:54 +08:00
CodeSynthesisContext::PriorTemplateArgumentSubstitution,
Sema: We can use delegating ctors now. NFC. llvm-svn: 231488
2015-03-07 00:36:50 +08:00
PointOfInstantiation, InstantiationRange, Param, Template,
TemplateArgs) {}
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
Sema: We can use delegating ctors now. NFC. llvm-svn: 231488
2015-03-07 00:36:50 +08:00
Sema::InstantiatingTemplate::InstantiatingTemplate(
Sema &SemaRef, SourceLocation PointOfInstantiation, NamedDecl *Template,
TemplateTemplateParmDecl *Param, ArrayRef<TemplateArgument> TemplateArgs,
SourceRange InstantiationRange)
: InstantiatingTemplate(
SemaRef,
Rename ActiveTemplateInstantiation to CodeSynthesisContext in preparation for using it for other kinds of context (where we currently produce context notes in a highly ad-hoc manner). llvm-svn: 295919
2017-02-23 09:43:54 +08:00
CodeSynthesisContext::PriorTemplateArgumentSubstitution,
Sema: We can use delegating ctors now. NFC. llvm-svn: 231488
2015-03-07 00:36:50 +08:00
PointOfInstantiation, InstantiationRange, Param, Template,
TemplateArgs) {}
Improve diagnostics when a default template argument does not match with its corresponding template parameter. This can happen when we performed some substitution into the default template argument and what we had doesn't match any more, e.g., template<int> struct A; template<typename T, template<T> class X = A> class B; B<long> b; Previously, we'd emit a pretty but disembodied diagnostic showing how the default argument didn't match the template parameter. The diagnostic was good, but nothing tied it to the *use* of the default argument in "B<long>". This commit fixes that. Also, tweak the counting of active template instantiations to avoid counting non-instantiation records, such as those we create for (surprise!) checking default arguments, instantiating default arguments, and performing substitutions as part of template argument deduction. llvm-svn: 86884
2009-11-12 05:54:23 +08:00
Sema: We can use delegating ctors now. NFC. llvm-svn: 231488
2015-03-07 00:36:50 +08:00
Sema::InstantiatingTemplate::InstantiatingTemplate(
Sema &SemaRef, SourceLocation PointOfInstantiation, TemplateDecl *Template,
NamedDecl *Param, ArrayRef<TemplateArgument> TemplateArgs,
SourceRange InstantiationRange)
: InstantiatingTemplate(
Rename ActiveTemplateInstantiation to CodeSynthesisContext in preparation for using it for other kinds of context (where we currently produce context notes in a highly ad-hoc manner). llvm-svn: 295919
2017-02-23 09:43:54 +08:00
SemaRef, CodeSynthesisContext::DefaultTemplateArgumentChecking,
Sema: We can use delegating ctors now. NFC. llvm-svn: 231488
2015-03-07 00:36:50 +08:00
PointOfInstantiation, InstantiationRange, Param, Template,
TemplateArgs) {}
Use a separate diagnostic for default function argument expressions. llvm-svn: 81062
2009-09-05 13:14:19 +08:00
[Concepts] Requires Expressions Implement support for C++2a requires-expressions. Re-commit after compilation failure on some platforms due to alignment issues with PointerIntPair. Differential Revision: https://reviews.llvm.org/D50360
2020-01-18 15:11:43 +08:00
Sema::InstantiatingTemplate::InstantiatingTemplate(
Sema &SemaRef, SourceLocation PointOfInstantiation,
concepts::Requirement *Req, sema::TemplateDeductionInfo &DeductionInfo,
SourceRange InstantiationRange)
: InstantiatingTemplate(
SemaRef, CodeSynthesisContext::RequirementInstantiation,
PointOfInstantiation, InstantiationRange, /*Entity=*/nullptr,
/*Template=*/nullptr, /*TemplateArgs=*/None, &DeductionInfo) {}
Sema::InstantiatingTemplate::InstantiatingTemplate(
Sema &SemaRef, SourceLocation PointOfInstantiation,
concepts::NestedRequirement *Req, ConstraintsCheck,
SourceRange InstantiationRange)
: InstantiatingTemplate(
SemaRef, CodeSynthesisContext::NestedRequirementConstraintsCheck,
PointOfInstantiation, InstantiationRange, /*Entity=*/nullptr,
/*Template=*/nullptr, /*TemplateArgs=*/None) {}
[Concepts] Concept Specialization Expressions Part of C++20 Concepts implementation effort. Added Concept Specialization Expressions that are created when a concept is refe$ D41217 on Phabricator. (recommit after fixing failing Parser test on windows) llvm-svn: 374903
2019-10-15 23:24:26 +08:00
Sema::InstantiatingTemplate::InstantiatingTemplate(
Sema &SemaRef, SourceLocation PointOfInstantiation,
[Concepts] Constraint Enforcement & Diagnostics Part of the C++20 concepts implementation effort. - Associated constraints (requires clauses, currently) are now enforced when instantiating/specializing templates and when considering partial specializations and function overloads. - Elaborated diagnostics give helpful insight as to why the constraints were not satisfied. Phabricator: D41569 Re-commit, after fixing some memory bugs.
2019-12-06 07:30:21 +08:00
ConstraintsCheck, NamedDecl *Template,
[Concepts] Concept Specialization Expressions Part of C++20 Concepts implementation effort. Added Concept Specialization Expressions that are created when a concept is refe$ D41217 on Phabricator. (recommit after fixing failing Parser test on windows) llvm-svn: 374903
2019-10-15 23:24:26 +08:00
ArrayRef<TemplateArgument> TemplateArgs, SourceRange InstantiationRange)
: InstantiatingTemplate(
SemaRef, CodeSynthesisContext::ConstraintsCheck,
PointOfInstantiation, InstantiationRange, Template, nullptr,
TemplateArgs) {}
Sema::InstantiatingTemplate::InstantiatingTemplate(
Sema &SemaRef, SourceLocation PointOfInstantiation,
[Concepts] Constraint Enforcement & Diagnostics Part of the C++20 concepts implementation effort. - Associated constraints (requires clauses, currently) are now enforced when instantiating/specializing templates and when considering partial specializations and function overloads. - Elaborated diagnostics give helpful insight as to why the constraints were not satisfied. Phabricator: D41569 Re-commit, after fixing some memory bugs.
2019-12-06 07:30:21 +08:00
ConstraintSubstitution, NamedDecl *Template,
[Concepts] Concept Specialization Expressions Part of C++20 Concepts implementation effort. Added Concept Specialization Expressions that are created when a concept is refe$ D41217 on Phabricator. (recommit after fixing failing Parser test on windows) llvm-svn: 374903
2019-10-15 23:24:26 +08:00
sema::TemplateDeductionInfo &DeductionInfo, SourceRange InstantiationRange)
: InstantiatingTemplate(
SemaRef, CodeSynthesisContext::ConstraintSubstitution,
PointOfInstantiation, InstantiationRange, Template, nullptr,
{}, &DeductionInfo) {}
[Concepts] Constrained partial specializations and function overloads. Added support for constraint satisfaction checking and partial ordering of constraints in constrained partial specialization and function template overloads. Re-commit after fixing another crash (added regression test). Differential Revision: https://reviews.llvm.org/D41910
2019-12-23 14:37:35 +08:00
Sema::InstantiatingTemplate::InstantiatingTemplate(
Sema &SemaRef, SourceLocation PointOfInstantiation,
ConstraintNormalization, NamedDecl *Template,
SourceRange InstantiationRange)
: InstantiatingTemplate(
SemaRef, CodeSynthesisContext::ConstraintNormalization,
PointOfInstantiation, InstantiationRange, Template) {}
Sema::InstantiatingTemplate::InstantiatingTemplate(
Sema &SemaRef, SourceLocation PointOfInstantiation,
ParameterMappingSubstitution, NamedDecl *Template,
SourceRange InstantiationRange)
: InstantiatingTemplate(
SemaRef, CodeSynthesisContext::ParameterMappingSubstitution,
PointOfInstantiation, InstantiationRange, Template) {}
Add context note to diagnostics that occur while declaring an implicit special member function. llvm-svn: 296020
2017-02-24 05:43:43 +08:00
void Sema::pushCodeSynthesisContext(CodeSynthesisContext Ctx) {
Ctx.SavedInNonInstantiationSFINAEContext = InNonInstantiationSFINAEContext;
InNonInstantiationSFINAEContext = false;
CodeSynthesisContexts.push_back(Ctx);
When we perform dependent name lookup during template instantiation, it's not sufficient to only consider names visible at the point of instantiation, because that may not include names that were visible when the template was defined. More generally, if the instantiation backtrace goes through a module M, then every declaration visible within M should be available to the instantiation. Any of those declarations might be part of the interface that M intended to export to a template that it instantiates. The fix here has two parts: 1) If we find a non-visible declaration during name lookup during template instantiation, check whether the declaration was visible from the defining module of all entities on the active template instantiation stack. The defining module is not the owning module in all cases: we look at the module in which a template was defined, not the module in which it was first instantiated. 2) Perform pending instantiations at the end of a module, not at the end of the translation unit. This is general goodness, since it significantly cuts down the amount of redundant work that is performed in every TU importing a module, and also implicitly adds the module containing the point of instantiation to the set of modules checked for declarations in a lookup within a template instantiation. There's a known issue here with template instantiations performed while building a module, if additional imports are added later on. I'll fix that in a subsequent commit. llvm-svn: 187167
2013-07-26 07:08:39 +08:00
Add context note to diagnostics that occur while declaring an implicit special member function. llvm-svn: 296020
2017-02-24 05:43:43 +08:00
if (!Ctx.isInstantiationRecord())
++NonInstantiationEntries;
Improve behavior in the case of stack exhaustion. Summary: Clang performs various recursive operations (such as template instantiation), and may use non-trivial amounts of stack space in each recursive step (for instance, due to recursive AST walks). While we try to keep the stack space used by such steps to a minimum and we have explicit limits on the number of such steps we perform, it's impractical to guarantee that we won't blow out the stack on deeply recursive template instantiations on complex ASTs, even with only a moderately high instantiation depth limit. The user experience in these cases is generally terrible: we crash with no hint of what went wrong. Under this patch, we attempt to do better: * Detect when the stack is nearly exhausted, and produce a warning with a nice template instantiation backtrace, telling the user that we might run slowly or crash. * For cases where we're forced to trigger recursive template instantiation in arbitrarily-deeply-nested contexts, check whether we're nearly out of stack space and allocate a new stack (by spawning a new thread) after producing the warning. Reviewers: rnk, aaron.ballman Subscribers: mgorny, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66361 llvm-svn: 369940
2019-08-27 02:18:07 +08:00
// Check to see if we're low on stack space. We can't do anything about this
// from here, but we can at least warn the user.
if (isStackNearlyExhausted())
warnStackExhausted(Ctx.PointOfInstantiation);
Add context note to diagnostics that occur while declaring an implicit special member function. llvm-svn: 296020
2017-02-24 05:43:43 +08:00
}
Fix tracking of whether the previous template instantiation stack matches the current one. Rather than attempting to compare whether the previous and current top of context stack are "equal" (which fails for a number of reasons, such as the context stack entries containing pointers to objects on the stack, or reaching the same "top of stack" entry through two different paths), track the depth of context stack at which we last emitted a note and invalidate it when we pop the context stack to less than that depth. This causes us to emit some missing "in instantiation of" notes and to stop emitting redundant "in instantiation of" stacks matching the previous stack in rare cases. llvm-svn: 295921
2017-02-23 10:09:03 +08:00
Add context note to diagnostics that occur while declaring an implicit special member function. llvm-svn: 296020
2017-02-24 05:43:43 +08:00
void Sema::popCodeSynthesisContext() {
auto &Active = CodeSynthesisContexts.back();
if (!Active.isInstantiationRecord()) {
assert(NonInstantiationEntries > 0);
--NonInstantiationEntries;
}
InNonInstantiationSFINAEContext = Active.SavedInNonInstantiationSFINAEContext;
// Name lookup no longer looks in this template's defining module.
assert(CodeSynthesisContexts.size() >=
CodeSynthesisContextLookupModules.size() &&
"forgot to remove a lookup module for a template instantiation");
if (CodeSynthesisContexts.size() ==
CodeSynthesisContextLookupModules.size()) {
if (Module *M = CodeSynthesisContextLookupModules.back())
LookupModulesCache.erase(M);
CodeSynthesisContextLookupModules.pop_back();
}
// If we've left the code synthesis context for the current context stack,
// stop remembering that we've emitted that stack.
if (CodeSynthesisContexts.size() ==
LastEmittedCodeSynthesisContextDepth)
LastEmittedCodeSynthesisContextDepth = 0;
CodeSynthesisContexts.pop_back();
}
void Sema::InstantiatingTemplate::Clear() {
if (!Invalid) {
if (!AlreadyInstantiating) {
auto &Active = SemaRef.CodeSynthesisContexts.back();
[Concepts] Requires Expressions Implement support for C++2a requires-expressions. Re-commit after compilation failure on some platforms due to alignment issues with PointerIntPair. Differential Revision: https://reviews.llvm.org/D50360
2020-01-18 15:11:43 +08:00
if (Active.Entity)
SemaRef.InstantiatingSpecializations.erase(
Ensure that we don't leave behind "InstantiatingSpecialization" entries after destroying an InstantiatingTemplate object. This previously caused us to (silently!) bail out of class template instantiation, thinking we'd produced an error, in some corner cases.
2020-12-11 08:49:27 +08:00
{Active.Entity->getCanonicalDecl(), Active.Kind});
Add context note to diagnostics that occur while declaring an implicit special member function. llvm-svn: 296020
2017-02-24 05:43:43 +08:00
}
[Templight] Template Instantiation Observer This patch adds a base-class called TemplateInstantiationObserver which gets notified whenever a template instantiation is entered or exited during semantic analysis. This is a base class used to implement the template profiling and debugging tool called Templight (https://github.com/mikael-s-persson/templight). The patch also makes a few more changes: * ActiveTemplateInstantiation class is moved out of the Sema class (so it can be used with inclusion of Sema.h). * CreateFrontendAction function in front-end utilities is given external linkage (not longer a hidden static function). * TemplateInstObserverChain data member added to Sema class to hold the list of template-inst observers. * Notifications to the template-inst observer are added at the key places where templates are instantiated. Patch by: Abel Sinkovics! Differential Revision: https://reviews.llvm.org/D5767 llvm-svn: 324808
2018-02-10 22:04:45 +08:00
atTemplateEnd(SemaRef.TemplateInstCallbacks, SemaRef,
SemaRef.CodeSynthesisContexts.back());
PR12298 et al: don't recursively instantiate a template specialization from within the instantiation of that same specialization. This could previously happen for eagerly-instantiated function templates, variable templates, exception specifications, default arguments, and a handful of other cases. We still have an issue here for default template arguments that recursively make use of themselves and likewise for substitution into the type of a non-type template parameter, but in those cases we're producing a different entity each time, so they should instead be caught by the instantiation depth limit. However, currently we will typically run out of stack before we reach it. :( llvm-svn: 280190
2016-08-31 10:15:21 +08:00
[Templight] Template Instantiation Observer This patch adds a base-class called TemplateInstantiationObserver which gets notified whenever a template instantiation is entered or exited during semantic analysis. This is a base class used to implement the template profiling and debugging tool called Templight (https://github.com/mikael-s-persson/templight). The patch also makes a few more changes: * ActiveTemplateInstantiation class is moved out of the Sema class (so it can be used with inclusion of Sema.h). * CreateFrontendAction function in front-end utilities is given external linkage (not longer a hidden static function). * TemplateInstObserverChain data member added to Sema class to hold the list of template-inst observers. * Notifications to the template-inst observer are added at the key places where templates are instantiated. Patch by: Abel Sinkovics! Differential Revision: https://reviews.llvm.org/D5767 llvm-svn: 324808
2018-02-10 22:04:45 +08:00
SemaRef.popCodeSynthesisContext();
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
Invalid = true;
}
Limit the template instantiation depth to some user-configurable value (default: 99). Beyond this limit, produce an error and consider the current template instantiation a failure. The stack we're building to track the instantiations will, eventually, be used to produce instantiation backtraces from diagnostics within template instantiation. However, we're not quite there yet. This adds a new Clang driver option -ftemplate-depth=NNN, which should eventually be generated from the GCC command-line operation -ftemplate-depth-NNN (note the '-' rather than the '='!). I did not make the driver changes to do this mapping. llvm-svn: 66513
2009-03-10 08:06:19 +08:00
}
Extend the notion of active template instantiations to include the context of a template-id for which we need to instantiate default template arguments. In the TextDiagnosticPrinter, don't suppress the caret diagnostic if we are producing a non-note diagnostic that follows a note diagnostic with the same location, because notes are (conceptually) a part of the warning or error that comes before them. llvm-svn: 66572
2009-03-11 04:44:00 +08:00
bool Sema::InstantiatingTemplate::CheckInstantiationDepth(
SourceLocation PointOfInstantiation,
SourceRange InstantiationRange) {
Improve diagnostics when a default template argument does not match with its corresponding template parameter. This can happen when we performed some substitution into the default template argument and what we had doesn't match any more, e.g., template<int> struct A; template<typename T, template<T> class X = A> class B; B<long> b; Previously, we'd emit a pretty but disembodied diagnostic showing how the default argument didn't match the template parameter. The diagnostic was good, but nothing tied it to the *use* of the default argument in "B<long>". This commit fixes that. Also, tweak the counting of active template instantiations to avoid counting non-instantiation records, such as those we create for (surprise!) checking default arguments, instantiating default arguments, and performing substitutions as part of template argument deduction. llvm-svn: 86884
2009-11-12 05:54:23 +08:00
assert(SemaRef.NonInstantiationEntries <=
Rename ActiveTemplateInstantiation to CodeSynthesisContext in preparation for using it for other kinds of context (where we currently produce context notes in a highly ad-hoc manner). llvm-svn: 295919
2017-02-23 09:43:54 +08:00
SemaRef.CodeSynthesisContexts.size());
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
if ((SemaRef.CodeSynthesisContexts.size() -
Improve diagnostics when a default template argument does not match with its corresponding template parameter. This can happen when we performed some substitution into the default template argument and what we had doesn't match any more, e.g., template<int> struct A; template<typename T, template<T> class X = A> class B; B<long> b; Previously, we'd emit a pretty but disembodied diagnostic showing how the default argument didn't match the template parameter. The diagnostic was good, but nothing tied it to the *use* of the default argument in "B<long>". This commit fixes that. Also, tweak the counting of active template instantiations to avoid counting non-instantiation records, such as those we create for (surprise!) checking default arguments, instantiating default arguments, and performing substitutions as part of template argument deduction. llvm-svn: 86884
2009-11-12 05:54:23 +08:00
SemaRef.NonInstantiationEntries)
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
<= SemaRef.getLangOpts().InstantiationDepth)
Extend the notion of active template instantiations to include the context of a template-id for which we need to instantiate default template arguments. In the TextDiagnosticPrinter, don't suppress the caret diagnostic if we are producing a non-note diagnostic that follows a note diagnostic with the same location, because notes are (conceptually) a part of the warning or error that comes before them. llvm-svn: 66572
2009-03-11 04:44:00 +08:00
return false;
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
SemaRef.Diag(PointOfInstantiation,
Extend the notion of active template instantiations to include the context of a template-id for which we need to instantiate default template arguments. In the TextDiagnosticPrinter, don't suppress the caret diagnostic if we are producing a non-note diagnostic that follows a note diagnostic with the same location, because notes are (conceptually) a part of the warning or error that comes before them. llvm-svn: 66572
2009-03-11 04:44:00 +08:00
diag::err_template_recursion_depth_exceeded)
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
<< SemaRef.getLangOpts().InstantiationDepth
Extend the notion of active template instantiations to include the context of a template-id for which we need to instantiate default template arguments. In the TextDiagnosticPrinter, don't suppress the caret diagnostic if we are producing a non-note diagnostic that follows a note diagnostic with the same location, because notes are (conceptually) a part of the warning or error that comes before them. llvm-svn: 66572
2009-03-11 04:44:00 +08:00
<< InstantiationRange;
SemaRef.Diag(PointOfInstantiation, diag::note_template_recursion_depth)
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
<< SemaRef.getLangOpts().InstantiationDepth;
Extend the notion of active template instantiations to include the context of a template-id for which we need to instantiate default template arguments. In the TextDiagnosticPrinter, don't suppress the caret diagnostic if we are producing a non-note diagnostic that follows a note diagnostic with the same location, because notes are (conceptually) a part of the warning or error that comes before them. llvm-svn: 66572
2009-03-11 04:44:00 +08:00
return true;
}
Remove \brief commands from doxygen comments. This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
2018-05-09 09:00:01 +08:00
/// Prints the current instantiation stack through a series of
Add a notion of "post-diagnostic hooks", which are callbacks attached to a diagnostic that will be invoked after the diagnostic (if it is not suppressed). The hooks are allowed to produce additional diagnostics (typically notes) that provide more information. We should be able to use this to help diagnostic clients link notes back to the diagnostic they clarify. Comments welcome; I'll write up documentation and convert other clients (e.g., overload resolution failures) if there are no screams of protest. As the first client of post-diagnostic hooks, we now produce a template instantiation backtrace when a failure occurs during template instantiation. There's still more work to do to make this output pretty, if that's even possible. llvm-svn: 66557
2009-03-11 02:03:33 +08:00
/// notes.
void Sema::PrintInstantiationStack() {
Introduce a limit on the depth of the template instantiation backtrace we will print with each error that occurs during template instantiation. When the backtrace is longer than that, we will print N/2 of the innermost backtrace entries and N/2 of the outermost backtrace entries, then skip the middle entries with a note such as: note: suppressed 2 template instantiation contexts; use -ftemplate-backtrace-limit=N to change the number of template instantiation entries shown This should eliminate some excessively long backtraces that aren't providing any value. llvm-svn: 101882
2010-04-20 15:18:24 +08:00
// Determine which template instantiations to skip, if any.
Rename ActiveTemplateInstantiation to CodeSynthesisContext in preparation for using it for other kinds of context (where we currently produce context notes in a highly ad-hoc manner). llvm-svn: 295919
2017-02-23 09:43:54 +08:00
unsigned SkipStart = CodeSynthesisContexts.size(), SkipEnd = SkipStart;
Introduce a limit on the depth of the template instantiation backtrace we will print with each error that occurs during template instantiation. When the backtrace is longer than that, we will print N/2 of the innermost backtrace entries and N/2 of the outermost backtrace entries, then skip the middle entries with a note such as: note: suppressed 2 template instantiation contexts; use -ftemplate-backtrace-limit=N to change the number of template instantiation entries shown This should eliminate some excessively long backtraces that aren't providing any value. llvm-svn: 101882
2010-04-20 15:18:24 +08:00
unsigned Limit = Diags.getTemplateBacktraceLimit();
Rename ActiveTemplateInstantiation to CodeSynthesisContext in preparation for using it for other kinds of context (where we currently produce context notes in a highly ad-hoc manner). llvm-svn: 295919
2017-02-23 09:43:54 +08:00
if (Limit && Limit < CodeSynthesisContexts.size()) {
Introduce a limit on the depth of the template instantiation backtrace we will print with each error that occurs during template instantiation. When the backtrace is longer than that, we will print N/2 of the innermost backtrace entries and N/2 of the outermost backtrace entries, then skip the middle entries with a note such as: note: suppressed 2 template instantiation contexts; use -ftemplate-backtrace-limit=N to change the number of template instantiation entries shown This should eliminate some excessively long backtraces that aren't providing any value. llvm-svn: 101882
2010-04-20 15:18:24 +08:00
SkipStart = Limit / 2 + Limit % 2;
Rename ActiveTemplateInstantiation to CodeSynthesisContext in preparation for using it for other kinds of context (where we currently produce context notes in a highly ad-hoc manner). llvm-svn: 295919
2017-02-23 09:43:54 +08:00
SkipEnd = CodeSynthesisContexts.size() - Limit / 2;
Introduce a limit on the depth of the template instantiation backtrace we will print with each error that occurs during template instantiation. When the backtrace is longer than that, we will print N/2 of the innermost backtrace entries and N/2 of the outermost backtrace entries, then skip the middle entries with a note such as: note: suppressed 2 template instantiation contexts; use -ftemplate-backtrace-limit=N to change the number of template instantiation entries shown This should eliminate some excessively long backtraces that aren't providing any value. llvm-svn: 101882
2010-04-20 15:18:24 +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
// FIXME: In all of these cases, we need to show the template arguments
Introduce a limit on the depth of the template instantiation backtrace we will print with each error that occurs during template instantiation. When the backtrace is longer than that, we will print N/2 of the innermost backtrace entries and N/2 of the outermost backtrace entries, then skip the middle entries with a note such as: note: suppressed 2 template instantiation contexts; use -ftemplate-backtrace-limit=N to change the number of template instantiation entries shown This should eliminate some excessively long backtraces that aren't providing any value. llvm-svn: 101882
2010-04-20 15:18:24 +08:00
unsigned InstantiationIdx = 0;
Rename ActiveTemplateInstantiation to CodeSynthesisContext in preparation for using it for other kinds of context (where we currently produce context notes in a highly ad-hoc manner). llvm-svn: 295919
2017-02-23 09:43:54 +08:00
for (SmallVectorImpl<CodeSynthesisContext>::reverse_iterator
Active = CodeSynthesisContexts.rbegin(),
ActiveEnd = CodeSynthesisContexts.rend();
Add a notion of "post-diagnostic hooks", which are callbacks attached to a diagnostic that will be invoked after the diagnostic (if it is not suppressed). The hooks are allowed to produce additional diagnostics (typically notes) that provide more information. We should be able to use this to help diagnostic clients link notes back to the diagnostic they clarify. Comments welcome; I'll write up documentation and convert other clients (e.g., overload resolution failures) if there are no screams of protest. As the first client of post-diagnostic hooks, we now produce a template instantiation backtrace when a failure occurs during template instantiation. There's still more work to do to make this output pretty, if that's even possible. llvm-svn: 66557
2009-03-11 02:03:33 +08:00
Active != ActiveEnd;
Introduce a limit on the depth of the template instantiation backtrace we will print with each error that occurs during template instantiation. When the backtrace is longer than that, we will print N/2 of the innermost backtrace entries and N/2 of the outermost backtrace entries, then skip the middle entries with a note such as: note: suppressed 2 template instantiation contexts; use -ftemplate-backtrace-limit=N to change the number of template instantiation entries shown This should eliminate some excessively long backtraces that aren't providing any value. llvm-svn: 101882
2010-04-20 15:18:24 +08:00
++Active, ++InstantiationIdx) {
// Skip this instantiation?
if (InstantiationIdx >= SkipStart && InstantiationIdx < SkipEnd) {
if (InstantiationIdx == SkipStart) {
// Note that we're skipping instantiations.
Refactoring of Diagnostic class. -Move the stuff of Diagnostic related to creating/querying diagnostic IDs into a new DiagnosticIDs class. -DiagnosticIDs can be shared among multiple Diagnostics for multiple translation units. -The rest of the state in Diagnostic object is considered related and tied to one translation unit. -Have Diagnostic point to the SourceManager that is related with. Diagnostic can now accept just a SourceLocation instead of a FullSourceLoc. -Reflect the changes to various interfaces. llvm-svn: 119730
2010-11-19 04:06:41 +08:00
Diags.Report(Active->PointOfInstantiation,
Introduce a limit on the depth of the template instantiation backtrace we will print with each error that occurs during template instantiation. When the backtrace is longer than that, we will print N/2 of the innermost backtrace entries and N/2 of the outermost backtrace entries, then skip the middle entries with a note such as: note: suppressed 2 template instantiation contexts; use -ftemplate-backtrace-limit=N to change the number of template instantiation entries shown This should eliminate some excessively long backtraces that aren't providing any value. llvm-svn: 101882
2010-04-20 15:18:24 +08:00
diag::note_instantiation_contexts_suppressed)
Rename ActiveTemplateInstantiation to CodeSynthesisContext in preparation for using it for other kinds of context (where we currently produce context notes in a highly ad-hoc manner). llvm-svn: 295919
2017-02-23 09:43:54 +08:00
<< unsigned(CodeSynthesisContexts.size() - Limit);
Introduce a limit on the depth of the template instantiation backtrace we will print with each error that occurs during template instantiation. When the backtrace is longer than that, we will print N/2 of the innermost backtrace entries and N/2 of the outermost backtrace entries, then skip the middle entries with a note such as: note: suppressed 2 template instantiation contexts; use -ftemplate-backtrace-limit=N to change the number of template instantiation entries shown This should eliminate some excessively long backtraces that aren't providing any value. llvm-svn: 101882
2010-04-20 15:18:24 +08:00
}
continue;
}
Extend the notion of active template instantiations to include the context of a template-id for which we need to instantiate default template arguments. In the TextDiagnosticPrinter, don't suppress the caret diagnostic if we are producing a non-note diagnostic that follows a note diagnostic with the same location, because notes are (conceptually) a part of the warning or error that comes before them. llvm-svn: 66572
2009-03-11 04:44:00 +08:00
switch (Active->Kind) {
Rename ActiveTemplateInstantiation to CodeSynthesisContext in preparation for using it for other kinds of context (where we currently produce context notes in a highly ad-hoc manner). llvm-svn: 295919
2017-02-23 09:43:54 +08:00
case CodeSynthesisContext::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
Decl *D = Active->Entity;
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
if (CXXRecordDecl *Record = dyn_cast<CXXRecordDecl>(D)) {
unsigned DiagID = diag::note_template_member_class_here;
if (isa<ClassTemplateSpecializationDecl>(Record))
DiagID = diag::note_template_class_instantiation_here;
Refactoring of Diagnostic class. -Move the stuff of Diagnostic related to creating/querying diagnostic IDs into a new DiagnosticIDs class. -DiagnosticIDs can be shared among multiple Diagnostics for multiple translation units. -The rest of the state in Diagnostic object is considered related and tied to one translation unit. -Have Diagnostic point to the SourceManager that is related with. Diagnostic can now accept just a SourceLocation instead of a FullSourceLoc. -Reflect the changes to various interfaces. llvm-svn: 119730
2010-11-19 04:06:41 +08:00
Diags.Report(Active->PointOfInstantiation, DiagID)
When producing a name of a partial specialization in a diagnostic, use the template arguments as written rather than the canonical template arguments, so we print more user-friendly names for template parameters. llvm-svn: 290483
2016-12-24 12:09:05 +08:00
<< Record << Active->InstantiationRange;
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
} else if (FunctionDecl *Function = dyn_cast<FunctionDecl>(D)) {
Implicit instantiation for function template specializations. For a FunctionDecl that has been instantiated due to template argument deduction, we now store the primary template from which it was instantiated and the deduced template arguments. From this information, we can instantiate the body of the function template. llvm-svn: 74232
2009-06-26 08:10:03 +08:00
unsigned DiagID;
if (Function->getPrimaryTemplate())
DiagID = diag::note_function_template_spec_here;
else
DiagID = diag::note_template_member_function_here;
Refactoring of Diagnostic class. -Move the stuff of Diagnostic related to creating/querying diagnostic IDs into a new DiagnosticIDs class. -DiagnosticIDs can be shared among multiple Diagnostics for multiple translation units. -The rest of the state in Diagnostic object is considered related and tied to one translation unit. -Have Diagnostic point to the SourceManager that is related with. Diagnostic can now accept just a SourceLocation instead of a FullSourceLoc. -Reflect the changes to various interfaces. llvm-svn: 119730
2010-11-19 04:06:41 +08:00
Diags.Report(Active->PointOfInstantiation, DiagID)
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
<< Function
<< Active->InstantiationRange;
Implement support for C++0x alias templates. llvm-svn: 130953
2011-05-06 05:57:07 +08:00
} else if (VarDecl *VD = dyn_cast<VarDecl>(D)) {
Refactoring of Diagnostic class. -Move the stuff of Diagnostic related to creating/querying diagnostic IDs into a new DiagnosticIDs class. -DiagnosticIDs can be shared among multiple Diagnostics for multiple translation units. -The rest of the state in Diagnostic object is considered related and tied to one translation unit. -Have Diagnostic point to the SourceManager that is related with. Diagnostic can now accept just a SourceLocation instead of a FullSourceLoc. -Reflect the changes to various interfaces. llvm-svn: 119730
2010-11-19 04:06:41 +08:00
Diags.Report(Active->PointOfInstantiation,
Bug fix: note diagnosis on expression narrowing should say "variable template" instead of "static data member" when appropriate llvm-svn: 188409
2013-08-15 04:15:02 +08:00
VD->isStaticDataMember()?
diag::note_template_static_data_member_def_here
: diag::note_template_variable_def_here)
Implement support for C++0x alias templates. llvm-svn: 130953
2011-05-06 05:57:07 +08:00
<< VD
<< Active->InstantiationRange;
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 if (EnumDecl *ED = dyn_cast<EnumDecl>(D)) {
Diags.Report(Active->PointOfInstantiation,
diag::note_template_enum_def_here)
<< ED
<< Active->InstantiationRange;
Handle use of default member initializers before end of outermost class Specifically, when we have this situation: struct A { template <typename T> struct B { int m1 = sizeof(A); }; B<int> m2; }; We can't parse m1's initializer eagerly because we need A to be complete. Therefore we wait until the end of A's class scope to parse it. However, we can trigger instantiation of B before the end of A, which will attempt to instantiate the field decls eagerly, and it would build a bad field decl instantiation that said it had an initializer but actually lacked one. Fixed by deferring instantiation of default member initializers until they are needed during constructor analysis. This addresses a long standing FIXME in the code. Fixes PR19195. Reviewed By: rsmith Differential Revision: http://reviews.llvm.org/D5690 llvm-svn: 222192
2014-11-18 07:36:45 +08:00
} else if (FieldDecl *FD = dyn_cast<FieldDecl>(D)) {
Diags.Report(Active->PointOfInstantiation,
diag::note_template_nsdmi_here)
<< FD << Active->InstantiationRange;
Implement support for C++0x alias templates. llvm-svn: 130953
2011-05-06 05:57:07 +08:00
} else {
Diags.Report(Active->PointOfInstantiation,
diag::note_template_type_alias_instantiation_here)
<< cast<TypeAliasTemplateDecl>(D)
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
<< Active->InstantiationRange;
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
}
Extend the notion of active template instantiations to include the context of a template-id for which we need to instantiate default template arguments. In the TextDiagnosticPrinter, don't suppress the caret diagnostic if we are producing a non-note diagnostic that follows a note diagnostic with the same location, because notes are (conceptually) a part of the warning or error that comes before them. llvm-svn: 66572
2009-03-11 04:44:00 +08:00
break;
}
Rename ActiveTemplateInstantiation to CodeSynthesisContext in preparation for using it for other kinds of context (where we currently produce context notes in a highly ad-hoc manner). llvm-svn: 295919
2017-02-23 09:43:54 +08:00
case CodeSynthesisContext::DefaultTemplateArgumentInstantiation: {
PR12298 et al: don't recursively instantiate a template specialization from within the instantiation of that same specialization. This could previously happen for eagerly-instantiated function templates, variable templates, exception specifications, default arguments, and a handful of other cases. We still have an issue here for default template arguments that recursively make use of themselves and likewise for substitution into the type of a non-type template parameter, but in those cases we're producing a different entity each time, so they should instead be caught by the instantiation depth limit. However, currently we will typically run out of stack before we reach it. :( llvm-svn: 280190
2016-08-31 10:15:21 +08:00
TemplateDecl *Template = cast<TemplateDecl>(Active->Template);
[clang][NFC] Use SmallString instead of SmallVector<char Simplifies code in some places and is more explicit about what is being used. No additional includes were added here so no impact on compile time.
2020-11-17 21:02:58 +08:00
SmallString<128> TemplateArgsStr;
Streamify getNameForDiagnostic and remove the string versions of PrintTemplateArgumentList. llvm-svn: 175894
2013-02-22 23:46:01 +08:00
llvm::raw_svector_ostream OS(TemplateArgsStr);
Template->printName(OS);
Refactor functions PrintTemplateArgumentList These functions were defined as static members of TemplateSpecializationType. Now they are moved to namespace level. Previously there were different implementations for lists containing TemplateArgument and TemplateArgumentLoc, now these implementations share the same code. This change is a result of refactoring patch D40508. NFC. llvm-svn: 319178
2017-11-29 00:14:14 +08:00
printTemplateArgumentList(OS, Active->template_arguments(),
getPrintingPolicy());
Refactoring of Diagnostic class. -Move the stuff of Diagnostic related to creating/querying diagnostic IDs into a new DiagnosticIDs class. -DiagnosticIDs can be shared among multiple Diagnostics for multiple translation units. -The rest of the state in Diagnostic object is considered related and tied to one translation unit. -Have Diagnostic point to the SourceManager that is related with. Diagnostic can now accept just a SourceLocation instead of a FullSourceLoc. -Reflect the changes to various interfaces. llvm-svn: 119730
2010-11-19 04:06:41 +08:00
Diags.Report(Active->PointOfInstantiation,
Extend the notion of active template instantiations to include the context of a template-id for which we need to instantiate default template arguments. In the TextDiagnosticPrinter, don't suppress the caret diagnostic if we are producing a non-note diagnostic that follows a note diagnostic with the same location, because notes are (conceptually) a part of the warning or error that comes before them. llvm-svn: 66572
2009-03-11 04:44:00 +08:00
diag::note_default_arg_instantiation_here)
Streamify getNameForDiagnostic and remove the string versions of PrintTemplateArgumentList. llvm-svn: 175894
2013-02-22 23:46:01 +08:00
<< OS.str()
Extend the notion of active template instantiations to include the context of a template-id for which we need to instantiate default template arguments. In the TextDiagnosticPrinter, don't suppress the caret diagnostic if we are producing a non-note diagnostic that follows a note diagnostic with the same location, because notes are (conceptually) a part of the warning or error that comes before them. llvm-svn: 66572
2009-03-11 04:44:00 +08:00
<< Active->InstantiationRange;
break;
}
Template argument deduction for member pointers. Also, introduced some of the framework for performing instantiation as part of template argument deduction. llvm-svn: 73175
2009-06-11 07:47:09 +08:00
Rename ActiveTemplateInstantiation to CodeSynthesisContext in preparation for using it for other kinds of context (where we currently produce context notes in a highly ad-hoc manner). llvm-svn: 295919
2017-02-23 09:43:54 +08:00
case CodeSynthesisContext::ExplicitTemplateArgumentSubstitution: {
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
FunctionTemplateDecl *FnTmpl = cast<FunctionTemplateDecl>(Active->Entity);
Refactoring of Diagnostic class. -Move the stuff of Diagnostic related to creating/querying diagnostic IDs into a new DiagnosticIDs class. -DiagnosticIDs can be shared among multiple Diagnostics for multiple translation units. -The rest of the state in Diagnostic object is considered related and tied to one translation unit. -Have Diagnostic point to the SourceManager that is related with. Diagnostic can now accept just a SourceLocation instead of a FullSourceLoc. -Reflect the changes to various interfaces. llvm-svn: 119730
2010-11-19 04:06:41 +08:00
Diags.Report(Active->PointOfInstantiation,
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
diag::note_explicit_template_arg_substitution_here)
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
<< FnTmpl
<< getTemplateArgumentBindingsText(FnTmpl->getTemplateParameters(),
Active->TemplateArgs,
Improve diagnostics when printing a template instantiation backtrace involving substitution of deduced template arguments into a class template partial specialization or function template, or when substituting explicitly-specific template arguments into a function template. We now print the actual deduced argument bindings so the user can see what got deduced. llvm-svn: 99923
2010-03-31 04:35:20 +08:00
Active->NumTemplateArgs)
<< Active->InstantiationRange;
Template argument deduction for member pointers. Also, introduced some of the framework for performing instantiation as part of template argument deduction. llvm-svn: 73175
2009-06-11 07:47:09 +08:00
break;
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Rename ActiveTemplateInstantiation to CodeSynthesisContext in preparation for using it for other kinds of context (where we currently produce context notes in a highly ad-hoc manner). llvm-svn: 295919
2017-02-23 09:43:54 +08:00
case CodeSynthesisContext::DeducedTemplateArgumentSubstitution: {
Fix crash if substitution fails during deduction of variable template partial specialization arguments. llvm-svn: 290484
2016-12-24 12:20:31 +08:00
if (FunctionTemplateDecl *FnTmpl =
dyn_cast<FunctionTemplateDecl>(Active->Entity)) {
Refactoring of Diagnostic class. -Move the stuff of Diagnostic related to creating/querying diagnostic IDs into a new DiagnosticIDs class. -DiagnosticIDs can be shared among multiple Diagnostics for multiple translation units. -The rest of the state in Diagnostic object is considered related and tied to one translation unit. -Have Diagnostic point to the SourceManager that is related with. Diagnostic can now accept just a SourceLocation instead of a FullSourceLoc. -Reflect the changes to various interfaces. llvm-svn: 119730
2010-11-19 04:06:41 +08:00
Diags.Report(Active->PointOfInstantiation,
Fix crash if substitution fails during deduction of variable template partial specialization arguments. llvm-svn: 290484
2016-12-24 12:20:31 +08:00
diag::note_function_template_deduction_instantiation_here)
<< FnTmpl
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
<< getTemplateArgumentBindingsText(FnTmpl->getTemplateParameters(),
Active->TemplateArgs,
Improve diagnostics when printing a template instantiation backtrace involving substitution of deduced template arguments into a class template partial specialization or function template, or when substituting explicitly-specific template arguments into a function template. We now print the actual deduced argument bindings so the user can see what got deduced. llvm-svn: 99923
2010-03-31 04:35:20 +08:00
Active->NumTemplateArgs)
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
<< Active->InstantiationRange;
} else {
Fix crash if substitution fails during deduction of variable template partial specialization arguments. llvm-svn: 290484
2016-12-24 12:20:31 +08:00
bool IsVar = isa<VarTemplateDecl>(Active->Entity) ||
isa<VarTemplateSpecializationDecl>(Active->Entity);
DR1495: A partial specialization is ill-formed if it is not (strictly) more specialized than the primary template. (Put another way, if we imagine there were a partial specialization matching the primary template, we should never select it if some other partial specialization also matches.) llvm-svn: 290593
2016-12-27 15:56:27 +08:00
bool IsTemplate = false;
Fix crash if substitution fails during deduction of variable template partial specialization arguments. llvm-svn: 290484
2016-12-24 12:20:31 +08:00
TemplateParameterList *Params;
DR1495: A partial specialization is ill-formed if it is not (strictly) more specialized than the primary template. (Put another way, if we imagine there were a partial specialization matching the primary template, we should never select it if some other partial specialization also matches.) llvm-svn: 290593
2016-12-27 15:56:27 +08:00
if (auto *D = dyn_cast<TemplateDecl>(Active->Entity)) {
IsTemplate = true;
Params = D->getTemplateParameters();
} else if (auto *D = dyn_cast<ClassTemplatePartialSpecializationDecl>(
Fix crash if substitution fails during deduction of variable template partial specialization arguments. llvm-svn: 290484
2016-12-24 12:20:31 +08:00
Active->Entity)) {
Params = D->getTemplateParameters();
} else if (auto *D = dyn_cast<VarTemplatePartialSpecializationDecl>(
Active->Entity)) {
Params = D->getTemplateParameters();
} else {
llvm_unreachable("unexpected template kind");
}
Refactoring of Diagnostic class. -Move the stuff of Diagnostic related to creating/querying diagnostic IDs into a new DiagnosticIDs class. -DiagnosticIDs can be shared among multiple Diagnostics for multiple translation units. -The rest of the state in Diagnostic object is considered related and tied to one translation unit. -Have Diagnostic point to the SourceManager that is related with. Diagnostic can now accept just a SourceLocation instead of a FullSourceLoc. -Reflect the changes to various interfaces. llvm-svn: 119730
2010-11-19 04:06:41 +08:00
Diags.Report(Active->PointOfInstantiation,
Fix crash if substitution fails during deduction of variable template partial specialization arguments. llvm-svn: 290484
2016-12-24 12:20:31 +08:00
diag::note_deduced_template_arg_substitution_here)
DR1495: A partial specialization is ill-formed if it is not (strictly) more specialized than the primary template. (Put another way, if we imagine there were a partial specialization matching the primary template, we should never select it if some other partial specialization also matches.) llvm-svn: 290593
2016-12-27 15:56:27 +08:00
<< IsVar << IsTemplate << cast<NamedDecl>(Active->Entity)
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
<< getTemplateArgumentBindingsText(Params, Active->TemplateArgs,
Improve diagnostics when printing a template instantiation backtrace involving substitution of deduced template arguments into a class template partial specialization or function template, or when substituting explicitly-specific template arguments into a function template. We now print the actual deduced argument bindings so the user can see what got deduced. llvm-svn: 99923
2010-03-31 04:35:20 +08:00
Active->NumTemplateArgs)
<< Active->InstantiationRange;
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
}
break;
Fix crash if substitution fails during deduction of variable template partial specialization arguments. llvm-svn: 290484
2016-12-24 12:20:31 +08:00
}
Template argument deduction for member pointers. Also, introduced some of the framework for performing instantiation as part of template argument deduction. llvm-svn: 73175
2009-06-11 07:47:09 +08:00
Rename ActiveTemplateInstantiation to CodeSynthesisContext in preparation for using it for other kinds of context (where we currently produce context notes in a highly ad-hoc manner). llvm-svn: 295919
2017-02-23 09:43:54 +08:00
case CodeSynthesisContext::DefaultFunctionArgumentInstantiation: {
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
ParmVarDecl *Param = cast<ParmVarDecl>(Active->Entity);
Use a separate diagnostic for default function argument expressions. llvm-svn: 81062
2009-09-05 13:14:19 +08:00
FunctionDecl *FD = cast<FunctionDecl>(Param->getDeclContext());
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
[clang][NFC] Use SmallString instead of SmallVector<char Simplifies code in some places and is more explicit about what is being used. No additional includes were added here so no impact on compile time.
2020-11-17 21:02:58 +08:00
SmallString<128> TemplateArgsStr;
Streamify getNameForDiagnostic and remove the string versions of PrintTemplateArgumentList. llvm-svn: 175894
2013-02-22 23:46:01 +08:00
llvm::raw_svector_ostream OS(TemplateArgsStr);
FD->printName(OS);
Refactor functions PrintTemplateArgumentList These functions were defined as static members of TemplateSpecializationType. Now they are moved to namespace level. Previously there were different implementations for lists containing TemplateArgument and TemplateArgumentLoc, now these implementations share the same code. This change is a result of refactoring patch D40508. NFC. llvm-svn: 319178
2017-11-29 00:14:14 +08:00
printTemplateArgumentList(OS, Active->template_arguments(),
getPrintingPolicy());
Refactoring of Diagnostic class. -Move the stuff of Diagnostic related to creating/querying diagnostic IDs into a new DiagnosticIDs class. -DiagnosticIDs can be shared among multiple Diagnostics for multiple translation units. -The rest of the state in Diagnostic object is considered related and tied to one translation unit. -Have Diagnostic point to the SourceManager that is related with. Diagnostic can now accept just a SourceLocation instead of a FullSourceLoc. -Reflect the changes to various interfaces. llvm-svn: 119730
2010-11-19 04:06:41 +08:00
Diags.Report(Active->PointOfInstantiation,
Use a separate diagnostic for default function argument expressions. llvm-svn: 81062
2009-09-05 13:14:19 +08:00
diag::note_default_function_arg_instantiation_here)
Streamify getNameForDiagnostic and remove the string versions of PrintTemplateArgumentList. llvm-svn: 175894
2013-02-22 23:46:01 +08:00
<< OS.str()
Use a separate diagnostic for default function argument expressions. llvm-svn: 81062
2009-09-05 13:14:19 +08:00
<< Active->InstantiationRange;
break;
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Rename ActiveTemplateInstantiation to CodeSynthesisContext in preparation for using it for other kinds of context (where we currently produce context notes in a highly ad-hoc manner). llvm-svn: 295919
2017-02-23 09:43:54 +08:00
case CodeSynthesisContext::PriorTemplateArgumentSubstitution: {
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
NamedDecl *Parm = cast<NamedDecl>(Active->Entity);
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
std::string Name;
if (!Parm->getName().empty())
Name = std::string(" '") + Parm->getName().str() + "'";
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
TemplateParameterList *TemplateParams = nullptr;
Improve our handling of non-type template parameters in partial specializations. We weren't dealing with any of the cases where the type of the non-type template argument differs from the type of the corresponding template parameter in the primary template. We would think that the template parameter in the partial specialization was not deducible (and warn about it, incorrectly), then fail to convert a deduced parameter to the type of the template parameter in the partial specialization (which may involve truncation, among other things). Fixes PR8905. llvm-svn: 122851
2011-01-05 07:35:54 +08:00
if (TemplateDecl *Template = dyn_cast<TemplateDecl>(Active->Template))
TemplateParams = Template->getTemplateParameters();
else
TemplateParams =
cast<ClassTemplatePartialSpecializationDecl>(Active->Template)
->getTemplateParameters();
Refactoring of Diagnostic class. -Move the stuff of Diagnostic related to creating/querying diagnostic IDs into a new DiagnosticIDs class. -DiagnosticIDs can be shared among multiple Diagnostics for multiple translation units. -The rest of the state in Diagnostic object is considered related and tied to one translation unit. -Have Diagnostic point to the SourceManager that is related with. Diagnostic can now accept just a SourceLocation instead of a FullSourceLoc. -Reflect the changes to various interfaces. llvm-svn: 119730
2010-11-19 04:06:41 +08:00
Diags.Report(Active->PointOfInstantiation,
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
diag::note_prior_template_arg_substitution)
<< isa<TemplateTemplateParmDecl>(Parm)
<< Name
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
<< getTemplateArgumentBindingsText(TemplateParams,
Active->TemplateArgs,
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
Active->NumTemplateArgs)
<< Active->InstantiationRange;
break;
}
Improve diagnostics when a default template argument does not match with its corresponding template parameter. This can happen when we performed some substitution into the default template argument and what we had doesn't match any more, e.g., template<int> struct A; template<typename T, template<T> class X = A> class B; B<long> b; Previously, we'd emit a pretty but disembodied diagnostic showing how the default argument didn't match the template parameter. The diagnostic was good, but nothing tied it to the *use* of the default argument in "B<long>". This commit fixes that. Also, tweak the counting of active template instantiations to avoid counting non-instantiation records, such as those we create for (surprise!) checking default arguments, instantiating default arguments, and performing substitutions as part of template argument deduction. llvm-svn: 86884
2009-11-12 05:54:23 +08:00
Rename ActiveTemplateInstantiation to CodeSynthesisContext in preparation for using it for other kinds of context (where we currently produce context notes in a highly ad-hoc manner). llvm-svn: 295919
2017-02-23 09:43:54 +08:00
case CodeSynthesisContext::DefaultTemplateArgumentChecking: {
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
TemplateParameterList *TemplateParams = nullptr;
Improve our handling of non-type template parameters in partial specializations. We weren't dealing with any of the cases where the type of the non-type template argument differs from the type of the corresponding template parameter in the primary template. We would think that the template parameter in the partial specialization was not deducible (and warn about it, incorrectly), then fail to convert a deduced parameter to the type of the template parameter in the partial specialization (which may involve truncation, among other things). Fixes PR8905. llvm-svn: 122851
2011-01-05 07:35:54 +08:00
if (TemplateDecl *Template = dyn_cast<TemplateDecl>(Active->Template))
TemplateParams = Template->getTemplateParameters();
else
TemplateParams =
cast<ClassTemplatePartialSpecializationDecl>(Active->Template)
->getTemplateParameters();
Refactoring of Diagnostic class. -Move the stuff of Diagnostic related to creating/querying diagnostic IDs into a new DiagnosticIDs class. -DiagnosticIDs can be shared among multiple Diagnostics for multiple translation units. -The rest of the state in Diagnostic object is considered related and tied to one translation unit. -Have Diagnostic point to the SourceManager that is related with. Diagnostic can now accept just a SourceLocation instead of a FullSourceLoc. -Reflect the changes to various interfaces. llvm-svn: 119730
2010-11-19 04:06:41 +08:00
Diags.Report(Active->PointOfInstantiation,
Improve diagnostics when a default template argument does not match with its corresponding template parameter. This can happen when we performed some substitution into the default template argument and what we had doesn't match any more, e.g., template<int> struct A; template<typename T, template<T> class X = A> class B; B<long> b; Previously, we'd emit a pretty but disembodied diagnostic showing how the default argument didn't match the template parameter. The diagnostic was good, but nothing tied it to the *use* of the default argument in "B<long>". This commit fixes that. Also, tweak the counting of active template instantiations to avoid counting non-instantiation records, such as those we create for (surprise!) checking default arguments, instantiating default arguments, and performing substitutions as part of template argument deduction. llvm-svn: 86884
2009-11-12 05:54:23 +08:00
diag::note_template_default_arg_checking)
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
<< getTemplateArgumentBindingsText(TemplateParams,
Active->TemplateArgs,
Improve diagnostics when a default template argument does not match with its corresponding template parameter. This can happen when we performed some substitution into the default template argument and what we had doesn't match any more, e.g., template<int> struct A; template<typename T, template<T> class X = A> class B; B<long> b; Previously, we'd emit a pretty but disembodied diagnostic showing how the default argument didn't match the template parameter. The diagnostic was good, but nothing tied it to the *use* of the default argument in "B<long>". This commit fixes that. Also, tweak the counting of active template instantiations to avoid counting non-instantiation records, such as those we create for (surprise!) checking default arguments, instantiating default arguments, and performing substitutions as part of template argument deduction. llvm-svn: 86884
2009-11-12 05:54:23 +08:00
Active->NumTemplateArgs)
<< Active->InstantiationRange;
break;
}
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
PR38627: Fix handling of exception specification adjustment for destructors. We previously tried to patch up the exception specification after completing the class, which went wrong when the exception specification was needed within the class body (in particular, by a friend redeclaration of the destructor in a nested class). We now mark the destructor as having a not-yet-computed exception specification immediately after creating it. This requires delaying various checks against the exception specification (where we'd previously have just got the wrong exception specification, and now find we have an exception specification that we can't compute yet) when those checks fire while the class is being defined. This also exposed an issue that we were missing a CodeSynthesisContext for computation of exception specifications (otherwise we'd fail to make the module containing the definition of the class visible when computing its members' exception specs). Adding that incidentally also gives us a diagnostic quality improvement. This has also exposed an pre-existing problem: making the exception specification evaluation context a non-SFINAE context (as it should be) results in a bootstrap failure; PR38850 filed for this. llvm-svn: 341499
2018-09-06 06:30:37 +08:00
case CodeSynthesisContext::ExceptionSpecEvaluation:
Diags.Report(Active->PointOfInstantiation,
diag::note_evaluating_exception_spec_here)
<< cast<FunctionDecl>(Active->Entity);
break;
Rename ActiveTemplateInstantiation to CodeSynthesisContext in preparation for using it for other kinds of context (where we currently produce context notes in a highly ad-hoc manner). llvm-svn: 295919
2017-02-23 09:43:54 +08:00
case CodeSynthesisContext::ExceptionSpecInstantiation:
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
Diags.Report(Active->PointOfInstantiation,
diag::note_template_exception_spec_instantiation_here)
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
<< cast<FunctionDecl>(Active->Entity)
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
<< Active->InstantiationRange;
break;
Add context note to diagnostics that occur while declaring an implicit special member function. llvm-svn: 296020
2017-02-24 05:43:43 +08:00
[Concepts] Requires Expressions Implement support for C++2a requires-expressions. Re-commit after compilation failure on some platforms due to alignment issues with PointerIntPair. Differential Revision: https://reviews.llvm.org/D50360
2020-01-18 15:11:43 +08:00
case CodeSynthesisContext::RequirementInstantiation:
Diags.Report(Active->PointOfInstantiation,
diag::note_template_requirement_instantiation_here)
<< Active->InstantiationRange;
break;
case CodeSynthesisContext::NestedRequirementConstraintsCheck:
Diags.Report(Active->PointOfInstantiation,
diag::note_nested_requirement_here)
<< Active->InstantiationRange;
break;
Add context note to diagnostics that occur while declaring an implicit special member function. llvm-svn: 296020
2017-02-24 05:43:43 +08:00
case CodeSynthesisContext::DeclaringSpecialMember:
Diags.Report(Active->PointOfInstantiation,
diag::note_in_declaration_of_implicit_special_member)
<< cast<CXXRecordDecl>(Active->Entity) << Active->SpecialMember;
break;
Switch from using a DiagnosticTrap and a note for "while defining a special member function" context notes to registering an entry on the context stack. Also reorder the steps within defining special members to be consistent. This has a few benefits: if multiple diagnostics are produced while checking such a member, the note is now attached to the first such diagnostic rather than the last, this prepares us for persisting these diagnostics between the point at which we require the implicit instantiation of a template and the point at which that instantiation is actually performed, and this fixes some cases where we would fail to produce a full note stack leading back to user code in the case of such a diagnostic. The reordering exposed a case where we could recursively attempt to define a defaulted destructor while we're already defining one (and other such cases also appear to be possible, with or without this change), so this change also reuses the "willHaveBody" flag on function declarations to track that we're in the middle of synthesizing a body for the function and bails out if we try to define a function that we're already defining. llvm-svn: 303930
2017-05-26 06:47:05 +08:00
[c++20] Implement P1185R2 (as modified by P2002R0). For each defaulted operator<=> in a class that doesn't explicitly declare any operator==, also inject a matching implicit defaulted operator==.
2019-12-11 08:45:02 +08:00
case CodeSynthesisContext::DeclaringImplicitEqualityComparison:
Diags.Report(Active->Entity->getLocation(),
diag::note_in_declaration_of_implicit_equality_comparison);
break;
[Templight] Template Instantiation Observer This patch adds a base-class called TemplateInstantiationObserver which gets notified whenever a template instantiation is entered or exited during semantic analysis. This is a base class used to implement the template profiling and debugging tool called Templight (https://github.com/mikael-s-persson/templight). The patch also makes a few more changes: * ActiveTemplateInstantiation class is moved out of the Sema class (so it can be used with inclusion of Sema.h). * CreateFrontendAction function in front-end utilities is given external linkage (not longer a hidden static function). * TemplateInstObserverChain data member added to Sema class to hold the list of template-inst observers. * Notifications to the template-inst observer are added at the key places where templates are instantiated. Patch by: Abel Sinkovics! Differential Revision: https://reviews.llvm.org/D5767 llvm-svn: 324808
2018-02-10 22:04:45 +08:00
case CodeSynthesisContext::DefiningSynthesizedFunction: {
[c++20] Synthesis of defaulted comparison functions. Array members are not yet handled. In addition, defaulted comparisons can't yet find comparison operators by unqualified lookup (only by member lookup and ADL). These issues will be fixed in follow-on changes.
2019-12-05 07:25:27 +08:00
// FIXME: For synthesized functions that are not defaulted,
// produce a note.
auto *FD = dyn_cast<FunctionDecl>(Active->Entity);
DefaultedFunctionKind DFK =
FD ? getDefaultedFunctionKind(FD) : DefaultedFunctionKind();
if (DFK.isSpecialMember()) {
auto *MD = cast<CXXMethodDecl>(FD);
Switch from using a DiagnosticTrap and a note for "while defining a special member function" context notes to registering an entry on the context stack. Also reorder the steps within defining special members to be consistent. This has a few benefits: if multiple diagnostics are produced while checking such a member, the note is now attached to the first such diagnostic rather than the last, this prepares us for persisting these diagnostics between the point at which we require the implicit instantiation of a template and the point at which that instantiation is actually performed, and this fixes some cases where we would fail to produce a full note stack leading back to user code in the case of such a diagnostic. The reordering exposed a case where we could recursively attempt to define a defaulted destructor while we're already defining one (and other such cases also appear to be possible, with or without this change), so this change also reuses the "willHaveBody" flag on function declarations to track that we're in the middle of synthesizing a body for the function and bails out if we try to define a function that we're already defining. llvm-svn: 303930
2017-05-26 06:47:05 +08:00
Diags.Report(Active->PointOfInstantiation,
diag::note_member_synthesized_at)
[c++20] Synthesis of defaulted comparison functions. Array members are not yet handled. In addition, defaulted comparisons can't yet find comparison operators by unqualified lookup (only by member lookup and ADL). These issues will be fixed in follow-on changes.
2019-12-05 07:25:27 +08:00
<< MD->isExplicitlyDefaulted() << DFK.asSpecialMember()
<< Context.getTagDeclType(MD->getParent());
} else if (DFK.isComparison()) {
Diags.Report(Active->PointOfInstantiation,
diag::note_comparison_synthesized_at)
<< (int)DFK.asComparison()
<< Context.getTagDeclType(
cast<CXXRecordDecl>(FD->getLexicalDeclContext()));
Switch from using a DiagnosticTrap and a note for "while defining a special member function" context notes to registering an entry on the context stack. Also reorder the steps within defining special members to be consistent. This has a few benefits: if multiple diagnostics are produced while checking such a member, the note is now attached to the first such diagnostic rather than the last, this prepares us for persisting these diagnostics between the point at which we require the implicit instantiation of a template and the point at which that instantiation is actually performed, and this fixes some cases where we would fail to produce a full note stack leading back to user code in the case of such a diagnostic. The reordering exposed a case where we could recursively attempt to define a defaulted destructor while we're already defining one (and other such cases also appear to be possible, with or without this change), so this change also reuses the "willHaveBody" flag on function declarations to track that we're in the middle of synthesizing a body for the function and bails out if we try to define a function that we're already defining. llvm-svn: 303930
2017-05-26 06:47:05 +08:00
}
break;
Extend the notion of active template instantiations to include the context of a template-id for which we need to instantiate default template arguments. In the TextDiagnosticPrinter, don't suppress the caret diagnostic if we are producing a non-note diagnostic that follows a note diagnostic with the same location, because notes are (conceptually) a part of the warning or error that comes before them. llvm-svn: 66572
2009-03-11 04:44:00 +08:00
}
[Templight] Template Instantiation Observer This patch adds a base-class called TemplateInstantiationObserver which gets notified whenever a template instantiation is entered or exited during semantic analysis. This is a base class used to implement the template profiling and debugging tool called Templight (https://github.com/mikael-s-persson/templight). The patch also makes a few more changes: * ActiveTemplateInstantiation class is moved out of the Sema class (so it can be used with inclusion of Sema.h). * CreateFrontendAction function in front-end utilities is given external linkage (not longer a hidden static function). * TemplateInstObserverChain data member added to Sema class to hold the list of template-inst observers. * Notifications to the template-inst observer are added at the key places where templates are instantiated. Patch by: Abel Sinkovics! Differential Revision: https://reviews.llvm.org/D5767 llvm-svn: 324808
2018-02-10 22:04:45 +08:00
[c++20] Add rewriting from comparison operators to <=> / ==. This adds support for rewriting <, >, <=, and >= to a normal or reversed call to operator<=>, for rewriting != to a normal or reversed call to operator==, and for rewriting <=> and == to reversed forms of those same operators. Note that this is a breaking change for various C++17 code patterns, including some in use in LLVM. The most common patterns (where an operator== becomes ambiguous with a reversed form of itself) are still accepted under this patch, as an extension (with a warning). I'm hopeful that we can get the language rules fixed before C++20 ships, and the extension warning is aimed primarily at providing data to inform that decision. llvm-svn: 375306
2019-10-19 08:04:43 +08:00
case CodeSynthesisContext::RewritingOperatorAsSpaceship:
Diags.Report(Active->Entity->getLocation(),
diag::note_rewriting_operator_as_spaceship);
break;
Remove improper uses of DiagnosticErrorTrap and hasErrorOccurred. DiagnosticErrorTrap is usually inappropriate because it indicates whether an error message was rendered in a given region (and is therefore affected by -ferror-limit and by suppression of errors if we see an invalid declaration). hasErrorOccurred() is usually inappropriate because it indicates whethere an "error:" message was displayed, regardless of whether the message was a warning promoted to an error, and therefore depends on things like -Werror that are usually irrelevant. Where applicable, CodeSynthesisContexts are used to attach notes to the first diagnostic produced in a region of code, isnstead of using an error trap and then attaching a note to whichever diagnostic happened to be produced last (or suppressing the note if the final diagnostic is a disabled warning!). This is mostly NFC.
2020-06-09 05:04:54 +08:00
case CodeSynthesisContext::InitializingStructuredBinding:
Diags.Report(Active->PointOfInstantiation,
diag::note_in_binding_decl_init)
<< cast<BindingDecl>(Active->Entity);
break;
case CodeSynthesisContext::MarkingClassDllexported:
Diags.Report(Active->PointOfInstantiation,
diag::note_due_to_dllexported_class)
<< cast<CXXRecordDecl>(Active->Entity) << !getLangOpts().CPlusPlus11;
break;
[Templight] Template Instantiation Observer This patch adds a base-class called TemplateInstantiationObserver which gets notified whenever a template instantiation is entered or exited during semantic analysis. This is a base class used to implement the template profiling and debugging tool called Templight (https://github.com/mikael-s-persson/templight). The patch also makes a few more changes: * ActiveTemplateInstantiation class is moved out of the Sema class (so it can be used with inclusion of Sema.h). * CreateFrontendAction function in front-end utilities is given external linkage (not longer a hidden static function). * TemplateInstObserverChain data member added to Sema class to hold the list of template-inst observers. * Notifications to the template-inst observer are added at the key places where templates are instantiated. Patch by: Abel Sinkovics! Differential Revision: https://reviews.llvm.org/D5767 llvm-svn: 324808
2018-02-10 22:04:45 +08:00
case CodeSynthesisContext::Memoization:
break;
[NFC] Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h,td}
2020-02-18 10:48:38 +08:00
[Concepts] Constraint Enforcement & Diagnostics Part of the C++20 concepts implementation effort. - Associated constraints (requires clauses, currently) are now enforced when instantiating/specializing templates and when considering partial specializations and function overloads. - Elaborated diagnostics give helpful insight as to why the constraints were not satisfied. Phabricator: D41569 Re-commit, after fixing some memory bugs.
2019-12-06 07:30:21 +08:00
case CodeSynthesisContext::ConstraintsCheck: {
unsigned DiagID = 0;
[Concepts] Transform constraints of non-template functions to ConstantEvaluated We would previously try to evaluate atomic constraints of non-template functions as-is, and since they are now unevaluated at first, this would cause incorrect evaluation (bugs #44657, #44656). Substitute into atomic constraints of non-template functions as we would atomic constraints of template functions, in order to rebuild the expressions in a constant-evaluated context.
2020-01-26 04:54:27 +08:00
if (!Active->Entity) {
Diags.Report(Active->PointOfInstantiation,
diag::note_nested_requirement_here)
<< Active->InstantiationRange;
break;
}
[Concepts] Constraint Enforcement & Diagnostics Part of the C++20 concepts implementation effort. - Associated constraints (requires clauses, currently) are now enforced when instantiating/specializing templates and when considering partial specializations and function overloads. - Elaborated diagnostics give helpful insight as to why the constraints were not satisfied. Phabricator: D41569 Re-commit, after fixing some memory bugs.
2019-12-06 07:30:21 +08:00
if (isa<ConceptDecl>(Active->Entity))
DiagID = diag::note_concept_specialization_here;
else if (isa<TemplateDecl>(Active->Entity))
DiagID = diag::note_checking_constraints_for_template_id_here;
else if (isa<VarTemplatePartialSpecializationDecl>(Active->Entity))
DiagID = diag::note_checking_constraints_for_var_spec_id_here;
[Concepts] Transform constraints of non-template functions to ConstantEvaluated We would previously try to evaluate atomic constraints of non-template functions as-is, and since they are now unevaluated at first, this would cause incorrect evaluation (bugs #44657, #44656). Substitute into atomic constraints of non-template functions as we would atomic constraints of template functions, in order to rebuild the expressions in a constant-evaluated context.
2020-01-26 04:54:27 +08:00
else if (isa<ClassTemplatePartialSpecializationDecl>(Active->Entity))
[Concepts] Constraint Enforcement & Diagnostics Part of the C++20 concepts implementation effort. - Associated constraints (requires clauses, currently) are now enforced when instantiating/specializing templates and when considering partial specializations and function overloads. - Elaborated diagnostics give helpful insight as to why the constraints were not satisfied. Phabricator: D41569 Re-commit, after fixing some memory bugs.
2019-12-06 07:30:21 +08:00
DiagID = diag::note_checking_constraints_for_class_spec_id_here;
[Concepts] Transform constraints of non-template functions to ConstantEvaluated We would previously try to evaluate atomic constraints of non-template functions as-is, and since they are now unevaluated at first, this would cause incorrect evaluation (bugs #44657, #44656). Substitute into atomic constraints of non-template functions as we would atomic constraints of template functions, in order to rebuild the expressions in a constant-evaluated context.
2020-01-26 04:54:27 +08:00
else {
assert(isa<FunctionDecl>(Active->Entity));
DiagID = diag::note_checking_constraints_for_function_here;
[Concepts] Concept Specialization Expressions Part of C++20 Concepts implementation effort. Added Concept Specialization Expressions that are created when a concept is refe$ D41217 on Phabricator. (recommit after fixing failing Parser test on windows) llvm-svn: 374903
2019-10-15 23:24:26 +08:00
}
[clang][NFC] Use SmallString instead of SmallVector<char Simplifies code in some places and is more explicit about what is being used. No additional includes were added here so no impact on compile time.
2020-11-17 21:02:58 +08:00
SmallString<128> TemplateArgsStr;
[Concepts] Constraint Enforcement & Diagnostics Part of the C++20 concepts implementation effort. - Associated constraints (requires clauses, currently) are now enforced when instantiating/specializing templates and when considering partial specializations and function overloads. - Elaborated diagnostics give helpful insight as to why the constraints were not satisfied. Phabricator: D41569 Re-commit, after fixing some memory bugs.
2019-12-06 07:30:21 +08:00
llvm::raw_svector_ostream OS(TemplateArgsStr);
cast<NamedDecl>(Active->Entity)->printName(OS);
Add type information to integral template argument if required. Non-comprehensive list of cases: * Dumping template arguments; * Corresponding parameter contains a deduced type; * Template arguments are for a DeclRefExpr that hadMultipleCandidates() Type information is added in the form of prefixes (u8, u, U, L), suffixes (U, L, UL, LL, ULL) or explicit casts to printed integral template argument, if MSVC codeview mode is disabled. Differential revision: https://reviews.llvm.org/D77598
2021-05-13 01:28:41 +08:00
if (!isa<FunctionDecl>(Active->Entity)) {
[Concepts] Transform constraints of non-template functions to ConstantEvaluated We would previously try to evaluate atomic constraints of non-template functions as-is, and since they are now unevaluated at first, this would cause incorrect evaluation (bugs #44657, #44656). Substitute into atomic constraints of non-template functions as we would atomic constraints of template functions, in order to rebuild the expressions in a constant-evaluated context.
2020-01-26 04:54:27 +08:00
printTemplateArgumentList(OS, Active->template_arguments(),
getPrintingPolicy());
Add type information to integral template argument if required. Non-comprehensive list of cases: * Dumping template arguments; * Corresponding parameter contains a deduced type; * Template arguments are for a DeclRefExpr that hadMultipleCandidates() Type information is added in the form of prefixes (u8, u, U, L), suffixes (U, L, UL, LL, ULL) or explicit casts to printed integral template argument, if MSVC codeview mode is disabled. Differential revision: https://reviews.llvm.org/D77598
2021-05-13 01:28:41 +08:00
}
[Concepts] Constraint Enforcement & Diagnostics Part of the C++20 concepts implementation effort. - Associated constraints (requires clauses, currently) are now enforced when instantiating/specializing templates and when considering partial specializations and function overloads. - Elaborated diagnostics give helpful insight as to why the constraints were not satisfied. Phabricator: D41569 Re-commit, after fixing some memory bugs.
2019-12-06 07:30:21 +08:00
Diags.Report(Active->PointOfInstantiation, DiagID) << OS.str()
<< Active->InstantiationRange;
[Concepts] Concept Specialization Expressions Part of C++20 Concepts implementation effort. Added Concept Specialization Expressions that are created when a concept is refe$ D41217 on Phabricator. (recommit after fixing failing Parser test on windows) llvm-svn: 374903
2019-10-15 23:24:26 +08:00
break;
[Concepts] Constraint Enforcement & Diagnostics Part of the C++20 concepts implementation effort. - Associated constraints (requires clauses, currently) are now enforced when instantiating/specializing templates and when considering partial specializations and function overloads. - Elaborated diagnostics give helpful insight as to why the constraints were not satisfied. Phabricator: D41569 Re-commit, after fixing some memory bugs.
2019-12-06 07:30:21 +08:00
}
[Concepts] Concept Specialization Expressions Part of C++20 Concepts implementation effort. Added Concept Specialization Expressions that are created when a concept is refe$ D41217 on Phabricator. (recommit after fixing failing Parser test on windows) llvm-svn: 374903
2019-10-15 23:24:26 +08:00
case CodeSynthesisContext::ConstraintSubstitution:
Diags.Report(Active->PointOfInstantiation,
diag::note_constraint_substitution_here)
<< Active->InstantiationRange;
break;
[Concepts] Constrained partial specializations and function overloads. Added support for constraint satisfaction checking and partial ordering of constraints in constrained partial specialization and function template overloads. Re-commit after fixing another crash (added regression test). Differential Revision: https://reviews.llvm.org/D41910
2019-12-23 14:37:35 +08:00
case CodeSynthesisContext::ConstraintNormalization:
Diags.Report(Active->PointOfInstantiation,
diag::note_constraint_normalization_here)
<< cast<NamedDecl>(Active->Entity)->getName()
<< Active->InstantiationRange;
break;
case CodeSynthesisContext::ParameterMappingSubstitution:
Diags.Report(Active->PointOfInstantiation,
diag::note_parameter_mapping_substitution_here)
<< Active->InstantiationRange;
break;
[Templight] Template Instantiation Observer This patch adds a base-class called TemplateInstantiationObserver which gets notified whenever a template instantiation is entered or exited during semantic analysis. This is a base class used to implement the template profiling and debugging tool called Templight (https://github.com/mikael-s-persson/templight). The patch also makes a few more changes: * ActiveTemplateInstantiation class is moved out of the Sema class (so it can be used with inclusion of Sema.h). * CreateFrontendAction function in front-end utilities is given external linkage (not longer a hidden static function). * TemplateInstObserverChain data member added to Sema class to hold the list of template-inst observers. * Notifications to the template-inst observer are added at the key places where templates are instantiated. Patch by: Abel Sinkovics! Differential Revision: https://reviews.llvm.org/D5767 llvm-svn: 324808
2018-02-10 22:04:45 +08:00
}
Add a notion of "post-diagnostic hooks", which are callbacks attached to a diagnostic that will be invoked after the diagnostic (if it is not suppressed). The hooks are allowed to produce additional diagnostics (typically notes) that provide more information. We should be able to use this to help diagnostic clients link notes back to the diagnostic they clarify. Comments welcome; I'll write up documentation and convert other clients (e.g., overload resolution failures) if there are no screams of protest. As the first client of post-diagnostic hooks, we now produce a template instantiation backtrace when a failure occurs during template instantiation. There's still more work to do to make this output pretty, if that's even possible. llvm-svn: 66557
2009-03-11 02:03:33 +08:00
}
}
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<TemplateDeductionInfo *> Sema::isSFINAEContext() const {
Teach the evaluation of the __is_convertible_to trait to translate access control errors into SFINAE errors, so that the trait provides enough support to implement the C++0x std::is_convertible type trait. To get there, the SFINAETrap now knows how to set up a SFINAE context independent of any template instantiations or template argument deduction steps, and (separately) can set a Sema flag to translate access control errors into SFINAE errors. The latter can also be useful if we decide that access control errors during template argument deduction should cause substitution failure (rather than a hard error) as has been proposed for C++0x. llvm-svn: 124446
2011-01-28 06:31:44 +08:00
if (InNonInstantiationSFINAEContext)
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return Optional<TemplateDeductionInfo *>(nullptr);
Teach the evaluation of the __is_convertible_to trait to translate access control errors into SFINAE errors, so that the trait provides enough support to implement the C++0x std::is_convertible type trait. To get there, the SFINAETrap now knows how to set up a SFINAE context independent of any template instantiations or template argument deduction steps, and (separately) can set a Sema flag to translate access control errors into SFINAE errors. The latter can also be useful if we decide that access control errors during template argument deduction should cause substitution failure (rather than a hard error) as has been proposed for C++0x. llvm-svn: 124446
2011-01-28 06:31:44 +08:00
Rename ActiveTemplateInstantiation to CodeSynthesisContext in preparation for using it for other kinds of context (where we currently produce context notes in a highly ad-hoc manner). llvm-svn: 295919
2017-02-23 09:43:54 +08:00
for (SmallVectorImpl<CodeSynthesisContext>::const_reverse_iterator
Active = CodeSynthesisContexts.rbegin(),
ActiveEnd = CodeSynthesisContexts.rend();
Update LLVM. Implement support for C++ Substitution Failure Is Not An Error (SFINAE), which says that errors that occur during template argument deduction do *not* produce diagnostics and do not necessarily make a program ill-formed. Instead, template argument deduction silently fails. This is currently implemented for template argument deduction during matching of class template partial specializations, although the mechanism will also apply to template argument deduction for function templates. The scheme is simple: - If we are in a template argument deduction context, any diagnostic that is considered a SFINAE error (or warning) will be suppressed. The error will be propagated up the call stack via the normal means. - By default, all warnings and errors are SFINAE errors. Add the NoSFINAE class to a diagnostic in the .td file to make it a hard error (e.g., for access-control violations). Note that, to make this fully work, every place in Sema that emits an error *and then immediately recovers* will need to check Sema::isSFINAEContext() to determine whether it must immediately return an error rather than recovering. llvm-svn: 73332
2009-06-14 15:33:30 +08:00
Active != ActiveEnd;
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
++Active)
Improve diagnostics when a default template argument does not match with its corresponding template parameter. This can happen when we performed some substitution into the default template argument and what we had doesn't match any more, e.g., template<int> struct A; template<typename T, template<T> class X = A> class B; B<long> b; Previously, we'd emit a pretty but disembodied diagnostic showing how the default argument didn't match the template parameter. The diagnostic was good, but nothing tied it to the *use* of the default argument in "B<long>". This commit fixes that. Also, tweak the counting of active template instantiations to avoid counting non-instantiation records, such as those we create for (surprise!) checking default arguments, instantiating default arguments, and performing substitutions as part of template argument deduction. llvm-svn: 86884
2009-11-12 05:54:23 +08:00
{
Add context note to diagnostics that occur while declaring an implicit special member function. llvm-svn: 296020
2017-02-24 05:43:43 +08:00
switch (Active->Kind) {
Rename ActiveTemplateInstantiation to CodeSynthesisContext in preparation for using it for other kinds of context (where we currently produce context notes in a highly ad-hoc manner). llvm-svn: 295919
2017-02-23 09:43:54 +08:00
case CodeSynthesisContext::TemplateInstantiation:
PR12647: An alias template instantiation which occurs in a SFINAE context is itself a SFINAE context. llvm-svn: 155621
2012-04-26 15:24:08 +08:00
// An instantiation of an alias template may or may not be a SFINAE
// context, depending on what else is on the stack.
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
if (isa<TypeAliasTemplateDecl>(Active->Entity))
PR12647: An alias template instantiation which occurs in a SFINAE context is itself a SFINAE context. llvm-svn: 155621
2012-04-26 15:24:08 +08:00
break;
Fix clang -Wimplicit-fallthrough warnings across llvm, NFC This patch should not introduce any behavior changes. It consists of mostly one of two changes: 1. Replacing fall through comments with the LLVM_FALLTHROUGH macro 2. Inserting 'break' before falling through into a case block consisting of only 'break'. We were already using this warning with GCC, but its warning behaves slightly differently. In this patch, the following differences are relevant: 1. GCC recognizes comments that say "fall through" as annotations, clang doesn't 2. GCC doesn't warn on "case N: foo(); default: break;", clang does 3. GCC doesn't warn when the case contains a switch, but falls through the outer case. I will enable the warning separately in a follow-up patch so that it can be cleanly reverted if necessary. Reviewers: alexfh, rsmith, lattner, rtrieu, EricWF, bollu Differential Revision: https://reviews.llvm.org/D53950 llvm-svn: 345882
2018-11-02 03:54:45 +08:00
LLVM_FALLTHROUGH;
Rename ActiveTemplateInstantiation to CodeSynthesisContext in preparation for using it for other kinds of context (where we currently produce context notes in a highly ad-hoc manner). llvm-svn: 295919
2017-02-23 09:43:54 +08:00
case CodeSynthesisContext::DefaultFunctionArgumentInstantiation:
case CodeSynthesisContext::ExceptionSpecInstantiation:
[Concepts] Concept Specialization Expressions Part of C++20 Concepts implementation effort. Added Concept Specialization Expressions that are created when a concept is refe$ D41217 on Phabricator. (recommit after fixing failing Parser test on windows) llvm-svn: 374903
2019-10-15 23:24:26 +08:00
case CodeSynthesisContext::ConstraintsCheck:
[Concepts] Constrained partial specializations and function overloads. Added support for constraint satisfaction checking and partial ordering of constraints in constrained partial specialization and function template overloads. Re-commit after fixing another crash (added regression test). Differential Revision: https://reviews.llvm.org/D41910
2019-12-23 14:37:35 +08:00
case CodeSynthesisContext::ParameterMappingSubstitution:
case CodeSynthesisContext::ConstraintNormalization:
[Concepts] Requires Expressions Implement support for C++2a requires-expressions. Re-commit after compilation failure on some platforms due to alignment issues with PointerIntPair. Differential Revision: https://reviews.llvm.org/D50360
2020-01-18 15:11:43 +08:00
case CodeSynthesisContext::NestedRequirementConstraintsCheck:
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
// This is a template instantiation, so there is no SFINAE.
Use None rather than Optional<T>() where possible. llvm-svn: 175705
2013-02-21 09:47:18 +08:00
return None;
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Rename ActiveTemplateInstantiation to CodeSynthesisContext in preparation for using it for other kinds of context (where we currently produce context notes in a highly ad-hoc manner). llvm-svn: 295919
2017-02-23 09:43:54 +08:00
case CodeSynthesisContext::DefaultTemplateArgumentInstantiation:
case CodeSynthesisContext::PriorTemplateArgumentSubstitution:
case CodeSynthesisContext::DefaultTemplateArgumentChecking:
PR47893: Synthesis of a comparison operator from an 'operator<=>' inherits the SFINAEness of its enclosing context.
2020-10-19 05:15:12 +08:00
case CodeSynthesisContext::RewritingOperatorAsSpaceship:
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
// A default template argument instantiation and substitution into
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
// template parameters with arguments for prior parameters may or may
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
// not be a SFINAE context; look further up the stack.
Update LLVM. Implement support for C++ Substitution Failure Is Not An Error (SFINAE), which says that errors that occur during template argument deduction do *not* produce diagnostics and do not necessarily make a program ill-formed. Instead, template argument deduction silently fails. This is currently implemented for template argument deduction during matching of class template partial specializations, although the mechanism will also apply to template argument deduction for function templates. The scheme is simple: - If we are in a template argument deduction context, any diagnostic that is considered a SFINAE error (or warning) will be suppressed. The error will be propagated up the call stack via the normal means. - By default, all warnings and errors are SFINAE errors. Add the NoSFINAE class to a diagnostic in the .td file to make it a hard error (e.g., for access-control violations). Note that, to make this fully work, every place in Sema that emits an error *and then immediately recovers* will need to check Sema::isSFINAEContext() to determine whether it must immediately return an error rather than recovering. llvm-svn: 73332
2009-06-14 15:33:30 +08:00
break;
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Rename ActiveTemplateInstantiation to CodeSynthesisContext in preparation for using it for other kinds of context (where we currently produce context notes in a highly ad-hoc manner). llvm-svn: 295919
2017-02-23 09:43:54 +08:00
case CodeSynthesisContext::ExplicitTemplateArgumentSubstitution:
case CodeSynthesisContext::DeducedTemplateArgumentSubstitution:
[Concepts] Concept Specialization Expressions Part of C++20 Concepts implementation effort. Added Concept Specialization Expressions that are created when a concept is refe$ D41217 on Phabricator. (recommit after fixing failing Parser test on windows) llvm-svn: 374903
2019-10-15 23:24:26 +08:00
case CodeSynthesisContext::ConstraintSubstitution:
[Concepts] Requires Expressions Implement support for C++2a requires-expressions. Re-commit after compilation failure on some platforms due to alignment issues with PointerIntPair. Differential Revision: https://reviews.llvm.org/D50360
2020-01-18 15:11:43 +08:00
case CodeSynthesisContext::RequirementInstantiation:
// We're either substituting explicitly-specified template arguments,
// deduced template arguments, a constraint expression or a requirement
// in a requires expression, so SFINAE applies.
Introduce support for emitting diagnostics (warnings + their notes) that are suppressed during template argument deduction. This change queues diagnostics computed during template argument deduction. Then, if the resulting function template specialization or partial specialization is chosen by overload resolution or partial ordering (respectively), we will emit the queued diagnostics at that point. This addresses most of PR6784. However, the check for unnamed/local template arguments (which existed before this change) is still only skin-deep, and needs to be extended to look deeper into types. It must be improved to finish PR6784. llvm-svn: 116373
2010-10-13 07:32:35 +08:00
assert(Active->DeductionInfo && "Missing deduction info pointer");
return Active->DeductionInfo;
Add context note to diagnostics that occur while declaring an implicit special member function. llvm-svn: 296020
2017-02-24 05:43:43 +08:00
case CodeSynthesisContext::DeclaringSpecialMember:
[c++20] Implement P1185R2 (as modified by P2002R0). For each defaulted operator<=> in a class that doesn't explicitly declare any operator==, also inject a matching implicit defaulted operator==.
2019-12-11 08:45:02 +08:00
case CodeSynthesisContext::DeclaringImplicitEqualityComparison:
Switch from using a DiagnosticTrap and a note for "while defining a special member function" context notes to registering an entry on the context stack. Also reorder the steps within defining special members to be consistent. This has a few benefits: if multiple diagnostics are produced while checking such a member, the note is now attached to the first such diagnostic rather than the last, this prepares us for persisting these diagnostics between the point at which we require the implicit instantiation of a template and the point at which that instantiation is actually performed, and this fixes some cases where we would fail to produce a full note stack leading back to user code in the case of such a diagnostic. The reordering exposed a case where we could recursively attempt to define a defaulted destructor while we're already defining one (and other such cases also appear to be possible, with or without this change), so this change also reuses the "willHaveBody" flag on function declarations to track that we're in the middle of synthesizing a body for the function and bails out if we try to define a function that we're already defining. llvm-svn: 303930
2017-05-26 06:47:05 +08:00
case CodeSynthesisContext::DefiningSynthesizedFunction:
Remove improper uses of DiagnosticErrorTrap and hasErrorOccurred. DiagnosticErrorTrap is usually inappropriate because it indicates whether an error message was rendered in a given region (and is therefore affected by -ferror-limit and by suppression of errors if we see an invalid declaration). hasErrorOccurred() is usually inappropriate because it indicates whethere an "error:" message was displayed, regardless of whether the message was a warning promoted to an error, and therefore depends on things like -Werror that are usually irrelevant. Where applicable, CodeSynthesisContexts are used to attach notes to the first diagnostic produced in a region of code, isnstead of using an error trap and then attaching a note to whichever diagnostic happened to be produced last (or suppressing the note if the final diagnostic is a disabled warning!). This is mostly NFC.
2020-06-09 05:04:54 +08:00
case CodeSynthesisContext::InitializingStructuredBinding:
case CodeSynthesisContext::MarkingClassDllexported:
Add context note to diagnostics that occur while declaring an implicit special member function. llvm-svn: 296020
2017-02-24 05:43:43 +08:00
// This happens in a context unrelated to template instantiation, so
// there is no SFINAE.
return None;
[Templight] Template Instantiation Observer This patch adds a base-class called TemplateInstantiationObserver which gets notified whenever a template instantiation is entered or exited during semantic analysis. This is a base class used to implement the template profiling and debugging tool called Templight (https://github.com/mikael-s-persson/templight). The patch also makes a few more changes: * ActiveTemplateInstantiation class is moved out of the Sema class (so it can be used with inclusion of Sema.h). * CreateFrontendAction function in front-end utilities is given external linkage (not longer a hidden static function). * TemplateInstObserverChain data member added to Sema class to hold the list of template-inst observers. * Notifications to the template-inst observer are added at the key places where templates are instantiated. Patch by: Abel Sinkovics! Differential Revision: https://reviews.llvm.org/D5767 llvm-svn: 324808
2018-02-10 22:04:45 +08:00
PR38627: Fix handling of exception specification adjustment for destructors. We previously tried to patch up the exception specification after completing the class, which went wrong when the exception specification was needed within the class body (in particular, by a friend redeclaration of the destructor in a nested class). We now mark the destructor as having a not-yet-computed exception specification immediately after creating it. This requires delaying various checks against the exception specification (where we'd previously have just got the wrong exception specification, and now find we have an exception specification that we can't compute yet) when those checks fire while the class is being defined. This also exposed an issue that we were missing a CodeSynthesisContext for computation of exception specifications (otherwise we'd fail to make the module containing the definition of the class visible when computing its members' exception specs). Adding that incidentally also gives us a diagnostic quality improvement. This has also exposed an pre-existing problem: making the exception specification evaluation context a non-SFINAE context (as it should be) results in a bootstrap failure; PR38850 filed for this. llvm-svn: 341499
2018-09-06 06:30:37 +08:00
case CodeSynthesisContext::ExceptionSpecEvaluation:
// FIXME: This should not be treated as a SFINAE context, because
// we will cache an incorrect exception specification. However, clang
// bootstrap relies this! See PR31692.
break;
[Templight] Template Instantiation Observer This patch adds a base-class called TemplateInstantiationObserver which gets notified whenever a template instantiation is entered or exited during semantic analysis. This is a base class used to implement the template profiling and debugging tool called Templight (https://github.com/mikael-s-persson/templight). The patch also makes a few more changes: * ActiveTemplateInstantiation class is moved out of the Sema class (so it can be used with inclusion of Sema.h). * CreateFrontendAction function in front-end utilities is given external linkage (not longer a hidden static function). * TemplateInstObserverChain data member added to Sema class to hold the list of template-inst observers. * Notifications to the template-inst observer are added at the key places where templates are instantiated. Patch by: Abel Sinkovics! Differential Revision: https://reviews.llvm.org/D5767 llvm-svn: 324808
2018-02-10 22:04:45 +08:00
case CodeSynthesisContext::Memoization:
break;
Update LLVM. Implement support for C++ Substitution Failure Is Not An Error (SFINAE), which says that errors that occur during template argument deduction do *not* produce diagnostics and do not necessarily make a program ill-formed. Instead, template argument deduction silently fails. This is currently implemented for template argument deduction during matching of class template partial specializations, although the mechanism will also apply to template argument deduction for function templates. The scheme is simple: - If we are in a template argument deduction context, any diagnostic that is considered a SFINAE error (or warning) will be suppressed. The error will be propagated up the call stack via the normal means. - By default, all warnings and errors are SFINAE errors. Add the NoSFINAE class to a diagnostic in the .td file to make it a hard error (e.g., for access-control violations). Note that, to make this fully work, every place in Sema that emits an error *and then immediately recovers* will need to check Sema::isSFINAEContext() to determine whether it must immediately return an error rather than recovering. llvm-svn: 73332
2009-06-14 15:33:30 +08:00
}
Add context note to diagnostics that occur while declaring an implicit special member function. llvm-svn: 296020
2017-02-24 05:43:43 +08:00
// The inner context was transparent for SFINAE. If it occurred within a
// non-instantiation SFINAE context, then SFINAE applies.
if (Active->SavedInNonInstantiationSFINAEContext)
return Optional<TemplateDeductionInfo *>(nullptr);
Update LLVM. Implement support for C++ Substitution Failure Is Not An Error (SFINAE), which says that errors that occur during template argument deduction do *not* produce diagnostics and do not necessarily make a program ill-formed. Instead, template argument deduction silently fails. This is currently implemented for template argument deduction during matching of class template partial specializations, although the mechanism will also apply to template argument deduction for function templates. The scheme is simple: - If we are in a template argument deduction context, any diagnostic that is considered a SFINAE error (or warning) will be suppressed. The error will be propagated up the call stack via the normal means. - By default, all warnings and errors are SFINAE errors. Add the NoSFINAE class to a diagnostic in the .td file to make it a hard error (e.g., for access-control violations). Note that, to make this fully work, every place in Sema that emits an error *and then immediately recovers* will need to check Sema::isSFINAEContext() to determine whether it must immediately return an error rather than recovering. llvm-svn: 73332
2009-06-14 15:33:30 +08:00
}
Use None rather than Optional<T>() where possible. llvm-svn: 175705
2013-02-21 09:47:18 +08:00
return None;
Update LLVM. Implement support for C++ Substitution Failure Is Not An Error (SFINAE), which says that errors that occur during template argument deduction do *not* produce diagnostics and do not necessarily make a program ill-formed. Instead, template argument deduction silently fails. This is currently implemented for template argument deduction during matching of class template partial specializations, although the mechanism will also apply to template argument deduction for function templates. The scheme is simple: - If we are in a template argument deduction context, any diagnostic that is considered a SFINAE error (or warning) will be suppressed. The error will be propagated up the call stack via the normal means. - By default, all warnings and errors are SFINAE errors. Add the NoSFINAE class to a diagnostic in the .td file to make it a hard error (e.g., for access-control violations). Note that, to make this fully work, every place in Sema that emits an error *and then immediately recovers* will need to check Sema::isSFINAEContext() to determine whether it must immediately return an error rather than recovering. llvm-svn: 73332
2009-06-14 15:33:30 +08:00
}
Implement the basic approach for instantiating types, with a lot of FIXME'd stubs for those types we don't yet know how to instantiate (everything that isn't a template parameter!). We now instantiate default arguments for template type parameters when needed. This will be our testbed while I fill out the remaining type-instantiation logic. llvm-svn: 65649
2009-02-28 03:31:52 +08:00
//===----------------------------------------------------------------------===/
// Template Instantiation for Types
//===----------------------------------------------------------------------===/
Implement template instantiation for pointer, reference, and (some) array types. Semantic checking for the construction of these types has been factored out of GetTypeForDeclarator and into separate subroutines (BuildPointerType, BuildReferenceType, BuildArrayType). We'll be doing the same thing for all other types (and declarations and expressions). As part of this, moved the type-instantiation functions into a class in an anonymous namespace. llvm-svn: 65663
2009-02-28 08:25:32 +08:00
namespace {
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
class TemplateInstantiator : public TreeTransform<TemplateInstantiator> {
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;
Implement template instantiation for pointer, reference, and (some) array types. Semantic checking for the construction of these types has been factored out of GetTypeForDeclarator and into separate subroutines (BuildPointerType, BuildReferenceType, BuildArrayType). We'll be doing the same thing for all other types (and declarations and expressions). As part of this, moved the type-instantiation functions into a class in an anonymous namespace. llvm-svn: 65663
2009-02-28 08:25:32 +08:00
SourceLocation Loc;
DeclarationName Entity;
public:
Refactor the instantiation of statements into a generic tree transformation. llvm-svn: 79519
2009-08-20 15:17:43 +08:00
typedef TreeTransform<TemplateInstantiator> inherited;
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
TemplateInstantiator(Sema &SemaRef,
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,
Refactor template instantiation for types into a generic tree transformation template (TreeTransform) that handles the transformation and reconstruction of AST nodes. Template instantiation for types is a (relatively small) customization of the generic tree transformation. llvm-svn: 78071
2009-08-05 00:50:30 +08:00
SourceLocation Loc,
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
DeclarationName Entity)
: inherited(SemaRef), TemplateArgs(TemplateArgs), Loc(Loc),
Refactor the instantiation of statements into a generic tree transformation. llvm-svn: 79519
2009-08-20 15:17:43 +08:00
Entity(Entity) { }
Refactor template instantiation for types into a generic tree transformation template (TreeTransform) that handles the transformation and reconstruction of AST nodes. Template instantiation for types is a (relatively small) customization of the generic tree transformation. llvm-svn: 78071
2009-08-05 00:50:30 +08:00
Remove \brief commands from doxygen comments. This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
2018-05-09 09:00:01 +08:00
/// Determine whether the given type \p T has already been
Refactor template instantiation for types into a generic tree transformation template (TreeTransform) that handles the transformation and reconstruction of AST nodes. Template instantiation for types is a (relatively small) customization of the generic tree transformation. llvm-svn: 78071
2009-08-05 00:50:30 +08:00
/// transformed.
///
/// For the purposes of template instantiation, a type has already been
/// transformed if it is NULL or if it is not dependent.
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
bool AlreadyTransformed(QualType T);
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Remove \brief commands from doxygen comments. This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
2018-05-09 09:00:01 +08:00
/// Returns the location of the entity being instantiated, if known.
Refactor template instantiation for types into a generic tree transformation template (TreeTransform) that handles the transformation and reconstruction of AST nodes. Template instantiation for types is a (relatively small) customization of the generic tree transformation. llvm-svn: 78071
2009-08-05 00:50:30 +08:00
SourceLocation getBaseLocation() { return Loc; }
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Remove \brief commands from doxygen comments. This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
2018-05-09 09:00:01 +08:00
/// Returns the name of the entity being instantiated, if any.
Refactor template instantiation for types into a generic tree transformation template (TreeTransform) that handles the transformation and reconstruction of AST nodes. Template instantiation for types is a (relatively small) customization of the generic tree transformation. llvm-svn: 78071
2009-08-05 00:50:30 +08:00
DeclarationName getBaseEntity() { return Entity; }
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Remove \brief commands from doxygen comments. This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
2018-05-09 09:00:01 +08:00
/// Sets the "base" location and entity when that
Only set the point of instantiation for an implicit or explicit instantiation once we have committed to performing the instantiation. As part of this, make our makeshift template-instantiation location information suck slightly less. Fixes PR5264. llvm-svn: 85209
2009-10-27 14:26:26 +08:00
/// information is known based on another transformation.
void setBase(SourceLocation Loc, DeclarationName Entity) {
this->Loc = Loc;
this->Entity = Entity;
}
Implement basic support for template instantiation of pack expansions whose patterns are template arguments. We can now instantiate, e.g., typedef tuple<pair<OuterTypes, InnerTypes>...> type; where OuterTypes and InnerTypes are template type parameter packs. There is a horrible inefficiency in TemplateArgumentLoc::getPackExpansionPattern(), where we need to create copies of TypeLoc data because our interfaces traffic in TypeSourceInfo pointers where they should traffic in TypeLocs instead. I've isolated in efficiency in this one routine; once we refactor our interfaces to traffic in TypeLocs, we can eliminate it. llvm-svn: 122278
2010-12-21 06:05:00 +08:00
PR45083: Mark statement expressions as being dependent if they appear in a dependent context. This matches the GCC behavior. We track the enclosing template depth when determining whether a statement expression is within a dependent context; there doesn't appear to be any other reliable way to determine this. We previously assumed they were neither value- nor instantiation-dependent under any circumstances, which would lead to crashes and other misbehavior.
2020-03-10 08:34:33 +08:00
unsigned TransformTemplateDepth(unsigned Depth) {
return TemplateArgs.getNewDepth(Depth);
}
Implement basic support for template instantiation of pack expansions whose patterns are template arguments. We can now instantiate, e.g., typedef tuple<pair<OuterTypes, InnerTypes>...> type; where OuterTypes and InnerTypes are template type parameter packs. There is a horrible inefficiency in TemplateArgumentLoc::getPackExpansionPattern(), where we need to create copies of TypeLoc data because our interfaces traffic in TypeSourceInfo pointers where they should traffic in TypeLocs instead. I've isolated in efficiency in this one routine; once we refactor our interfaces to traffic in TypeLocs, we can eliminate it. llvm-svn: 122278
2010-12-21 06:05:00 +08:00
bool TryExpandParameterPacks(SourceLocation EllipsisLoc,
SourceRange PatternRange,
Omit llvm:: before ArrayRef, as we have using llvm::ArrayRef in include/clang/Basic/LLVM.h. llvm-svn: 188089
2013-08-10 02:02:13 +08:00
ArrayRef<UnexpandedParameterPack> Unexpanded,
bool &ShouldExpand, bool &RetainExpansion,
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) {
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
return getSema().CheckParameterPacksForExpansion(EllipsisLoc,
Implement instantiation of pack expansions whose pattern is a type-id in an exception specification. llvm-svn: 122297
2010-12-21 08:52:54 +08:00
PatternRange, Unexpanded,
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
TemplateArgs,
Implement instantiation of pack expansions whose pattern is a type-id in an exception specification. llvm-svn: 122297
2010-12-21 08:52:54 +08:00
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 instantiation of pack expansions whose pattern is a type-id in an exception specification. llvm-svn: 122297
2010-12-21 08:52:54 +08:00
NumExpansions);
}
Implement basic support for template instantiation of pack expansions whose patterns are template arguments. We can now instantiate, e.g., typedef tuple<pair<OuterTypes, InnerTypes>...> type; where OuterTypes and InnerTypes are template type parameter packs. There is a horrible inefficiency in TemplateArgumentLoc::getPackExpansionPattern(), where we need to create copies of TypeLoc data because our interfaces traffic in TypeSourceInfo pointers where they should traffic in TypeLocs instead. I've isolated in efficiency in this one routine; once we refactor our interfaces to traffic in TypeLocs, we can eliminate it. llvm-svn: 122278
2010-12-21 06:05:00 +08:00
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
void ExpandingFunctionParameterPack(ParmVarDecl *Pack) {
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
SemaRef.CurrentInstantiationScope->MakeInstantiatedLocalArgPack(Pack);
}
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
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
TemplateArgument ForgetPartiallySubstitutedPack() {
TemplateArgument Result;
if (NamedDecl *PartialPack
= SemaRef.CurrentInstantiationScope->getPartiallySubstitutedPack()){
MultiLevelTemplateArgumentList &TemplateArgs
= const_cast<MultiLevelTemplateArgumentList &>(this->TemplateArgs);
unsigned Depth, Index;
[C++11] Replace llvm::tie with std::tie. llvm-svn: 202639
2014-03-02 21:01:17 +08:00
std::tie(Depth, Index) = getDepthAndIndex(PartialPack);
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
if (TemplateArgs.hasTemplateArgument(Depth, Index)) {
Result = TemplateArgs(Depth, Index);
TemplateArgs.setArgument(Depth, Index, TemplateArgument());
}
}
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
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
return Result;
}
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
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
void RememberPartiallySubstitutedPack(TemplateArgument Arg) {
if (Arg.isNull())
return;
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
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
if (NamedDecl *PartialPack
= SemaRef.CurrentInstantiationScope->getPartiallySubstitutedPack()){
MultiLevelTemplateArgumentList &TemplateArgs
= const_cast<MultiLevelTemplateArgumentList &>(this->TemplateArgs);
unsigned Depth, Index;
[C++11] Replace llvm::tie with std::tie. llvm-svn: 202639
2014-03-02 21:01:17 +08:00
std::tie(Depth, Index) = getDepthAndIndex(PartialPack);
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
TemplateArgs.setArgument(Depth, Index, Arg);
}
}
Remove \brief commands from doxygen comments. This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
2018-05-09 09:00:01 +08:00
/// Transform the given declaration by instantiating a reference to
Refactor template instantiation for types into a generic tree transformation template (TreeTransform) that handles the transformation and reconstruction of AST nodes. Template instantiation for types is a (relatively small) customization of the generic tree transformation. llvm-svn: 78071
2009-08-05 00:50:30 +08:00
/// this declaration.
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 *TransformDecl(SourceLocation Loc, Decl *D);
Refactor the template-instantiation logic for expressions into a generic tree transformation (also used for recanonicalization) and a small amount of template-instantiation-specific logic. llvm-svn: 78645
2009-08-11 13:31:07 +08:00
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
void transformAttrs(Decl *Old, Decl *New) {
Introduce support for template instantiation of lambda expressions. This is mostly a simple refact, splitting the main "start a lambda expression" function into smaller chunks that are driven either from the parser (Sema::ActOnLambdaExpr) or during AST transformation (TreeTransform::TransformLambdaExpr). A few minor interesting points: - Added new entry points for TreeTransform, so that we can explicitly establish the link between the lambda closure type in the template and the lambda closure type in the instantiation. - Added a bit into LambdaExpr specifying whether it had an explicit result type or not. We should have had this anyway. This code is 'lightly' tested. llvm-svn: 150417
2012-02-14 06:00:16 +08:00
SemaRef.InstantiateAttrs(TemplateArgs, Old, New);
}
[c++20] P0780R2: Support pack-expansion of init-captures. This permits an init-capture to introduce a new pack: template<typename ...T> auto x = [...a = T()] { /* a is a pack */ }; To support this, the mechanism for allowing ParmVarDecls to be packs has been extended to support arbitrary local VarDecls. llvm-svn: 361300
2019-05-22 04:10:50 +08:00
void transformedLocalDecl(Decl *Old, ArrayRef<Decl *> NewDecls) {
if (Old->isParameterPack()) {
SemaRef.CurrentInstantiationScope->MakeInstantiatedLocalArgPack(Old);
for (auto *New : NewDecls)
SemaRef.CurrentInstantiationScope->InstantiatedLocalPackArg(
Old, cast<VarDecl>(New));
return;
}
assert(NewDecls.size() == 1 &&
"should only have multiple expansions for a pack");
Decl *New = NewDecls.front();
PR23334: Perform semantic checking of lambda capture initialization in the right context. Previously we'd try to perform checks on the captures from the middle of parsing the lambda's body, at the point where we detected that a variable needed to be captured. This was wrong in a number of subtle ways. In PR23334, we couldn't correctly handle the list of potential odr-uses resulting from the capture, and our attempt to recover from that resulted in a use-after-free. We now defer building the initialization expression until we leave the lambda body and return to the enclosing context, where the initialization does the right thing. This patch only covers lambda-expressions, but we should apply the same change to blocks and captured statements too. llvm-svn: 235921
2015-04-28 05:27:54 +08:00
// If we've instantiated the call operator of a lambda or the call
// operator template of a generic lambda, update the "instantiation of"
// information.
auto *NewMD = dyn_cast<CXXMethodDecl>(New);
if (NewMD && isLambdaCallOperator(NewMD)) {
auto *OldMD = dyn_cast<CXXMethodDecl>(Old);
if (auto *NewTD = NewMD->getDescribedFunctionTemplate())
NewTD->setInstantiatedFromMemberTemplate(
OldMD->getDescribedFunctionTemplate());
else
NewMD->setInstantiationOfMemberFunction(OldMD,
TSK_ImplicitInstantiation);
}
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
Introduce support for template instantiation of lambda expressions. This is mostly a simple refact, splitting the main "start a lambda expression" function into smaller chunks that are driven either from the parser (Sema::ActOnLambdaExpr) or during AST transformation (TreeTransform::TransformLambdaExpr). A few minor interesting points: - Added new entry points for TreeTransform, so that we can explicitly establish the link between the lambda closure type in the template and the lambda closure type in the instantiation. - Added a bit into LambdaExpr specifying whether it had an explicit result type or not. We should have had this anyway. This code is 'lightly' tested. llvm-svn: 150417
2012-02-14 06:00:16 +08:00
SemaRef.CurrentInstantiationScope->InstantiatedLocal(Old, New);
Make sure to perform dependent access checks when instantiating a lambda-expression. We don't actually instantiate the closure type / operator() in the template in order to produce the closure type / operator() in the instantiation, so this isn't caught by the normal path. llvm-svn: 264184
2016-03-24 04:07:07 +08:00
// We recreated a local declaration, but not by instantiating it. There
// may be pending dependent diagnostics to produce.
if (auto *DC = dyn_cast<DeclContext>(Old))
SemaRef.PerformDependentDiagnostics(DC, TemplateArgs);
Introduce support for template instantiation of lambda expressions. This is mostly a simple refact, splitting the main "start a lambda expression" function into smaller chunks that are driven either from the parser (Sema::ActOnLambdaExpr) or during AST transformation (TreeTransform::TransformLambdaExpr). A few minor interesting points: - Added new entry points for TreeTransform, so that we can explicitly establish the link between the lambda closure type in the template and the lambda closure type in the instantiation. - Added a bit into LambdaExpr specifying whether it had an explicit result type or not. We should have had this anyway. This code is 'lightly' tested. llvm-svn: 150417
2012-02-14 06:00:16 +08:00
}
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
Remove \brief commands from doxygen comments. This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
2018-05-09 09:00:01 +08:00
/// Transform the definition of the given declaration by
Refactor the instantiation of statements into a generic tree transformation. llvm-svn: 79519
2009-08-20 15:17:43 +08:00
/// instantiating it.
Finish pushing source-location information though TreeTransform's TransformDefinition. llvm-svn: 97445
2010-03-02 01:25:41 +08:00
Decl *TransformDefinition(SourceLocation Loc, Decl *D);
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Remove \brief commands from doxygen comments. This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
2018-05-09 09:00:01 +08:00
/// Transform the first qualifier within a scope by instantiating the
Handle substitutions into the "first qualifier in scope" of a qualified member access expression (e.g., t->U::member) when that first qualifier refers to a template parameters. llvm-svn: 84612
2009-10-20 13:58:46 +08:00
/// declaration.
NamedDecl *TransformFirstQualifierInScope(NamedDecl *D, SourceLocation Loc);
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
Remove \brief commands from doxygen comments. This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
2018-05-09 09:00:01 +08:00
/// Rebuild the exception declaration and register the declaration
Refactor the instantiation of statements into a generic tree transformation. llvm-svn: 79519
2009-08-20 15:17:43 +08:00
/// as an instantiated local.
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
VarDecl *RebuildExceptionDecl(VarDecl *ExceptionDecl,
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 *Declarator,
Fixed source range for all DeclaratorDecl's. llvm-svn: 127225
2011-03-08 16:55:46 +08:00
SourceLocation StartLoc,
SourceLocation NameLoc,
IdentifierInfo *Name);
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
/// Rebuild the Objective-C exception declaration and register the
Implement template instantiation for Objective-C @catch statements. This is the last of the Objective-C statements. llvm-svn: 102356
2010-04-27 01:57:08 +08:00
/// declaration as an instantiated local.
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
VarDecl *RebuildObjCExceptionDecl(VarDecl *ExceptionDecl,
Implement template instantiation for Objective-C @catch statements. This is the last of the Objective-C statements. llvm-svn: 102356
2010-04-27 01:57:08 +08:00
TypeSourceInfo *TSInfo, QualType T);
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
Remove \brief commands from doxygen comments. This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
2018-05-09 09:00:01 +08:00
/// Check for tag mismatches when instantiating an
Support elaborated dependent types and diagnose tag mismatches. llvm-svn: 81504
2009-09-11 12:59:25 +08:00
/// elaborated type.
Use the real keyword location when rebuilding an elaborated type instead of making something up. Fixes PR8129. llvm-svn: 118258
2010-11-05 03:04:38 +08:00
QualType RebuildElaboratedType(SourceLocation KeywordLoc,
ElaboratedTypeKeyword Keyword,
Reinstate the introduction of source-location information for nested-name-speciciers within elaborated type names, e.g., enum clang::NestedNameSpecifier::SpecifierKind Fixes in this iteration include: (1) Compute the type-source range properly for a dependent template specialization type that starts with "template template-id ::", as in a member access expression dep->template f<T>::f() This is a latent bug I triggered with this change (because now we're checking the computed source ranges for dependent template specialization types). But the real problem was... (2) Make sure to set the qualifier range on a dependent template specialization type appropriately. This will go away once we push nested-name-specifier locations into dependent template specialization types, but it was the source of the valgrind errors on the buildbots. llvm-svn: 126765
2011-03-02 02:12:44 +08:00
NestedNameSpecifierLoc QualifierLoc,
QualType T);
Support elaborated dependent types and diagnose tag mismatches. llvm-svn: 81504
2009-09-11 12:59:25 +08:00
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
TemplateName
TransformTemplateName(CXXScopeSpec &SS, TemplateName Name,
SourceLocation NameLoc,
QualType ObjectType = QualType(),
Finish implementation of C++ DR1310 (http://wg21.link/cwg1310). Diagnose the case when a dependent template name instantiates to an injected-class-name outside a nested-name-specifier. llvm-svn: 292545
2017-01-20 08:20:39 +08:00
NamedDecl *FirstQualifierInScope = nullptr,
bool AllowInjectedClassName = false);
Start migrating TreeTransform's TransformTemplateName over to version that preserve source-location information. This commit adds more redundancy than it removes; WIP. llvm-svn: 126849
2011-03-03 02:07:45 +08:00
Allow constant expressions in pragma loop hints. Previously loop hints such as #pragma loop vectorize_width(#) required a constant. This patch allows a constant expression to be used as well. Such as a non-type template parameter or an expression (2 * c + 1). Reviewed by Richard Smith llvm-svn: 219589
2014-10-13 04:46:07 +08:00
const LoopHintAttr *TransformLoopHintAttr(const LoopHintAttr *LH);
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 TransformPredefinedExpr(PredefinedExpr *E);
ExprResult TransformDeclRefExpr(DeclRefExpr *E);
ExprResult TransformCXXDefaultArgExpr(CXXDefaultArgExpr *E);
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
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 TransformTemplateParmRefExpr(DeclRefExpr *E,
When instantiating a non-type template parameter pack, be sure to extract the appropriate argument from the argument pack (based on the current substitution index, of course). Simple instantiation of pack expansions involving non-type template parameter packs now works. llvm-svn: 122532
2010-12-24 08:15:10 +08:00
NonTypeTemplateParmDecl *D);
Introduce a new expression kind, SubstNonTypeTemplateParmPackExpr, that captures the substitution of a non-type template argument pack for a non-type template parameter pack within a pack expansion that cannot be fully expanded. This follows the approach taken by SubstTemplateTypeParmPackType. llvm-svn: 123506
2011-01-15 09:15:58 +08:00
ExprResult TransformSubstNonTypeTemplateParmPackExpr(
SubstNonTypeTemplateParmPackExpr *E);
[Concepts] Correctly form initial parameter mapping for parameter packs, support substitution into SubstNonTypeTemplateParmExpr We previously would not correctly for the initial parameter mapping for variadic template parameters in Concepts. Testing this lead to the discovery that with the normalization process we would need to substitute into already-substituted-into template arguments, which means we need to add NonTypeTemplateParmExpr support to TemplateInstantiator. We do that by substituting into the replacement and the type separately, and then re-checking the expression against the NTTP with the new type, in order to form any new required implicit casts (for cases where the type of the NTTP was dependent).
2020-01-31 21:55:06 +08:00
ExprResult TransformSubstNonTypeTemplateParmExpr(
SubstNonTypeTemplateParmExpr *E);
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
[c++20] P0780R2: Support pack-expansion of init-captures. This permits an init-capture to introduce a new pack: template<typename ...T> auto x = [...a = T()] { /* a is a pack */ }; To support this, the mechanism for allowing ParmVarDecls to be packs has been extended to support arbitrary local VarDecls. llvm-svn: 361300
2019-05-22 04:10:50 +08:00
/// Rebuild a DeclRefExpr for a VarDecl reference.
ExprResult RebuildVarDeclRefExpr(VarDecl *PD, SourceLocation Loc);
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
[c++20] P0780R2: Support pack-expansion of init-captures. This permits an init-capture to introduce a new pack: template<typename ...T> auto x = [...a = T()] { /* a is a pack */ }; To support this, the mechanism for allowing ParmVarDecls to be packs has been extended to support arbitrary local VarDecls. llvm-svn: 361300
2019-05-22 04:10:50 +08:00
/// Transform a reference to a function or init-capture parameter pack.
ExprResult TransformFunctionParmPackRefExpr(DeclRefExpr *E, VarDecl *PD);
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
Remove \brief commands from doxygen comments. This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
2018-05-09 09:00:01 +08:00
/// Transform a FunctionParmPackExpr which was built when we couldn't
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
/// expand a function parameter pack reference which refers to an expanded
/// pack.
ExprResult TransformFunctionParmPackExpr(FunctionParmPackExpr *E);
Revert r217995 and follow-ups: r218053: Use exceptions() instead of getNumExceptions()/getExceptionType() to avoid r218011: Work around MSVC parser bug by putting redundant braces around the body of r217997: Skip parens when detecting whether we're instantiating a function declaration. r217995: Instantiate exception specifications when instantiating function types (other The Windows build was broken for 16 hours and no one had any good ideas of how to fix it. Reverting for now to make the builders green. See the cfe-commits thread [1] for more info. This was the build error (from [2]): C:\bb-win7\ninja-clang-i686-msc17-R\llvm-project\clang\lib\Sema\SemaTemplateInstantiate.cpp(1590) : error C2668: '`anonymous-namespace'::TemplateInstantiator::TransformFunctionProtoType' : ambiguous call to overloaded function C:\bb-win7\ninja-clang-i686-msc17-R\llvm-project\clang\lib\Sema\SemaTemplateInstantiate.cpp(1313): could be 'clang::QualType `anonymous-namespace'::TemplateInstantiator::TransformFunctionProtoType<clang::Sema::SubstFunctionDeclType::<lambda_756edcbe7bd5c7584849a6e3a1491735>>(clang::TypeLocBuilder &,clang::FunctionProtoTypeLoc,clang::CXXRecordDecl *,unsigned int,Fn)' with [ Fn=clang::Sema::SubstFunctionDeclType::<lambda_756edcbe7bd5c7584849a6e3a1491735> ] c:\bb-win7\ninja-clang-i686-msc17-r\llvm-project\clang\lib\sema\TreeTransform.h(4532): or 'clang::QualType clang::TreeTransform<Derived>::TransformFunctionProtoType<clang::Sema::SubstFunctionDeclType::<lambda_756edcbe7bd5c7584849a6e3a1491735>>(clang::TypeLocBuilder &,clang::FunctionProtoTypeLoc,clang::CXXRecordDecl *,unsigned int,Fn)' with [ Derived=`anonymous-namespace'::TemplateInstantiator, Fn=clang::Sema::SubstFunctionDeclType::<lambda_756edcbe7bd5c7584849a6e3a1491735> ] while trying to match the argument list '(clang::TypeLocBuilder, clang::FunctionProtoTypeLoc, clang::CXXRecordDecl *, unsigned int, clang::Sema::SubstFunctionDeclType::<lambda_756edcbe7bd5c7584849a6e3a1491735>)' 1. http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140915/115011.html 2. http://bb.pgr.jp/builders/ninja-clang-i686-msc17-R/builds/10515/steps/build_clang_tools_1/logs/stdio llvm-svn: 218058
2014-09-19 00:01:32 +08:00
QualType TransformFunctionProtoType(TypeLocBuilder &TLB,
Instantiate exception specifications when instantiating function types (other than the type of a function declaration). We previously didn't instantiate these at all! This also covers the pathological case where the only mention of a parameter pack is within the exception specification; this gives us a second way (other than alias templates) to reach the horrible state where a type contains an unexpanded pack, but its canonical type does not. This is a re-commit of r219977: r219977 was reverted in r220038 because it hit a wrong-code bug in GCC 4.7.2. (That's gcc.gnu.org/PR56135, and affects any implicit lambda-capture of 'this' within a template.) r219977 was a re-commit of r217995, r218011, and r218053: r217995 was reverted in r218058 because it hit a rejects-valid bug in MSVC. (Incorrect overload resolution in the presence of using-declarations.) It was re-committed in r219977 with a workaround for the MSVC rejects-valid. r218011 was a workaround for an MSVC parser bug. (Incorrect desugaring of unbraced range-based for loop). llvm-svn: 221750
2014-11-12 10:00:47 +08:00
FunctionProtoTypeLoc TL) {
// Call the base version; it will forward to our overridden version below.
return inherited::TransformFunctionProtoType(TLB, TL);
}
template<typename Fn>
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
QualType TransformFunctionProtoType(TypeLocBuilder &TLB,
FunctionProtoTypeLoc TL,
CXXRecordDecl *ThisContext,
[OpenCL] Add generic AS to 'this' pointer Address spaces are cast into generic before invoking the constructor. Added support for a trailing Qualifiers object in FunctionProtoType. Note: This recommits the previously reverted patch, but now it is commited together with a fix for lldb. Differential Revision: https://reviews.llvm.org/D54862 llvm-svn: 349019
2018-12-13 18:15:27 +08:00
Qualifiers ThisTypeQuals,
Instantiate exception specifications when instantiating function types (other than the type of a function declaration). We previously didn't instantiate these at all! This also covers the pathological case where the only mention of a parameter pack is within the exception specification; this gives us a second way (other than alias templates) to reach the horrible state where a type contains an unexpanded pack, but its canonical type does not. This is a re-commit of r219977: r219977 was reverted in r220038 because it hit a wrong-code bug in GCC 4.7.2. (That's gcc.gnu.org/PR56135, and affects any implicit lambda-capture of 'this' within a template.) r219977 was a re-commit of r217995, r218011, and r218053: r217995 was reverted in r218058 because it hit a rejects-valid bug in MSVC. (Incorrect overload resolution in the presence of using-declarations.) It was re-committed in r219977 with a workaround for the MSVC rejects-valid. r218011 was a workaround for an MSVC parser bug. (Incorrect desugaring of unbraced range-based for loop). llvm-svn: 221750
2014-11-12 10:00:47 +08:00
Fn TransformExceptionSpec);
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
Handle substitutions into function parameter packs whose patterns contain multiple parameter packs at different levels. llvm-svn: 123488
2011-01-15 06:40:04 +08:00
ParmVarDecl *TransformFunctionTypeParam(ParmVarDecl *OldParm,
Store a parameter index and function prototype depth in every parameter node and use this to correctly mangle parameter references in function template signatures. A follow-up patch will improve the storage usage of these fields; here I've just done the lazy thing. llvm-svn: 130669
2011-05-02 06:35:37 +08:00
int indexAdjustment,
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,
When we're substituting into a function parameter pack and expect to get a function parameter pack (but don't due to weird substitutions), complain. Fixes the last bit of PR11848. llvm-svn: 148960
2012-01-26 00:15:54 +08:00
bool ExpectParameterPack);
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
Remove \brief commands from doxygen comments. This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
2018-05-09 09:00:01 +08:00
/// Transforms a template type parameter type by performing
Refactor template instantiation for types into a generic tree transformation template (TreeTransform) that handles the transformation and reconstruction of AST nodes. Template instantiation for types is a (relatively small) customization of the generic tree transformation. llvm-svn: 78071
2009-08-05 00:50:30 +08:00
/// substitution of the corresponding template type argument.
Rewrite TreeTransform to transform types as DeclaratorInfos rather than as bare QualTypes. Don't actually exploit this yet. llvm-svn: 84716
2009-10-21 08:40:46 +08:00
QualType TransformTemplateTypeParmType(TypeLocBuilder &TLB,
Replace one hack with a different hack: strip out the ObjectType parameters to the Transform*Type functions and instead call out the specific cases where an object type and the unqualified lookup results are important. Fixes an assert and failed compile on a testcase from PR7248. llvm-svn: 118887
2010-11-12 16:19:04 +08:00
TemplateTypeParmTypeLoc TL);
Fix multiple emission of the this-> fixit for each instantiation by fixing the AST during the instantiation. Fixes PR7417! llvm-svn: 107690
2010-07-07 03:51:49 +08:00
Remove \brief commands from doxygen comments. This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
2018-05-09 09:00:01 +08:00
/// Transforms an already-substituted template type parameter pack
Start implementing support for substitution into pack expansions that involve template parameter packs at multiple template levels that occur within the signatures members of class templates (and partial specializations thereof). This is a work-in-progress that is deficient in several ways, notably: - It only works for template type parameter packs, but we need to also support non-type template parameter packs and template template parameter packs. - It doesn't keep track of the lengths of the substituted argument packs in the expansion, so it can't properly diagnose length mismatches. However, this is a concrete step in the right direction. llvm-svn: 123425
2011-01-14 10:55:32 +08:00
/// into either itself (if we aren't substituting into its pack expansion)
/// or the appropriate substituted argument.
QualType TransformSubstTemplateTypeParmPackType(TypeLocBuilder &TLB,
SubstTemplateTypeParmPackTypeLoc TL);
PR12057: Allow variadic template pack expansions to cross lambda boundaries. Rather than adding a ContainsUnexpandedParameterPack bit to essentially every AST node, we tunnel the bit directly up to the surrounding lambda expression when we reach a context where an unexpanded pack can not normally appear. Thus any statement or declaration within a lambda can now potentially contain an unexpanded parameter pack. llvm-svn: 160705
2012-07-25 11:56:55 +08:00
ExprResult TransformLambdaExpr(LambdaExpr *E) {
LocalInstantiationScope Scope(SemaRef, /*CombineWithOuterScope=*/true);
return TreeTransform<TemplateInstantiator>::TransformLambdaExpr(E);
}
[Concepts] Requires Expressions Implement support for C++2a requires-expressions. Re-commit after compilation failure on some platforms due to alignment issues with PointerIntPair. Differential Revision: https://reviews.llvm.org/D50360
2020-01-18 15:11:43 +08:00
ExprResult TransformRequiresExpr(RequiresExpr *E) {
LocalInstantiationScope Scope(SemaRef, /*CombineWithOuterScope=*/true);
return TreeTransform<TemplateInstantiator>::TransformRequiresExpr(E);
}
bool TransformRequiresExprRequirements(
ArrayRef<concepts::Requirement *> Reqs,
SmallVectorImpl<concepts::Requirement *> &Transformed) {
bool SatisfactionDetermined = false;
for (concepts::Requirement *Req : Reqs) {
concepts::Requirement *TransReq = nullptr;
if (!SatisfactionDetermined) {
if (auto *TypeReq = dyn_cast<concepts::TypeRequirement>(Req))
TransReq = TransformTypeRequirement(TypeReq);
else if (auto *ExprReq = dyn_cast<concepts::ExprRequirement>(Req))
TransReq = TransformExprRequirement(ExprReq);
else
TransReq = TransformNestedRequirement(
cast<concepts::NestedRequirement>(Req));
if (!TransReq)
return true;
if (!TransReq->isDependent() && !TransReq->isSatisfied())
// [expr.prim.req]p6
// [...] The substitution and semantic constraint checking
// proceeds in lexical order and stops when a condition that
// determines the result of the requires-expression is
// encountered. [..]
SatisfactionDetermined = true;
} else
TransReq = Req;
Transformed.push_back(TransReq);
}
return false;
}
Normalize line endings Some files had CRLF line terminators, some only had a mixture of CRLF and LF. Switch to LF. llvm-svn: 202659
2014-03-03 02:46:05 +08:00
TemplateParameterList *TransformTemplateParameterList(
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
TemplateParameterList *OrigTPL) {
if (!OrigTPL || !OrigTPL->size()) return OrigTPL;
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
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
DeclContext *Owner = OrigTPL->getParam(0)->getDeclContext();
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
TemplateDeclInstantiator DeclInstantiator(getSema(),
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
/* DeclContext *Owner */ Owner, TemplateArgs);
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
return DeclInstantiator.SubstTemplateParams(OrigTPL);
PR12057: Allow variadic template pack expansions to cross lambda boundaries. Rather than adding a ContainsUnexpandedParameterPack bit to essentially every AST node, we tunnel the bit directly up to the surrounding lambda expression when we reach a context where an unexpanded pack can not normally appear. Thus any statement or declaration within a lambda can now potentially contain an unexpanded parameter pack. llvm-svn: 160705
2012-07-25 11:56:55 +08:00
}
[Concepts] Requires Expressions Implement support for C++2a requires-expressions. Re-commit after compilation failure on some platforms due to alignment issues with PointerIntPair. Differential Revision: https://reviews.llvm.org/D50360
2020-01-18 15:11:43 +08:00
concepts::TypeRequirement *
TransformTypeRequirement(concepts::TypeRequirement *Req);
concepts::ExprRequirement *
TransformExprRequirement(concepts::ExprRequirement *Req);
concepts::NestedRequirement *
TransformNestedRequirement(concepts::NestedRequirement *Req);
Create a new expression node, SubstNonTypeTemplateParmExpr, to represent a fully-substituted non-type template parameter. This should improve source fidelity, as well as being generically useful for diagnostics and such. llvm-svn: 135243
2011-07-15 13:09:51 +08:00
private:
ExprResult transformNonTypeTemplateParmRef(NonTypeTemplateParmDecl *parm,
SourceLocation loc,
PR13136: * When substituting a reference to a non-type template parameter pack where the corresponding argument is a pack expansion, transform into an expression which contains an unexpanded parameter pack rather than into an expression which contains a pack expansion. This causes the SubstNonTypeTemplateParmExpr to be inside the PackExpansionExpr, rather than outside, so the expression still looks like a pack expansion and can be deduced. * Teach MarkUsedTemplateParameters that we can deduce a reference to a template parameter if it's wrapped in a SubstNonTypeTemplateParmExpr (such nodes are added during alias template substitution). llvm-svn: 159922
2012-07-09 11:07:20 +08:00
TemplateArgument arg);
Improve the semantic checking for explicit instantiations of templates. In particular: - An explicit instantiation can follow an implicit instantiation (we were improperly diagnosing this as an error, previously). - In C++0x, an explicit instantiation that follows an explicit specialization of the same template specialization is ignored. In C++98, we just emit an extension warning. - In C++0x, an explicit instantiation must be in a namespace enclosing the original template. C++98 has no such requirement. Also, fixed a longstanding FIXME regarding the integral type that is used for the size of a constant array type when it is being instantiated. llvm-svn: 71689
2009-05-14 02:28:20 +08:00
};
Revert r240270 ("Fixed/added namespace ending comments using clang-tidy"). llvm-svn: 240353
2015-06-23 07:07:51 +08:00
}
Implement the basic approach for instantiating types, with a lot of FIXME'd stubs for those types we don't yet know how to instantiate (everything that isn't a template parameter!). We now instantiate default arguments for template type parameters when needed. This will be our testbed while I fill out the remaining type-instantiation logic. llvm-svn: 65649
2009-02-28 03:31:52 +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
bool TemplateInstantiator::AlreadyTransformed(QualType T) {
if (T.isNull())
return true;
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
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 (T->isInstantiationDependentType() || T->isVariablyModifiedType())
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
return false;
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +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
getSema().MarkDeclarationsReferencedInType(Loc, T);
return true;
}
Fix for template substitution with packs. When we see a pack, and replace it with a template argument which is also a pack, we want to use the pack pattern, not the expanded pack. The caller should take care of expanding the pack afterwards. Fixes PR16646. llvm-svn: 186713
2013-07-20 03:40:38 +08:00
static TemplateArgument
getPackSubstitutedTemplateArgument(Sema &S, TemplateArgument Arg) {
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
assert(S.ArgumentPackSubstitutionIndex >= 0);
Fix for template substitution with packs. When we see a pack, and replace it with a template argument which is also a pack, we want to use the pack pattern, not the expanded pack. The caller should take care of expanding the pack afterwards. Fixes PR16646. llvm-svn: 186713
2013-07-20 03:40:38 +08:00
assert(S.ArgumentPackSubstitutionIndex < (int)Arg.pack_size());
Arg = Arg.pack_begin()[S.ArgumentPackSubstitutionIndex];
if (Arg.isPackExpansion())
Arg = Arg.getPackExpansionPattern();
return Arg;
}
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 *TemplateInstantiator::TransformDecl(SourceLocation Loc, Decl *D) {
Improve template instantiation for member access expressions that involve qualified names, e.g., x->Base::f. We now maintain enough information in the AST to compare the results of the name lookup of "Base" in the scope of the postfix-expression (determined at template definition time) and in the type of the object expression. llvm-svn: 80953
2009-09-04 05:38:09 +08:00
if (!D)
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Improve template instantiation for member access expressions that involve qualified names, e.g., x->Base::f. We now maintain enough information in the AST to compare the results of the name lookup of "Base" in the scope of the postfix-expression (determined at template definition time) and in the type of the object expression. llvm-svn: 80953
2009-09-04 05:38:09 +08:00
if (TemplateTemplateParmDecl *TTP = dyn_cast<TemplateTemplateParmDecl>(D)) {
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
if (TTP->getDepth() < TemplateArgs.getNumLevels()) {
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
// If the corresponding template argument is NULL or non-existent, it's
// because we are performing instantiation from explicitly-specified
// template arguments in a function template, but there were some
// arguments left unspecified.
if (!TemplateArgs.hasTemplateArgument(TTP->getDepth(),
TTP->getPosition()))
return D;
Implement support for template template parameter packs, e.g., template<template<class> class ...Metafunctions> struct apply_to_each; llvm-svn: 122874
2011-01-05 23:48:55 +08:00
TemplateArgument Arg = TemplateArgs(TTP->getDepth(), TTP->getPosition());
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
Implement support for template template parameter packs, e.g., template<template<class> class ...Metafunctions> struct apply_to_each; llvm-svn: 122874
2011-01-05 23:48:55 +08:00
if (TTP->isParameterPack()) {
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
assert(Arg.getKind() == TemplateArgument::Pack &&
Implement support for template template parameter packs, e.g., template<template<class> class ...Metafunctions> struct apply_to_each; llvm-svn: 122874
2011-01-05 23:48:55 +08:00
"Missing argument pack");
Fix for template substitution with packs. When we see a pack, and replace it with a template argument which is also a pack, we want to use the pack pattern, not the expanded pack. The caller should take care of expanding the pack afterwards. Fixes PR16646. llvm-svn: 186713
2013-07-20 03:40:38 +08:00
Arg = getPackSubstitutedTemplateArgument(getSema(), Arg);
Implement support for template template parameter packs, e.g., template<template<class> class ...Metafunctions> struct apply_to_each; llvm-svn: 122874
2011-01-05 23:48:55 +08:00
}
PR10147: When substituting a template template argument, substitute in the most recent (non-friend) declaration to pick up the right set of default template arguments. llvm-svn: 312049
2017-08-30 06:14:43 +08:00
TemplateName Template = Arg.getAsTemplate().getNameToSubstitute();
Introduce a new representation for template template parameters. Rather than storing them as either declarations (for the non-dependent case) or expressions (for the dependent case), we now (always) store them as TemplateNames. The primary change here is to add a new kind of TemplateArgument, which stores a TemplateName. However, making that change ripples to every switch on a TemplateArgument's kind, also affecting TemplateArgumentLocInfo/TemplateArgumentLoc, default template arguments for template template parameters, type-checking of template template arguments, etc. This change is light on testing. It should fix several pre-existing problems with template template parameters, such as: - the inability to use dependent template names as template template arguments - template template parameter default arguments cannot be instantiation However, there are enough pieces missing that more implementation is required before we can adequately test template template parameters. llvm-svn: 86777
2009-11-11 09:00:40 +08:00
assert(!Template.isNull() && Template.getAsTemplateDecl() &&
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
"Wrong kind of template template argument");
Introduce a new representation for template template parameters. Rather than storing them as either declarations (for the non-dependent case) or expressions (for the dependent case), we now (always) store them as TemplateNames. The primary change here is to add a new kind of TemplateArgument, which stores a TemplateName. However, making that change ripples to every switch on a TemplateArgument's kind, also affecting TemplateArgumentLocInfo/TemplateArgumentLoc, default template arguments for template template parameters, type-checking of template template arguments, etc. This change is light on testing. It should fix several pre-existing problems with template template parameters, such as: - the inability to use dependent template names as template template arguments - template template parameter default arguments cannot be instantiation However, there are enough pieces missing that more implementation is required before we can adequately test template template parameters. llvm-svn: 86777
2009-11-11 09:00:40 +08:00
return Template.getAsTemplateDecl();
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
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Introduce a new representation for template template parameters. Rather than storing them as either declarations (for the non-dependent case) or expressions (for the dependent case), we now (always) store them as TemplateNames. The primary change here is to add a new kind of TemplateArgument, which stores a TemplateName. However, making that change ripples to every switch on a TemplateArgument's kind, also affecting TemplateArgumentLocInfo/TemplateArgumentLoc, default template arguments for template template parameters, type-checking of template template arguments, etc. This change is light on testing. It should fix several pre-existing problems with template template parameters, such as: - the inability to use dependent template names as template template arguments - template template parameter default arguments cannot be instantiation However, there are enough pieces missing that more implementation is required before we can adequately test template template parameters. llvm-svn: 86777
2009-11-11 09:00:40 +08:00
// Fall through to find the instantiated declaration for this template
// template parameter.
Implement transformation of template names within the generic tree transform, then use the result for template instantiation. The generic transformation fixes a few issues: - It copes better with template template parameters and member templates (when they're implemented). - The logic used to replace template template parameters with their arguments is now centralized in TransformDecl, so that it will apply for other declaration-instantiation steps. - The error-recovery strategy is normalized now, so that any error results in a NULL TemplateName. llvm-svn: 78292
2009-08-06 14:41:21 +08:00
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +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
return SemaRef.FindInstantiatedDecl(Loc, cast<NamedDecl>(D), TemplateArgs);
Implement the basic approach for instantiating types, with a lot of FIXME'd stubs for those types we don't yet know how to instantiate (everything that isn't a template parameter!). We now instantiate default arguments for template type parameters when needed. This will be our testbed while I fill out the remaining type-instantiation logic. llvm-svn: 65649
2009-02-28 03:31:52 +08:00
}
Finish pushing source-location information though TreeTransform's TransformDefinition. llvm-svn: 97445
2010-03-02 01:25:41 +08:00
Decl *TemplateInstantiator::TransformDefinition(SourceLocation Loc, Decl *D) {
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 *Inst = getSema().SubstDecl(D, getSema().CurContext, TemplateArgs);
Refactor the instantiation of statements into a generic tree transformation. llvm-svn: 79519
2009-08-20 15:17:43 +08:00
if (!Inst)
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Refactor the instantiation of statements into a generic tree transformation. llvm-svn: 79519
2009-08-20 15:17:43 +08:00
getSema().CurrentInstantiationScope->InstantiatedLocal(D, Inst);
return Inst;
}
Handle substitutions into the "first qualifier in scope" of a qualified member access expression (e.g., t->U::member) when that first qualifier refers to a template parameters. llvm-svn: 84612
2009-10-20 13:58:46 +08:00
NamedDecl *
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
TemplateInstantiator::TransformFirstQualifierInScope(NamedDecl *D,
Handle substitutions into the "first qualifier in scope" of a qualified member access expression (e.g., t->U::member) when that first qualifier refers to a template parameters. llvm-svn: 84612
2009-10-20 13:58:46 +08:00
SourceLocation Loc) {
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
// If the first part of the nested-name-specifier was a template type
Handle substitutions into the "first qualifier in scope" of a qualified member access expression (e.g., t->U::member) when that first qualifier refers to a template parameters. llvm-svn: 84612
2009-10-20 13:58:46 +08:00
// parameter, instantiate that type parameter down to a tag type.
if (TemplateTypeParmDecl *TTPD = dyn_cast_or_null<TemplateTypeParmDecl>(D)) {
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
const TemplateTypeParmType *TTP
Handle substitutions into the "first qualifier in scope" of a qualified member access expression (e.g., t->U::member) when that first qualifier refers to a template parameters. llvm-svn: 84612
2009-10-20 13:58:46 +08:00
= cast<TemplateTypeParmType>(getSema().Context.getTypeDeclType(TTPD));
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
Handle substitutions into the "first qualifier in scope" of a qualified member access expression (e.g., t->U::member) when that first qualifier refers to a template parameters. llvm-svn: 84612
2009-10-20 13:58:46 +08:00
if (TTP->getDepth() < TemplateArgs.getNumLevels()) {
Handle instantiation of template type parameter packs that occur as the first qualifier in scope. We can't adequately test this test, unfortunately. llvm-svn: 122283
2010-12-21 06:48:17 +08:00
// FIXME: This needs testing w/ member access expressions.
TemplateArgument Arg = TemplateArgs(TTP->getDepth(), TTP->getIndex());
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
Handle instantiation of template type parameter packs that occur as the first qualifier in scope. We can't adequately test this test, unfortunately. llvm-svn: 122283
2010-12-21 06:48:17 +08:00
if (TTP->isParameterPack()) {
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
assert(Arg.getKind() == TemplateArgument::Pack &&
Handle instantiation of template type parameter packs that occur as the first qualifier in scope. We can't adequately test this test, unfortunately. llvm-svn: 122283
2010-12-21 06:48:17 +08:00
"Missing argument pack");
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
Teach template template argument pack expansions to keep track of the number of expansions, when we know it, and propagate that information through Sema. llvm-svn: 123493
2011-01-15 07:41:42 +08:00
if (getSema().ArgumentPackSubstitutionIndex == -1)
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Fix for template substitution with packs. When we see a pack, and replace it with a template argument which is also a pack, we want to use the pack pattern, not the expanded pack. The caller should take care of expanding the pack afterwards. Fixes PR16646. llvm-svn: 186713
2013-07-20 03:40:38 +08:00
Arg = getPackSubstitutedTemplateArgument(getSema(), Arg);
Handle instantiation of template type parameter packs that occur as the first qualifier in scope. We can't adequately test this test, unfortunately. llvm-svn: 122283
2010-12-21 06:48:17 +08:00
}
QualType T = Arg.getAsType();
Handle substitutions into the "first qualifier in scope" of a qualified member access expression (e.g., t->U::member) when that first qualifier refers to a template parameters. llvm-svn: 84612
2009-10-20 13:58:46 +08:00
if (T.isNull())
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
return cast_or_null<NamedDecl>(TransformDecl(Loc, D));
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
Handle substitutions into the "first qualifier in scope" of a qualified member access expression (e.g., t->U::member) when that first qualifier refers to a template parameters. llvm-svn: 84612
2009-10-20 13:58:46 +08:00
if (const TagType *Tag = T->getAs<TagType>())
return Tag->getDecl();
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
Handle substitutions into the "first qualifier in scope" of a qualified member access expression (e.g., t->U::member) when that first qualifier refers to a template parameters. llvm-svn: 84612
2009-10-20 13:58:46 +08:00
// The resulting type is not a tag; complain.
getSema().Diag(Loc, diag::err_nested_name_spec_non_tag) << T;
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Handle substitutions into the "first qualifier in scope" of a qualified member access expression (e.g., t->U::member) when that first qualifier refers to a template parameters. llvm-svn: 84612
2009-10-20 13:58:46 +08:00
}
}
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +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
return cast_or_null<NamedDecl>(TransformDecl(Loc, D));
Handle substitutions into the "first qualifier in scope" of a qualified member access expression (e.g., t->U::member) when that first qualifier refers to a template parameters. llvm-svn: 84612
2009-10-20 13:58:46 +08:00
}
Refactor the instantiation of statements into a generic tree transformation. llvm-svn: 79519
2009-08-20 15:17:43 +08:00
VarDecl *
TemplateInstantiator::RebuildExceptionDecl(VarDecl *ExceptionDecl,
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 *Declarator,
Fixed source range for all DeclaratorDecl's. llvm-svn: 127225
2011-03-08 16:55:46 +08:00
SourceLocation StartLoc,
SourceLocation NameLoc,
IdentifierInfo *Name) {
Simplify template instantiation for C++ exception declarations, eliminating an unnecessary use of TemporaryBase in the process. llvm-svn: 113500
2010-09-10 01:09:21 +08:00
VarDecl *Var = inherited::RebuildExceptionDecl(ExceptionDecl, Declarator,
Fixed source range for all DeclaratorDecl's. llvm-svn: 127225
2011-03-08 16:55:46 +08:00
StartLoc, NameLoc, Name);
Implement template instantiation for Objective-C @catch statements. This is the last of the Objective-C statements. llvm-svn: 102356
2010-04-27 01:57:08 +08:00
if (Var)
getSema().CurrentInstantiationScope->InstantiatedLocal(ExceptionDecl, Var);
return Var;
}
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
VarDecl *TemplateInstantiator::RebuildObjCExceptionDecl(VarDecl *ExceptionDecl,
TypeSourceInfo *TSInfo,
Implement template instantiation for Objective-C @catch statements. This is the last of the Objective-C statements. llvm-svn: 102356
2010-04-27 01:57:08 +08:00
QualType T) {
VarDecl *Var = inherited::RebuildObjCExceptionDecl(ExceptionDecl, TSInfo, T);
if (Var)
Refactor the instantiation of statements into a generic tree transformation. llvm-svn: 79519
2009-08-20 15:17:43 +08:00
getSema().CurrentInstantiationScope->InstantiatedLocal(ExceptionDecl, Var);
return Var;
}
Support elaborated dependent types and diagnose tag mismatches. llvm-svn: 81504
2009-09-11 12:59:25 +08:00
QualType
Use the real keyword location when rebuilding an elaborated type instead of making something up. Fixes PR8129. llvm-svn: 118258
2010-11-05 03:04:38 +08:00
TemplateInstantiator::RebuildElaboratedType(SourceLocation KeywordLoc,
ElaboratedTypeKeyword Keyword,
Reinstate the introduction of source-location information for nested-name-speciciers within elaborated type names, e.g., enum clang::NestedNameSpecifier::SpecifierKind Fixes in this iteration include: (1) Compute the type-source range properly for a dependent template specialization type that starts with "template template-id ::", as in a member access expression dep->template f<T>::f() This is a latent bug I triggered with this change (because now we're checking the computed source ranges for dependent template specialization types). But the real problem was... (2) Make sure to set the qualifier range on a dependent template specialization type appropriately. This will go away once we push nested-name-specifier locations into dependent template specialization types, but it was the source of the valgrind errors on the buildbots. llvm-svn: 126765
2011-03-02 02:12:44 +08:00
NestedNameSpecifierLoc QualifierLoc,
Merged Elaborated and QualifiedName types. llvm-svn: 103517
2010-05-12 05:36:43 +08:00
QualType T) {
Support elaborated dependent types and diagnose tag mismatches. llvm-svn: 81504
2009-09-11 12:59:25 +08:00
if (const TagType *TT = T->getAs<TagType>()) {
TagDecl* TD = TT->getDecl();
Use the real keyword location when rebuilding an elaborated type instead of making something up. Fixes PR8129. llvm-svn: 118258
2010-11-05 03:04:38 +08:00
SourceLocation TagLocation = KeywordLoc;
Support elaborated dependent types and diagnose tag mismatches. llvm-svn: 81504
2009-09-11 12:59:25 +08:00
IdentifierInfo *Id = TD->getIdentifier();
// TODO: should we even warn on struct/class mismatches for this? Seems
// like it's likely to produce a lot of spurious errors.
Don't form a null reference when checking for validity of an anonymous elaborated type specifier in template instantiation: such a specifier is always valid because it must be specified within the definition of the type. llvm-svn: 162068
2012-08-17 08:12:27 +08:00
if (Id && Keyword != ETK_None && Keyword != ETK_Typename) {
Merged Elaborated and QualifiedName types. llvm-svn: 103517
2010-05-12 05:36:43 +08:00
TagTypeKind Kind = TypeWithKeyword::getTagTypeKindForKeyword(Keyword);
Made changes to how 'struct'/'class' mismatches are handled in -Wmismatched-tags. - Removed fix-it hints from template instaniations since changes to the templates are rarely helpful. - Changed the caret in template instaniations from the class/struct name to the class/struct keyword, matching the other warnings. - Do not offer fix-it hints when multiple declarations disagree. Warnings are still given. - Once a definition is found, offer a fix-it hint to all previous declarations with wrong tag. - Declarations that disagree with a previous definition will get a fix-it hint to change the declaration. llvm-svn: 132831
2011-06-10 11:11:26 +08:00
if (!SemaRef.isAcceptableTagRedeclaration(TD, Kind, /*isDefinition*/false,
Sema: Allow null names to be passed in to isAcceptableTagRedeclaration It's possible for TagRedeclarations to involve decls without a name, ie, anonymous enums. We hit some undefined behaviour if we bind these null names to the reference here. We never dereference the name, so it's harmless if it's null - make it a pointer to allow that. Fixes the Modules/submodules-merge-defs.cpp test under ubsan. llvm-svn: 241963
2015-07-11 07:05:47 +08:00
TagLocation, Id)) {
Merged Elaborated and QualifiedName types. llvm-svn: 103517
2010-05-12 05:36:43 +08:00
SemaRef.Diag(TagLocation, diag::err_use_with_wrong_tag)
<< Id
<< FixItHint::CreateReplacement(SourceRange(TagLocation),
TD->getKindName());
SemaRef.Diag(TD->getLocation(), diag::note_previous_use);
}
Support elaborated dependent types and diagnose tag mismatches. llvm-svn: 81504
2009-09-11 12:59:25 +08:00
}
}
Use the real keyword location when rebuilding an elaborated type instead of making something up. Fixes PR8129. llvm-svn: 118258
2010-11-05 03:04:38 +08:00
return TreeTransform<TemplateInstantiator>::RebuildElaboratedType(KeywordLoc,
Keyword,
Reinstate the introduction of source-location information for nested-name-speciciers within elaborated type names, e.g., enum clang::NestedNameSpecifier::SpecifierKind Fixes in this iteration include: (1) Compute the type-source range properly for a dependent template specialization type that starts with "template template-id ::", as in a member access expression dep->template f<T>::f() This is a latent bug I triggered with this change (because now we're checking the computed source ranges for dependent template specialization types). But the real problem was... (2) Make sure to set the qualifier range on a dependent template specialization type appropriately. This will go away once we push nested-name-specifier locations into dependent template specialization types, but it was the source of the valgrind errors on the buildbots. llvm-svn: 126765
2011-03-02 02:12:44 +08:00
QualifierLoc,
T);
Support elaborated dependent types and diagnose tag mismatches. llvm-svn: 81504
2009-09-11 12:59:25 +08:00
}
Finish implementation of C++ DR1310 (http://wg21.link/cwg1310). Diagnose the case when a dependent template name instantiates to an injected-class-name outside a nested-name-specifier. llvm-svn: 292545
2017-01-20 08:20:39 +08:00
TemplateName TemplateInstantiator::TransformTemplateName(
CXXScopeSpec &SS, TemplateName Name, SourceLocation NameLoc,
QualType ObjectType, NamedDecl *FirstQualifierInScope,
bool AllowInjectedClassName) {
Start migrating TreeTransform's TransformTemplateName over to version that preserve source-location information. This commit adds more redundancy than it removes; WIP. llvm-svn: 126849
2011-03-03 02:07:45 +08:00
if (TemplateTemplateParmDecl *TTP
= dyn_cast_or_null<TemplateTemplateParmDecl>(Name.getAsTemplateDecl())) {
if (TTP->getDepth() < TemplateArgs.getNumLevels()) {
// If the corresponding template argument is NULL or non-existent, it's
// because we are performing instantiation from explicitly-specified
// template arguments in a function template, but there were some
// arguments left unspecified.
if (!TemplateArgs.hasTemplateArgument(TTP->getDepth(),
TTP->getPosition()))
return Name;
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
Start migrating TreeTransform's TransformTemplateName over to version that preserve source-location information. This commit adds more redundancy than it removes; WIP. llvm-svn: 126849
2011-03-03 02:07:45 +08:00
TemplateArgument Arg = TemplateArgs(TTP->getDepth(), TTP->getPosition());
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
Distinguish between template parameter substitutions that are forming specializations and those that are done as part of rewrites. Do not create Subst* nodes in the latter. We previously had a hybrid of these two behaviors where we would only create some Subst* nodes but not others during deduction guide rewrites. No functional change intended, but the resulting ASTs are more principled.
2020-06-23 10:30:36 +08:00
if (TemplateArgs.isRewrite()) {
// We're rewriting the template parameter as a reference to another
// template parameter.
if (Arg.getKind() == TemplateArgument::Pack) {
assert(Arg.pack_size() == 1 && Arg.pack_begin()->isPackExpansion() &&
"unexpected pack arguments in template rewrite");
Arg = Arg.pack_begin()->getPackExpansionPattern();
}
assert(Arg.getKind() == TemplateArgument::Template &&
"unexpected nontype template argument kind in template rewrite");
return Arg.getAsTemplate();
}
Start migrating TreeTransform's TransformTemplateName over to version that preserve source-location information. This commit adds more redundancy than it removes; WIP. llvm-svn: 126849
2011-03-03 02:07:45 +08:00
if (TTP->isParameterPack()) {
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
assert(Arg.getKind() == TemplateArgument::Pack &&
Start migrating TreeTransform's TransformTemplateName over to version that preserve source-location information. This commit adds more redundancy than it removes; WIP. llvm-svn: 126849
2011-03-03 02:07:45 +08:00
"Missing argument pack");
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
Start migrating TreeTransform's TransformTemplateName over to version that preserve source-location information. This commit adds more redundancy than it removes; WIP. llvm-svn: 126849
2011-03-03 02:07:45 +08:00
if (getSema().ArgumentPackSubstitutionIndex == -1) {
// We have the template argument pack to substitute, but we're not
// actually expanding the enclosing pack expansion yet. So, just
// keep the entire argument pack.
return getSema().Context.getSubstTemplateTemplateParmPack(TTP, Arg);
}
Fix for template substitution with packs. When we see a pack, and replace it with a template argument which is also a pack, we want to use the pack pattern, not the expanded pack. The caller should take care of expanding the pack afterwards. Fixes PR16646. llvm-svn: 186713
2013-07-20 03:40:38 +08:00
Arg = getPackSubstitutedTemplateArgument(getSema(), Arg);
Start migrating TreeTransform's TransformTemplateName over to version that preserve source-location information. This commit adds more redundancy than it removes; WIP. llvm-svn: 126849
2011-03-03 02:07:45 +08:00
}
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
PR10147: When substituting a template template argument, substitute in the most recent (non-friend) declaration to pick up the right set of default template arguments. llvm-svn: 312049
2017-08-30 06:14:43 +08:00
TemplateName Template = Arg.getAsTemplate().getNameToSubstitute();
Implement support for C++0x alias templates. llvm-svn: 130953
2011-05-06 05:57:07 +08:00
assert(!Template.isNull() && "Null template template argument");
PR10147: When substituting a template template argument, substitute in the most recent (non-friend) declaration to pick up the right set of default template arguments. llvm-svn: 312049
2017-08-30 06:14:43 +08:00
assert(!Template.getAsQualifiedTemplateName() &&
"template decl to substitute is qualified?");
Preserve that a TemplateName was arrived at by substituting for a template template parameter. Uses to follow. I've also made the uniquing of SubstTemplateTemplateParmPacks use a ContextualFoldingSet as a minor space efficiency. llvm-svn: 134137
2011-06-30 16:33:18 +08:00
Template = getSema().Context.getSubstTemplateTemplateParm(TTP, Template);
Start migrating TreeTransform's TransformTemplateName over to version that preserve source-location information. This commit adds more redundancy than it removes; WIP. llvm-svn: 126849
2011-03-03 02:07:45 +08:00
return Template;
}
}
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
Start migrating TreeTransform's TransformTemplateName over to version that preserve source-location information. This commit adds more redundancy than it removes; WIP. llvm-svn: 126849
2011-03-03 02:07:45 +08:00
if (SubstTemplateTemplateParmPackStorage *SubstPack
= Name.getAsSubstTemplateTemplateParmPack()) {
if (getSema().ArgumentPackSubstitutionIndex == -1)
return Name;
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
Fix for template substitution with packs. When we see a pack, and replace it with a template argument which is also a pack, we want to use the pack pattern, not the expanded pack. The caller should take care of expanding the pack afterwards. Fixes PR16646. llvm-svn: 186713
2013-07-20 03:40:38 +08:00
TemplateArgument Arg = SubstPack->getArgumentPack();
Arg = getPackSubstitutedTemplateArgument(getSema(), Arg);
PR10147: When substituting a template template argument, substitute in the most recent (non-friend) declaration to pick up the right set of default template arguments. llvm-svn: 312049
2017-08-30 06:14:43 +08:00
return Arg.getAsTemplate().getNameToSubstitute();
Start migrating TreeTransform's TransformTemplateName over to version that preserve source-location information. This commit adds more redundancy than it removes; WIP. llvm-svn: 126849
2011-03-03 02:07:45 +08:00
}
Finish implementation of C++ DR1310 (http://wg21.link/cwg1310). Diagnose the case when a dependent template name instantiates to an injected-class-name outside a nested-name-specifier. llvm-svn: 292545
2017-01-20 08:20:39 +08:00
return inherited::TransformTemplateName(SS, Name, NameLoc, ObjectType,
FirstQualifierInScope,
AllowInjectedClassName);
Start migrating TreeTransform's TransformTemplateName over to version that preserve source-location information. This commit adds more redundancy than it removes; WIP. llvm-svn: 126849
2011-03-03 02:07:45 +08:00
}
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
ExprResult
The refactor of implicit member access expressions means we don't need this horrible isAddressOfOperand hack in TreeTransform, since that syntactic information is managed by the initial parser callbacks now. That's enough insomniac commits for one night. llvm-svn: 90849
2009-12-08 17:21:05 +08:00
TemplateInstantiator::TransformPredefinedExpr(PredefinedExpr *E) {
Instantiate PredefinedExprs correctly. Patch by Sam Weinig! llvm-svn: 81498
2009-09-11 09:22:35 +08:00
if (!E->isTypeDependent())
Refactoring. Remove Owned method from Sema. llvm-svn: 209812
2014-05-29 22:05:12 +08:00
return E;
Instantiate PredefinedExprs correctly. Patch by Sam Weinig! llvm-svn: 81498
2009-09-11 09:22:35 +08:00
[AST] Refactor PredefinedExpr Make the following changes to PredefinedExpr: 1. Move PredefinedExpr below StringLiteral so that it can use its definition. 2. Rename IdentType to IdentKind to be more in line with clang's conventions, and propagate the change to its users. 3. Move the location and the IdentKind into the newly available space of the bit-fields of Stmt. 4. Only store the function name when needed. When parsing all of Boost, of the 1357 PredefinedExpr 919 have no function name. Differential Revision: https://reviews.llvm.org/D53605 Reviewed By: rjmccall llvm-svn: 345460
2018-10-28 03:21:19 +08:00
return getSema().BuildPredefinedExpr(E->getLocation(), E->getIdentKind());
Instantiate PredefinedExprs correctly. Patch by Sam Weinig! llvm-svn: 81498
2009-09-11 09:22:35 +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
Extract a function to instantiate references to value template parameters. llvm-svn: 95491
2010-02-06 16:42:39 +08:00
TemplateInstantiator::TransformTemplateParmRefExpr(DeclRefExpr *E,
When substituting a declaration non-type template argument for a non-type template parameter that has reference type, augment the qualifiers of the non-type template argument with those of the referenced type. Fixes PR6250. llvm-svn: 95607
2010-02-09 07:41:45 +08:00
NonTypeTemplateParmDecl *NTTP) {
Extract a function to instantiate references to value template parameters. llvm-svn: 95491
2010-02-06 16:42:39 +08:00
// If the corresponding template argument is NULL or non-existent, it's
// because we are performing instantiation from explicitly-specified
// template arguments in a function template, but there were some
// arguments left unspecified.
if (!TemplateArgs.hasTemplateArgument(NTTP->getDepth(),
NTTP->getPosition()))
Refactoring. Remove Owned method from Sema. llvm-svn: 209812
2014-05-29 22:05:12 +08:00
return E;
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
When instantiating a non-type template parameter pack, be sure to extract the appropriate argument from the argument pack (based on the current substitution index, of course). Simple instantiation of pack expansions involving non-type template parameter packs now works. llvm-svn: 122532
2010-12-24 08:15:10 +08:00
TemplateArgument Arg = TemplateArgs(NTTP->getDepth(), NTTP->getPosition());
PR32010: Fix template argument depth mixup when forming implicit constructor template deduction guides for class template argument deduction. Ensure that we have a local instantiation scope for tracking the instantiated parameters. Additionally, unusually, we're substituting at depth 1 and leaving depth 0 alone; make sure that we don't reduce template parameter depth by 2 for inner parameters in the process. (This is probably also broken for alias templates in the case where they're expanded within a dependent context, but this patch doesn't fix that.) llvm-svn: 295696
2017-02-21 14:30:38 +08:00
Distinguish between template parameter substitutions that are forming specializations and those that are done as part of rewrites. Do not create Subst* nodes in the latter. We previously had a hybrid of these two behaviors where we would only create some Subst* nodes but not others during deduction guide rewrites. No functional change intended, but the resulting ASTs are more principled.
2020-06-23 10:30:36 +08:00
if (TemplateArgs.isRewrite()) {
// We're rewriting the template parameter as a reference to another
// template parameter.
PR32010: Fix template argument depth mixup when forming implicit constructor template deduction guides for class template argument deduction. Ensure that we have a local instantiation scope for tracking the instantiated parameters. Additionally, unusually, we're substituting at depth 1 and leaving depth 0 alone; make sure that we don't reduce template parameter depth by 2 for inner parameters in the process. (This is probably also broken for alias templates in the case where they're expanded within a dependent context, but this patch doesn't fix that.) llvm-svn: 295696
2017-02-21 14:30:38 +08:00
if (Arg.getKind() == TemplateArgument::Pack) {
assert(Arg.pack_size() == 1 && Arg.pack_begin()->isPackExpansion() &&
Distinguish between template parameter substitutions that are forming specializations and those that are done as part of rewrites. Do not create Subst* nodes in the latter. We previously had a hybrid of these two behaviors where we would only create some Subst* nodes but not others during deduction guide rewrites. No functional change intended, but the resulting ASTs are more principled.
2020-06-23 10:30:36 +08:00
"unexpected pack arguments in template rewrite");
PR32010: Fix template argument depth mixup when forming implicit constructor template deduction guides for class template argument deduction. Ensure that we have a local instantiation scope for tracking the instantiated parameters. Additionally, unusually, we're substituting at depth 1 and leaving depth 0 alone; make sure that we don't reduce template parameter depth by 2 for inner parameters in the process. (This is probably also broken for alias templates in the case where they're expanded within a dependent context, but this patch doesn't fix that.) llvm-svn: 295696
2017-02-21 14:30:38 +08:00
Arg = Arg.pack_begin()->getPackExpansionPattern();
}
assert(Arg.getKind() == TemplateArgument::Expression &&
Distinguish between template parameter substitutions that are forming specializations and those that are done as part of rewrites. Do not create Subst* nodes in the latter. We previously had a hybrid of these two behaviors where we would only create some Subst* nodes but not others during deduction guide rewrites. No functional change intended, but the resulting ASTs are more principled.
2020-06-23 10:30:36 +08:00
"unexpected nontype template argument kind in template rewrite");
// FIXME: This can lead to the same subexpression appearing multiple times
// in a complete expression.
PR32010: Fix template argument depth mixup when forming implicit constructor template deduction guides for class template argument deduction. Ensure that we have a local instantiation scope for tracking the instantiated parameters. Additionally, unusually, we're substituting at depth 1 and leaving depth 0 alone; make sure that we don't reduce template parameter depth by 2 for inner parameters in the process. (This is probably also broken for alias templates in the case where they're expanded within a dependent context, but this patch doesn't fix that.) llvm-svn: 295696
2017-02-21 14:30:38 +08:00
return Arg.getAsExpr();
}
When instantiating a non-type template parameter pack, be sure to extract the appropriate argument from the argument pack (based on the current substitution index, of course). Simple instantiation of pack expansions involving non-type template parameter packs now works. llvm-svn: 122532
2010-12-24 08:15:10 +08:00
if (NTTP->isParameterPack()) {
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
assert(Arg.getKind() == TemplateArgument::Pack &&
When instantiating a non-type template parameter pack, be sure to extract the appropriate argument from the argument pack (based on the current substitution index, of course). Simple instantiation of pack expansions involving non-type template parameter packs now works. llvm-svn: 122532
2010-12-24 08:15:10 +08:00
"Missing argument pack");
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
When instantiating a non-type template parameter pack, be sure to extract the appropriate argument from the argument pack (based on the current substitution index, of course). Simple instantiation of pack expansions involving non-type template parameter packs now works. llvm-svn: 122532
2010-12-24 08:15:10 +08:00
if (getSema().ArgumentPackSubstitutionIndex == -1) {
Introduce a new expression kind, SubstNonTypeTemplateParmPackExpr, that captures the substitution of a non-type template argument pack for a non-type template parameter pack within a pack expansion that cannot be fully expanded. This follows the approach taken by SubstTemplateTypeParmPackType. llvm-svn: 123506
2011-01-15 09:15:58 +08:00
// We have an argument pack, but we can't select a particular argument
// out of it yet. Therefore, we'll build an expression to hold on to that
// argument pack.
QualType TargetType = SemaRef.SubstType(NTTP->getType(), TemplateArgs,
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
E->getLocation(),
Introduce a new expression kind, SubstNonTypeTemplateParmPackExpr, that captures the substitution of a non-type template argument pack for a non-type template parameter pack within a pack expansion that cannot be fully expanded. This follows the approach taken by SubstTemplateTypeParmPackType. llvm-svn: 123506
2011-01-15 09:15:58 +08:00
NTTP->getDeclName());
if (TargetType.isNull())
return ExprError();
Fix a couple of places where we assumed that non-type template parameters are always rvalues. llvm-svn: 325095
2018-02-14 10:07:53 +08:00
[c++20] For P0732R2: Give class NTTPs the proper type when examined with 'decltype'. This requires that we track enough information to determine the original type of the parameter in a substituted non-type template parameter, to distinguish the reference-to-class case from the class case.
2020-09-14 10:38:32 +08:00
QualType ExprType = TargetType.getNonLValueExprType(SemaRef.Context);
if (TargetType->isRecordType())
ExprType.addConst();
Fix a couple of places where we assumed that non-type template parameters are always rvalues. llvm-svn: 325095
2018-02-14 10:07:53 +08:00
return new (SemaRef.Context) SubstNonTypeTemplateParmPackExpr(
[clang] NFC: Rename rvalue to prvalue This renames the expression value categories from rvalue to prvalue, keeping nomenclature consistent with C++11 onwards. C++ has the most complicated taxonomy here, and every other language only uses a subset of it, so it's less confusing to use the C++ names consistently, and mentally remap to the C names when working on that context (prvalue -> rvalue, no xvalues, etc). Renames: * VK_RValue -> VK_PRValue * Expr::isRValue -> Expr::isPRValue * SK_QualificationConversionRValue -> SK_QualificationConversionPRValue * JSON AST Dumper Expression nodes value category: "rvalue" -> "prvalue" Signed-off-by: Matheus Izvekov <mizvekov@gmail.com> Reviewed By: rsmith Differential Revision: https://reviews.llvm.org/D103720
2021-06-05 05:15:23 +08:00
ExprType, TargetType->isReferenceType() ? VK_LValue : VK_PRValue,
NTTP, E->getLocation(), Arg);
When instantiating a non-type template parameter pack, be sure to extract the appropriate argument from the argument pack (based on the current substitution index, of course). Simple instantiation of pack expansions involving non-type template parameter packs now works. llvm-svn: 122532
2010-12-24 08:15:10 +08:00
}
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
Fix for template substitution with packs. When we see a pack, and replace it with a template argument which is also a pack, we want to use the pack pattern, not the expanded pack. The caller should take care of expanding the pack afterwards. Fixes PR16646. llvm-svn: 186713
2013-07-20 03:40:38 +08:00
Arg = getPackSubstitutedTemplateArgument(getSema(), Arg);
When instantiating a non-type template parameter pack, be sure to extract the appropriate argument from the argument pack (based on the current substitution index, of course). Simple instantiation of pack expansions involving non-type template parameter packs now works. llvm-svn: 122532
2010-12-24 08:15:10 +08:00
}
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 new expression node, SubstNonTypeTemplateParmExpr, to represent a fully-substituted non-type template parameter. This should improve source fidelity, as well as being generically useful for diagnostics and such. llvm-svn: 135243
2011-07-15 13:09:51 +08:00
return transformNonTypeTemplateParmRef(NTTP, E->getLocation(), Arg);
}
Allow constant expressions in pragma loop hints. Previously loop hints such as #pragma loop vectorize_width(#) required a constant. This patch allows a constant expression to be used as well. Such as a non-type template parameter or an expression (2 * c + 1). Reviewed by Richard Smith llvm-svn: 219589
2014-10-13 04:46:07 +08:00
const LoopHintAttr *
TemplateInstantiator::TransformLoopHintAttr(const LoopHintAttr *LH) {
Expr *TransformedExpr = getDerived().TransformExpr(LH->getValue()).get();
if (TransformedExpr == LH->getValue())
return LH;
// Generate error if there is a problem with the value.
if (getSema().CheckLoopHintExpr(TransformedExpr, LH->getLocation()))
return LH;
// Create new LoopHintValueAttr with integral expression in place of the
// non-type template parameter.
[NFCI]Create CommonAttributeInfo Type as base type of *Attr and ParsedAttr. In order to enable future improvements to our attribute diagnostics, this moves info from ParsedAttr into CommonAttributeInfo, then makes this type the base of the *Attr and ParsedAttr types. Quite a bit of refactoring took place, including removing a bunch of redundant Spelling Index propogation. Differential Revision: https://reviews.llvm.org/D67368 llvm-svn: 371875
2019-09-14 01:39:31 +08:00
return LoopHintAttr::CreateImplicit(getSema().Context, LH->getOption(),
LH->getState(), TransformedExpr, *LH);
Allow constant expressions in pragma loop hints. Previously loop hints such as #pragma loop vectorize_width(#) required a constant. This patch allows a constant expression to be used as well. Such as a non-type template parameter or an expression (2 * c + 1). Reviewed by Richard Smith llvm-svn: 219589
2014-10-13 04:46:07 +08:00
}
Create a new expression node, SubstNonTypeTemplateParmExpr, to represent a fully-substituted non-type template parameter. This should improve source fidelity, as well as being generically useful for diagnostics and such. llvm-svn: 135243
2011-07-15 13:09:51 +08:00
ExprResult TemplateInstantiator::transformNonTypeTemplateParmRef(
NonTypeTemplateParmDecl *parm,
SourceLocation loc,
PR13136: * When substituting a reference to a non-type template parameter pack where the corresponding argument is a pack expansion, transform into an expression which contains an unexpanded parameter pack rather than into an expression which contains a pack expansion. This causes the SubstNonTypeTemplateParmExpr to be inside the PackExpansionExpr, rather than outside, so the expression still looks like a pack expansion and can be deduced. * Teach MarkUsedTemplateParameters that we can deduce a reference to a template parameter if it's wrapped in a SubstNonTypeTemplateParmExpr (such nodes are added during alias template substitution). llvm-svn: 159922
2012-07-09 11:07:20 +08:00
TemplateArgument arg) {
Create a new expression node, SubstNonTypeTemplateParmExpr, to represent a fully-substituted non-type template parameter. This should improve source fidelity, as well as being generically useful for diagnostics and such. llvm-svn: 135243
2011-07-15 13:09:51 +08:00
ExprResult result;
[c++20] For P0732R2: Give class NTTPs the proper type when examined with 'decltype'. This requires that we track enough information to determine the original type of the parameter in a substituted non-type template parameter, to distinguish the reference-to-class case from the class case.
2020-09-14 10:38:32 +08:00
// Determine the substituted parameter type. We can usually infer this from
// the template argument, but not always.
auto SubstParamType = [&] {
QualType T;
if (parm->isExpandedParameterPack())
T = parm->getExpansionType(SemaRef.ArgumentPackSubstitutionIndex);
else
T = parm->getType();
if (parm->isParameterPack() && isa<PackExpansionType>(T))
T = cast<PackExpansionType>(T)->getPattern();
return SemaRef.SubstType(T, TemplateArgs, loc, parm->getDeclName());
};
bool refParam = false;
// The template argument itself might be an expression, in which case we just
// return that expression. This happens when substituting into an alias
// template.
Create a new expression node, SubstNonTypeTemplateParmExpr, to represent a fully-substituted non-type template parameter. This should improve source fidelity, as well as being generically useful for diagnostics and such. llvm-svn: 135243
2011-07-15 13:09:51 +08:00
if (arg.getKind() == TemplateArgument::Expression) {
Expr *argExpr = arg.getAsExpr();
Refactoring. Remove Owned method from Sema. llvm-svn: 209812
2014-05-29 22:05:12 +08:00
result = argExpr;
[c++20] For P0732R2: Give class NTTPs the proper type when examined with 'decltype'. This requires that we track enough information to determine the original type of the parameter in a substituted non-type template parameter, to distinguish the reference-to-class case from the class case.
2020-09-14 10:38:32 +08:00
if (argExpr->isLValue()) {
if (argExpr->getType()->isRecordType()) {
// Check whether the parameter was actually a reference.
QualType paramType = SubstParamType();
if (paramType.isNull())
return ExprError();
refParam = paramType->isReferenceType();
} else {
refParam = true;
}
}
Fix the AST representation for non-type template arguments to encode enough information so we can mangle them correctly in cases involving dependent parameter types. (This specifically impacts cases involving null pointers and cases involving parameters of reference type.) Fix the mangler to use this information instead of trying to scavenge it out of the parameter declaration. <rdar://problem/12296776>. llvm-svn: 164656
2012-09-26 10:36:12 +08:00
} else if (arg.getKind() == TemplateArgument::Declaration ||
arg.getKind() == TemplateArgument::NullPtr) {
Implement support for null non-type template arguments for non-type template parameters of pointer, pointer-to-member, or nullptr_t type in C++11. Fixes PR9700 / <rdar://problem/11193097>. llvm-svn: 154219
2012-04-07 06:40:38 +08:00
ValueDecl *VD;
Fix the AST representation for non-type template arguments to encode enough information so we can mangle them correctly in cases involving dependent parameter types. (This specifically impacts cases involving null pointers and cases involving parameters of reference type.) Fix the mangler to use this information instead of trying to scavenge it out of the parameter declaration. <rdar://problem/12296776>. llvm-svn: 164656
2012-09-26 10:36:12 +08:00
if (arg.getKind() == TemplateArgument::Declaration) {
Remove redundant casts. NFC So I wrote a clang-tidy check to lint out redundant `isa`, `cast`, and `dyn_cast`s for fun. This is a portion of what it found for clang; I plan to do similar cleanups in LLVM and other subprojects when I find time. Because of the volume of changes, I explicitly avoided making any change that wasn't highly local and obviously correct to me (e.g. we still have a number of foo(cast<Bar>(baz)) that I didn't touch, since overloading is a thing and the cast<Bar> did actually change the type -- just up the class hierarchy). I also tried to leave the types we were cast<>ing to somewhere nearby, in cases where it wasn't locally obvious what we were dealing with before. llvm-svn: 326416
2018-03-01 13:43:23 +08:00
VD = arg.getAsDecl();
Implement support for null non-type template arguments for non-type template parameters of pointer, pointer-to-member, or nullptr_t type in C++11. Fixes PR9700 / <rdar://problem/11193097>. llvm-svn: 154219
2012-04-07 06:40:38 +08:00
// Find the instantiation of the template argument. This is
// required for nested templates.
VD = cast_or_null<ValueDecl>(
getSema().FindInstantiatedDecl(loc, VD, TemplateArgs));
if (!VD)
return ExprError();
} else {
// Propagate NULL template argument.
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
VD = nullptr;
Implement support for null non-type template arguments for non-type template parameters of pointer, pointer-to-member, or nullptr_t type in C++11. Fixes PR9700 / <rdar://problem/11193097>. llvm-svn: 154219
2012-04-07 06:40:38 +08:00
}
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
Revert "Following up on PR48517, fix handling of template arguments that refer" Combined with 'da98651 - Revert "DR2064: decltype(E) is only a dependent', this change (5a391d3) caused verifier errors when building Chromium. See https://crbug.com/1168494#c1 for a reproducer. Additionally it reverts changes that were dependent on this one, see below. > Following up on PR48517, fix handling of template arguments that refer > to dependent declarations. > > Treat an id-expression that names a local variable in a templated > function as being instantiation-dependent. > > This addresses a language defect whereby a reference to a dependent > declaration can be formed without any construct being value-dependent. > Fixing that through value-dependence turns out to be problematic, so > instead this patch takes the approach (proposed on the core reflector) > of allowing the use of pointers or references to (but not values of) > dependent declarations inside value-dependent expressions, and instead > treating template arguments as dependent if they evaluate to a constant > involving such dependent declarations. > > This ends up affecting a bunch of OpenMP tests, due to OpenMP > imprecisely handling instantiation-dependent constructs, bailing out > early instead of processing dependent constructs to the extent possible > when handling the template. > > Previously committed as 8c1f2d15b826591cdf6bd6b468b8a7d23377b29e, and > reverted because a dependency commit was reverted. This reverts commit 5a391d38ac6c561ba908334d427f26124ed9132e. It also restores clang/test/SemaCXX/coroutines.cpp to its state before da986511fb9da1a46a0ca4dba2e49e2426036303. Revert "[c++20] P1907R1: Support for generalized non-type template arguments of scalar type." > Previously committed as 9e08e51a20d0d2b1c5724bb17e969d036fced4cd, and > reverted because a dependency commit was reverted. This incorporates the > following follow-on commits that were also reverted: > > 7e84aa1b81e72d44bcc58ffe1731bfc7abb73ce0 by Simon Pilgrim > ed13d8c66781b50ff007cb089c5905f9bb9e8af2 by me > 95c7b6cadbc9a3d4376ef44edbeb3c8bb5b8d7fc by Sam McCall > 430d5d8429473c2b10b109991d7577a3cea41140 by Dave Zarzycki This reverts commit 4b574008aef5a7235c1f894ab065fe300d26e786. Revert "[msabi] Mangle a template argument referring to array-to-pointer decay" > [msabi] Mangle a template argument referring to array-to-pointer decay > applied to an array the same as the array itself. > > This follows MS ABI, and corrects a regression from the implementation > of generalized non-type template parameters, where we "forgot" how to > mangle this case. This reverts commit 18e093faf726d15f210ab4917142beec51848258.
2021-01-20 22:25:33 +08:00
QualType paramType = VD ? arg.getParamTypeForDecl() : arg.getNullPtrType();
[c++20] For P0732R2: Give class NTTPs the proper type when examined with 'decltype'. This requires that we track enough information to determine the original type of the parameter in a substituted non-type template parameter, to distinguish the reference-to-class case from the class case.
2020-09-14 10:38:32 +08:00
assert(!paramType.isNull() && "type substitution failed for param type");
assert(!paramType->isDependentType() && "param type still dependent");
result = SemaRef.BuildExpressionFromDeclTemplateArgument(arg, paramType, loc);
refParam = paramType->isReferenceType();
Create a new expression node, SubstNonTypeTemplateParmExpr, to represent a fully-substituted non-type template parameter. This should improve source fidelity, as well as being generically useful for diagnostics and such. llvm-svn: 135243
2011-07-15 13:09:51 +08:00
} else {
Revert "Following up on PR48517, fix handling of template arguments that refer" Combined with 'da98651 - Revert "DR2064: decltype(E) is only a dependent', this change (5a391d3) caused verifier errors when building Chromium. See https://crbug.com/1168494#c1 for a reproducer. Additionally it reverts changes that were dependent on this one, see below. > Following up on PR48517, fix handling of template arguments that refer > to dependent declarations. > > Treat an id-expression that names a local variable in a templated > function as being instantiation-dependent. > > This addresses a language defect whereby a reference to a dependent > declaration can be formed without any construct being value-dependent. > Fixing that through value-dependence turns out to be problematic, so > instead this patch takes the approach (proposed on the core reflector) > of allowing the use of pointers or references to (but not values of) > dependent declarations inside value-dependent expressions, and instead > treating template arguments as dependent if they evaluate to a constant > involving such dependent declarations. > > This ends up affecting a bunch of OpenMP tests, due to OpenMP > imprecisely handling instantiation-dependent constructs, bailing out > early instead of processing dependent constructs to the extent possible > when handling the template. > > Previously committed as 8c1f2d15b826591cdf6bd6b468b8a7d23377b29e, and > reverted because a dependency commit was reverted. This reverts commit 5a391d38ac6c561ba908334d427f26124ed9132e. It also restores clang/test/SemaCXX/coroutines.cpp to its state before da986511fb9da1a46a0ca4dba2e49e2426036303. Revert "[c++20] P1907R1: Support for generalized non-type template arguments of scalar type." > Previously committed as 9e08e51a20d0d2b1c5724bb17e969d036fced4cd, and > reverted because a dependency commit was reverted. This incorporates the > following follow-on commits that were also reverted: > > 7e84aa1b81e72d44bcc58ffe1731bfc7abb73ce0 by Simon Pilgrim > ed13d8c66781b50ff007cb089c5905f9bb9e8af2 by me > 95c7b6cadbc9a3d4376ef44edbeb3c8bb5b8d7fc by Sam McCall > 430d5d8429473c2b10b109991d7577a3cea41140 by Dave Zarzycki This reverts commit 4b574008aef5a7235c1f894ab065fe300d26e786. Revert "[msabi] Mangle a template argument referring to array-to-pointer decay" > [msabi] Mangle a template argument referring to array-to-pointer decay > applied to an array the same as the array itself. > > This follows MS ABI, and corrects a regression from the implementation > of generalized non-type template parameters, where we "forgot" how to > mangle this case. This reverts commit 18e093faf726d15f210ab4917142beec51848258.
2021-01-20 22:25:33 +08:00
result = SemaRef.BuildExpressionFromIntegralTemplateArgument(arg, loc);
[c++20] For P0732R2: Give class NTTPs the proper type when examined with 'decltype'. This requires that we track enough information to determine the original type of the parameter in a substituted non-type template parameter, to distinguish the reference-to-class case from the class case.
2020-09-14 10:38:32 +08:00
assert(result.isInvalid() ||
SemaRef.Context.hasSameType(result.get()->getType(),
Revert "Following up on PR48517, fix handling of template arguments that refer" Combined with 'da98651 - Revert "DR2064: decltype(E) is only a dependent', this change (5a391d3) caused verifier errors when building Chromium. See https://crbug.com/1168494#c1 for a reproducer. Additionally it reverts changes that were dependent on this one, see below. > Following up on PR48517, fix handling of template arguments that refer > to dependent declarations. > > Treat an id-expression that names a local variable in a templated > function as being instantiation-dependent. > > This addresses a language defect whereby a reference to a dependent > declaration can be formed without any construct being value-dependent. > Fixing that through value-dependence turns out to be problematic, so > instead this patch takes the approach (proposed on the core reflector) > of allowing the use of pointers or references to (but not values of) > dependent declarations inside value-dependent expressions, and instead > treating template arguments as dependent if they evaluate to a constant > involving such dependent declarations. > > This ends up affecting a bunch of OpenMP tests, due to OpenMP > imprecisely handling instantiation-dependent constructs, bailing out > early instead of processing dependent constructs to the extent possible > when handling the template. > > Previously committed as 8c1f2d15b826591cdf6bd6b468b8a7d23377b29e, and > reverted because a dependency commit was reverted. This reverts commit 5a391d38ac6c561ba908334d427f26124ed9132e. It also restores clang/test/SemaCXX/coroutines.cpp to its state before da986511fb9da1a46a0ca4dba2e49e2426036303. Revert "[c++20] P1907R1: Support for generalized non-type template arguments of scalar type." > Previously committed as 9e08e51a20d0d2b1c5724bb17e969d036fced4cd, and > reverted because a dependency commit was reverted. This incorporates the > following follow-on commits that were also reverted: > > 7e84aa1b81e72d44bcc58ffe1731bfc7abb73ce0 by Simon Pilgrim > ed13d8c66781b50ff007cb089c5905f9bb9e8af2 by me > 95c7b6cadbc9a3d4376ef44edbeb3c8bb5b8d7fc by Sam McCall > 430d5d8429473c2b10b109991d7577a3cea41140 by Dave Zarzycki This reverts commit 4b574008aef5a7235c1f894ab065fe300d26e786. Revert "[msabi] Mangle a template argument referring to array-to-pointer decay" > [msabi] Mangle a template argument referring to array-to-pointer decay > applied to an array the same as the array itself. > > This follows MS ABI, and corrects a regression from the implementation > of generalized non-type template parameters, where we "forgot" how to > mangle this case. This reverts commit 18e093faf726d15f210ab4917142beec51848258.
2021-01-20 22:25:33 +08:00
arg.getIntegralType()));
Extract a function to instantiate references to value template parameters. llvm-svn: 95491
2010-02-06 16:42:39 +08:00
}
[c++20] For P0732R2: Give class NTTPs the proper type when examined with 'decltype'. This requires that we track enough information to determine the original type of the parameter in a substituted non-type template parameter, to distinguish the reference-to-class case from the class case.
2020-09-14 10:38:32 +08:00
if (result.isInvalid())
return ExprError();
Extract a function to instantiate references to value template parameters. llvm-svn: 95491
2010-02-06 16:42:39 +08:00
Refactoring. Remove release and take methods from ActionResult. Rename takeAs to getAs. llvm-svn: 209800
2014-05-29 18:55:11 +08:00
Expr *resultExpr = result.get();
Refactoring. Remove Owned method from Sema. llvm-svn: 209812
2014-05-29 22:05:12 +08:00
return new (SemaRef.Context) SubstNonTypeTemplateParmExpr(
[c++20] For P0732R2: Give class NTTPs the proper type when examined with 'decltype'. This requires that we track enough information to determine the original type of the parameter in a substituted non-type template parameter, to distinguish the reference-to-class case from the class case.
2020-09-14 10:38:32 +08:00
resultExpr->getType(), resultExpr->getValueKind(), loc, parm, refParam,
resultExpr);
Extract a function to instantiate references to value template parameters. llvm-svn: 95491
2010-02-06 16:42:39 +08:00
}
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
ExprResult
Introduce a new expression kind, SubstNonTypeTemplateParmPackExpr, that captures the substitution of a non-type template argument pack for a non-type template parameter pack within a pack expansion that cannot be fully expanded. This follows the approach taken by SubstTemplateTypeParmPackType. llvm-svn: 123506
2011-01-15 09:15:58 +08:00
TemplateInstantiator::TransformSubstNonTypeTemplateParmPackExpr(
SubstNonTypeTemplateParmPackExpr *E) {
if (getSema().ArgumentPackSubstitutionIndex == -1) {
// We aren't expanding the parameter pack, so just return ourselves.
Refactoring. Remove Owned method from Sema. llvm-svn: 209812
2014-05-29 22:05:12 +08:00
return E;
Introduce a new expression kind, SubstNonTypeTemplateParmPackExpr, that captures the substitution of a non-type template argument pack for a non-type template parameter pack within a pack expansion that cannot be fully expanded. This follows the approach taken by SubstTemplateTypeParmPackType. llvm-svn: 123506
2011-01-15 09:15:58 +08:00
}
Fix for template substitution with packs. When we see a pack, and replace it with a template argument which is also a pack, we want to use the pack pattern, not the expanded pack. The caller should take care of expanding the pack afterwards. Fixes PR16646. llvm-svn: 186713
2013-07-20 03:40:38 +08:00
TemplateArgument Arg = E->getArgumentPack();
Arg = getPackSubstitutedTemplateArgument(getSema(), Arg);
Create a new expression node, SubstNonTypeTemplateParmExpr, to represent a fully-substituted non-type template parameter. This should improve source fidelity, as well as being generically useful for diagnostics and such. llvm-svn: 135243
2011-07-15 13:09:51 +08:00
return transformNonTypeTemplateParmRef(E->getParameterPack(),
E->getParameterPackLocation(),
Arg);
Introduce a new expression kind, SubstNonTypeTemplateParmPackExpr, that captures the substitution of a non-type template argument pack for a non-type template parameter pack within a pack expansion that cannot be fully expanded. This follows the approach taken by SubstTemplateTypeParmPackType. llvm-svn: 123506
2011-01-15 09:15:58 +08:00
}
Extract a function to instantiate references to value template parameters. llvm-svn: 95491
2010-02-06 16:42:39 +08:00
[Concepts] Correctly form initial parameter mapping for parameter packs, support substitution into SubstNonTypeTemplateParmExpr We previously would not correctly for the initial parameter mapping for variadic template parameters in Concepts. Testing this lead to the discovery that with the normalization process we would need to substitute into already-substituted-into template arguments, which means we need to add NonTypeTemplateParmExpr support to TemplateInstantiator. We do that by substituting into the replacement and the type separately, and then re-checking the expression against the NTTP with the new type, in order to form any new required implicit casts (for cases where the type of the NTTP was dependent).
2020-01-31 21:55:06 +08:00
ExprResult
TemplateInstantiator::TransformSubstNonTypeTemplateParmExpr(
SubstNonTypeTemplateParmExpr *E) {
Ensure we don't strip the ConstantExpr carrying a non-type template argument's value off it during substitution.
2021-01-20 04:09:12 +08:00
ExprResult SubstReplacement = E->getReplacement();
if (!isa<ConstantExpr>(SubstReplacement.get()))
SubstReplacement = TransformExpr(E->getReplacement());
[Concepts] Correctly form initial parameter mapping for parameter packs, support substitution into SubstNonTypeTemplateParmExpr We previously would not correctly for the initial parameter mapping for variadic template parameters in Concepts. Testing this lead to the discovery that with the normalization process we would need to substitute into already-substituted-into template arguments, which means we need to add NonTypeTemplateParmExpr support to TemplateInstantiator. We do that by substituting into the replacement and the type separately, and then re-checking the expression against the NTTP with the new type, in order to form any new required implicit casts (for cases where the type of the NTTP was dependent).
2020-01-31 21:55:06 +08:00
if (SubstReplacement.isInvalid())
return true;
When re-checking an already-substituted template argument, don't lose the reference-ness of the parameter's type.
2020-11-04 06:02:56 +08:00
QualType SubstType = TransformType(E->getParameterType(getSema().Context));
[Concepts] Correctly form initial parameter mapping for parameter packs, support substitution into SubstNonTypeTemplateParmExpr We previously would not correctly for the initial parameter mapping for variadic template parameters in Concepts. Testing this lead to the discovery that with the normalization process we would need to substitute into already-substituted-into template arguments, which means we need to add NonTypeTemplateParmExpr support to TemplateInstantiator. We do that by substituting into the replacement and the type separately, and then re-checking the expression against the NTTP with the new type, in order to form any new required implicit casts (for cases where the type of the NTTP was dependent).
2020-01-31 21:55:06 +08:00
if (SubstType.isNull())
return true;
// The type may have been previously dependent and not now, which means we
// might have to implicit cast the argument to the new type, for example:
// template<auto T, decltype(T) U>
// concept C = sizeof(U) == 4;
// void foo() requires C<2, 'a'> { }
// When normalizing foo(), we first form the normalized constraints of C:
// AtomicExpr(sizeof(U) == 4,
// U=SubstNonTypeTemplateParmExpr(Param=U,
// Expr=DeclRef(U),
// Type=decltype(T)))
// Then we substitute T = 2, U = 'a' into the parameter mapping, and need to
// produce:
// AtomicExpr(sizeof(U) == 4,
// U=SubstNonTypeTemplateParmExpr(Param=U,
// Expr=ImpCast(
// decltype(2),
// SubstNTTPE(Param=U, Expr='a',
// Type=char)),
// Type=decltype(2)))
// The call to CheckTemplateArgument here produces the ImpCast.
TemplateArgument Converted;
if (SemaRef.CheckTemplateArgument(E->getParameter(), SubstType,
SubstReplacement.get(),
Converted).isInvalid())
return true;
return transformNonTypeTemplateParmRef(E->getParameter(),
E->getExprLoc(), Converted);
}
[c++20] P0780R2: Support pack-expansion of init-captures. This permits an init-capture to introduce a new pack: template<typename ...T> auto x = [...a = T()] { /* a is a pack */ }; To support this, the mechanism for allowing ParmVarDecls to be packs has been extended to support arbitrary local VarDecls. llvm-svn: 361300
2019-05-22 04:10:50 +08:00
ExprResult TemplateInstantiator::RebuildVarDeclRefExpr(VarDecl *PD,
SourceLocation Loc) {
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
DeclarationNameInfo NameInfo(PD->getDeclName(), Loc);
return getSema().BuildDeclarationNameExpr(CXXScopeSpec(), NameInfo, PD);
}
ExprResult
TemplateInstantiator::TransformFunctionParmPackExpr(FunctionParmPackExpr *E) {
if (getSema().ArgumentPackSubstitutionIndex != -1) {
// We can expand this parameter pack now.
[c++20] P0780R2: Support pack-expansion of init-captures. This permits an init-capture to introduce a new pack: template<typename ...T> auto x = [...a = T()] { /* a is a pack */ }; To support this, the mechanism for allowing ParmVarDecls to be packs has been extended to support arbitrary local VarDecls. llvm-svn: 361300
2019-05-22 04:10:50 +08:00
VarDecl *D = E->getExpansion(getSema().ArgumentPackSubstitutionIndex);
VarDecl *VD = cast_or_null<VarDecl>(TransformDecl(E->getExprLoc(), D));
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
if (!VD)
return ExprError();
[c++20] P0780R2: Support pack-expansion of init-captures. This permits an init-capture to introduce a new pack: template<typename ...T> auto x = [...a = T()] { /* a is a pack */ }; To support this, the mechanism for allowing ParmVarDecls to be packs has been extended to support arbitrary local VarDecls. llvm-svn: 361300
2019-05-22 04:10:50 +08:00
return RebuildVarDeclRefExpr(VD, E->getExprLoc());
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
}
QualType T = TransformType(E->getType());
if (T.isNull())
return ExprError();
// Transform each of the parameter expansions into the corresponding
// parameters in the instantiation of the function decl.
[c++20] P0780R2: Support pack-expansion of init-captures. This permits an init-capture to introduce a new pack: template<typename ...T> auto x = [...a = T()] { /* a is a pack */ }; To support this, the mechanism for allowing ParmVarDecls to be packs has been extended to support arbitrary local VarDecls. llvm-svn: 361300
2019-05-22 04:10:50 +08:00
SmallVector<VarDecl *, 8> Vars;
Vars.reserve(E->getNumExpansions());
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
for (FunctionParmPackExpr::iterator I = E->begin(), End = E->end();
I != End; ++I) {
[c++20] P0780R2: Support pack-expansion of init-captures. This permits an init-capture to introduce a new pack: template<typename ...T> auto x = [...a = T()] { /* a is a pack */ }; To support this, the mechanism for allowing ParmVarDecls to be packs has been extended to support arbitrary local VarDecls. llvm-svn: 361300
2019-05-22 04:10:50 +08:00
VarDecl *D = cast_or_null<VarDecl>(TransformDecl(E->getExprLoc(), *I));
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
if (!D)
return ExprError();
[c++20] P0780R2: Support pack-expansion of init-captures. This permits an init-capture to introduce a new pack: template<typename ...T> auto x = [...a = T()] { /* a is a pack */ }; To support this, the mechanism for allowing ParmVarDecls to be packs has been extended to support arbitrary local VarDecls. llvm-svn: 361300
2019-05-22 04:10:50 +08:00
Vars.push_back(D);
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
}
PR42104: Support instantiations of lambdas that implicitly capture packs. Two changes: * Track odr-use via FunctionParmPackExprs to properly handle dependent odr-uses of packs in generic lambdas. * Do not instantiate implicit captures; instead, regenerate them by instantiating the body of the lambda. This is necessary to distinguish between cases where only one element of a pack is captured and cases where the entire pack is captured. This reinstates r362358 (reverted in r362375) with a fix for an uninitialized variable use in UpdateMarkingForLValueToRValue. llvm-svn: 362531
2019-06-05 01:17:20 +08:00
auto *PackExpr =
FunctionParmPackExpr::Create(getSema().Context, T, E->getParameterPack(),
E->getParameterPackLocation(), Vars);
getSema().MarkFunctionParmPackReferenced(PackExpr);
return PackExpr;
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
}
ExprResult
TemplateInstantiator::TransformFunctionParmPackRefExpr(DeclRefExpr *E,
[c++20] P0780R2: Support pack-expansion of init-captures. This permits an init-capture to introduce a new pack: template<typename ...T> auto x = [...a = T()] { /* a is a pack */ }; To support this, the mechanism for allowing ParmVarDecls to be packs has been extended to support arbitrary local VarDecls. llvm-svn: 361300
2019-05-22 04:10:50 +08:00
VarDecl *PD) {
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
typedef LocalInstantiationScope::DeclArgumentPack DeclArgumentPack;
llvm::PointerUnion<Decl *, DeclArgumentPack *> *Found
= getSema().CurrentInstantiationScope->findInstantiationOf(PD);
assert(Found && "no instantiation for parameter pack");
Decl *TransformedDecl;
if (DeclArgumentPack *Pack = Found->dyn_cast<DeclArgumentPack *>()) {
Wrap to 80 columns. No behavior change. llvm-svn: 214059
2014-07-28 08:02:09 +08:00
// If this is a reference to a function parameter pack which we can
// substitute but can't yet expand, build a FunctionParmPackExpr for it.
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
if (getSema().ArgumentPackSubstitutionIndex == -1) {
QualType T = TransformType(E->getType());
if (T.isNull())
return ExprError();
PR42104: Support instantiations of lambdas that implicitly capture packs. Two changes: * Track odr-use via FunctionParmPackExprs to properly handle dependent odr-uses of packs in generic lambdas. * Do not instantiate implicit captures; instead, regenerate them by instantiating the body of the lambda. This is necessary to distinguish between cases where only one element of a pack is captured and cases where the entire pack is captured. This reinstates r362358 (reverted in r362375) with a fix for an uninitialized variable use in UpdateMarkingForLValueToRValue. llvm-svn: 362531
2019-06-05 01:17:20 +08:00
auto *PackExpr = FunctionParmPackExpr::Create(getSema().Context, T, PD,
E->getExprLoc(), *Pack);
getSema().MarkFunctionParmPackReferenced(PackExpr);
return PackExpr;
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
}
TransformedDecl = (*Pack)[getSema().ArgumentPackSubstitutionIndex];
} else {
TransformedDecl = Found->get<Decl*>();
}
// We have either an unexpanded pack or a specific expansion.
[c++20] P0780R2: Support pack-expansion of init-captures. This permits an init-capture to introduce a new pack: template<typename ...T> auto x = [...a = T()] { /* a is a pack */ }; To support this, the mechanism for allowing ParmVarDecls to be packs has been extended to support arbitrary local VarDecls. llvm-svn: 361300
2019-05-22 04:10:50 +08:00
return RebuildVarDeclRefExpr(cast<VarDecl>(TransformedDecl), E->getExprLoc());
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
}
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
Extract a function to instantiate references to value template parameters. llvm-svn: 95491
2010-02-06 16:42:39 +08:00
TemplateInstantiator::TransformDeclRefExpr(DeclRefExpr *E) {
NamedDecl *D = E->getDecl();
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
// Handle references to non-type template parameters and non-type template
// parameter packs.
Extract a function to instantiate references to value template parameters. llvm-svn: 95491
2010-02-06 16:42:39 +08:00
if (NonTypeTemplateParmDecl *NTTP = dyn_cast<NonTypeTemplateParmDecl>(D)) {
if (NTTP->getDepth() < TemplateArgs.getNumLevels())
return TransformTemplateParmRefExpr(E, NTTP);
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
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
// We have a non-type template parameter that isn't fully substituted;
// FindInstantiatedDecl will find it in the local instantiation scope.
Refactor the template-instantiation logic for expressions into a generic tree transformation (also used for recanonicalization) and a small amount of template-instantiation-specific logic. llvm-svn: 78645
2009-08-11 13:31:07 +08:00
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +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
// Handle references to function parameter packs.
[c++20] P0780R2: Support pack-expansion of init-captures. This permits an init-capture to introduce a new pack: template<typename ...T> auto x = [...a = T()] { /* a is a pack */ }; To support this, the mechanism for allowing ParmVarDecls to be packs has been extended to support arbitrary local VarDecls. llvm-svn: 361300
2019-05-22 04:10:50 +08:00
if (VarDecl *PD = dyn_cast<VarDecl>(D))
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
if (PD->isParameterPack())
return TransformFunctionParmPackRefExpr(E, PD);
The refactor of implicit member access expressions means we don't need this horrible isAddressOfOperand hack in TreeTransform, since that syntactic information is managed by the initial parser callbacks now. That's enough insomniac commits for one night. llvm-svn: 90849
2009-12-08 17:21:05 +08:00
return TreeTransform<TemplateInstantiator>::TransformDeclRefExpr(E);
Refactor the template-instantiation logic for expressions into a generic tree transformation (also used for recanonicalization) and a small amount of template-instantiation-specific logic. llvm-svn: 78645
2009-08-11 13:31:07 +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 TemplateInstantiator::TransformCXXDefaultArgExpr(
The refactor of implicit member access expressions means we don't need this horrible isAddressOfOperand hack in TreeTransform, since that syntactic information is managed by the initial parser callbacks now. That's enough insomniac commits for one night. llvm-svn: 90849
2009-12-08 17:21:05 +08:00
CXXDefaultArgExpr *E) {
Special-case default argument expression in instantiation. This should fix PR4301. Doug, please double-check my assumptions. Read the PR for more details. llvm-svn: 86465
2009-11-08 21:56:19 +08:00
assert(!cast<FunctionDecl>(E->getParam()->getDeclContext())->
getDescribedFunctionTemplate() &&
"Default arg expressions are never formed in dependent cases.");
When we see a CXXDefaultArgExpr during template instantiation, rebuild the default argument so that we're sure to mark any referenced declarations. This gets us another little step closer to fixing PR5810. llvm-svn: 92078
2009-12-24 07:03:06 +08:00
return SemaRef.BuildCXXDefaultArgExpr(E->getUsedLocation(),
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
cast<FunctionDecl>(E->getParam()->getDeclContext()),
When we see a CXXDefaultArgExpr during template instantiation, rebuild the default argument so that we're sure to mark any referenced declarations. This gets us another little step closer to fixing PR5810. llvm-svn: 92078
2009-12-24 07:03:06 +08:00
E->getParam());
Special-case default argument expression in instantiation. This should fix PR4301. Doug, please double-check my assumptions. Read the PR for more details. llvm-svn: 86465
2009-11-08 21:56:19 +08:00
}
Instantiate exception specifications when instantiating function types (other than the type of a function declaration). We previously didn't instantiate these at all! This also covers the pathological case where the only mention of a parameter pack is within the exception specification; this gives us a second way (other than alias templates) to reach the horrible state where a type contains an unexpanded pack, but its canonical type does not. This is a re-commit of r219977: r219977 was reverted in r220038 because it hit a wrong-code bug in GCC 4.7.2. (That's gcc.gnu.org/PR56135, and affects any implicit lambda-capture of 'this' within a template.) r219977 was a re-commit of r217995, r218011, and r218053: r217995 was reverted in r218058 because it hit a rejects-valid bug in MSVC. (Incorrect overload resolution in the presence of using-declarations.) It was re-committed in r219977 with a workaround for the MSVC rejects-valid. r218011 was a workaround for an MSVC parser bug. (Incorrect desugaring of unbraced range-based for loop). llvm-svn: 221750
2014-11-12 10:00:47 +08:00
template<typename Fn>
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
QualType TemplateInstantiator::TransformFunctionProtoType(TypeLocBuilder &TLB,
FunctionProtoTypeLoc TL,
CXXRecordDecl *ThisContext,
[OpenCL] Add generic AS to 'this' pointer Address spaces are cast into generic before invoking the constructor. Added support for a trailing Qualifiers object in FunctionProtoType. Note: This recommits the previously reverted patch, but now it is commited together with a fix for lldb. Differential Revision: https://reviews.llvm.org/D54862 llvm-svn: 349019
2018-12-13 18:15:27 +08:00
Qualifiers ThisTypeQuals,
Instantiate exception specifications when instantiating function types (other than the type of a function declaration). We previously didn't instantiate these at all! This also covers the pathological case where the only mention of a parameter pack is within the exception specification; this gives us a second way (other than alias templates) to reach the horrible state where a type contains an unexpanded pack, but its canonical type does not. This is a re-commit of r219977: r219977 was reverted in r220038 because it hit a wrong-code bug in GCC 4.7.2. (That's gcc.gnu.org/PR56135, and affects any implicit lambda-capture of 'this' within a template.) r219977 was a re-commit of r217995, r218011, and r218053: r217995 was reverted in r218058 because it hit a rejects-valid bug in MSVC. (Incorrect overload resolution in the presence of using-declarations.) It was re-committed in r219977 with a workaround for the MSVC rejects-valid. r218011 was a workaround for an MSVC parser bug. (Incorrect desugaring of unbraced range-based for loop). llvm-svn: 221750
2014-11-12 10:00:47 +08:00
Fn TransformExceptionSpec) {
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
// We need a local instantiation scope for this function prototype.
LocalInstantiationScope Scope(SemaRef, /*CombineWithOuterScope=*/true);
Instantiate exception specifications when instantiating function types (other than the type of a function declaration). We previously didn't instantiate these at all! This also covers the pathological case where the only mention of a parameter pack is within the exception specification; this gives us a second way (other than alias templates) to reach the horrible state where a type contains an unexpanded pack, but its canonical type does not. This is a re-commit of r219977: r219977 was reverted in r220038 because it hit a wrong-code bug in GCC 4.7.2. (That's gcc.gnu.org/PR56135, and affects any implicit lambda-capture of 'this' within a template.) r219977 was a re-commit of r217995, r218011, and r218053: r217995 was reverted in r218058 because it hit a rejects-valid bug in MSVC. (Incorrect overload resolution in the presence of using-declarations.) It was re-committed in r219977 with a workaround for the MSVC rejects-valid. r218011 was a workaround for an MSVC parser bug. (Incorrect desugaring of unbraced range-based for loop). llvm-svn: 221750
2014-11-12 10:00:47 +08:00
return inherited::TransformFunctionProtoType(
TLB, TL, ThisContext, ThisTypeQuals, TransformExceptionSpec);
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
}
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
ParmVarDecl *
Handle substitutions into function parameter packs whose patterns contain multiple parameter packs at different levels. llvm-svn: 123488
2011-01-15 06:40:04 +08:00
TemplateInstantiator::TransformFunctionTypeParam(ParmVarDecl *OldParm,
Store a parameter index and function prototype depth in every parameter node and use this to correctly mangle parameter references in function template signatures. A follow-up patch will improve the storage usage of these fields; here I've just done the lazy thing. llvm-svn: 130669
2011-05-02 06:35:37 +08:00
int indexAdjustment,
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,
When we're substituting into a function parameter pack and expect to get a function parameter pack (but don't due to weird substitutions), complain. Fixes the last bit of PR11848. llvm-svn: 148960
2012-01-26 00:15:54 +08:00
bool ExpectParameterPack) {
[OpenCL] Move addr space deduction to Sema. In order to simplify implementation we are moving add space deduction into Sema while constructing variable declaration and on template instantiation. Pointee are deduced to generic addr space during creation of types. This commit also - fixed addr space dedution for auto type; - factors out in a separate helper function OpenCL specific logic from type diagnostics in var decl. Tags: #clang Differential Revision: https://reviews.llvm.org/D65744
2019-11-27 19:03:11 +08:00
auto NewParm =
SemaRef.SubstParmVarDecl(OldParm, TemplateArgs, indexAdjustment,
NumExpansions, ExpectParameterPack);
if (NewParm && SemaRef.getLangOpts().OpenCL)
SemaRef.deduceOpenCLAddressSpace(NewParm);
return NewParm;
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
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
QualType
Rewrite TreeTransform to transform types as DeclaratorInfos rather than as bare QualTypes. Don't actually exploit this yet. llvm-svn: 84716
2009-10-21 08:40:46 +08:00
TemplateInstantiator::TransformTemplateTypeParmType(TypeLocBuilder &TLB,
Replace one hack with a different hack: strip out the ObjectType parameters to the Transform*Type functions and instead call out the specific cases where an object type and the unqualified lookup results are important. Fixes an assert and failed compile on a testcase from PR7248. llvm-svn: 118887
2010-11-12 16:19:04 +08:00
TemplateTypeParmTypeLoc TL) {
Change QualType::getTypePtr() to return a const pointer, then change a thousand other things which were (generally inadvertantly) relying on that. llvm-svn: 123814
2011-01-19 14:33:43 +08:00
const TemplateTypeParmType *T = TL.getTypePtr();
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
if (T->getDepth() < TemplateArgs.getNumLevels()) {
Implement the basic approach for instantiating types, with a lot of FIXME'd stubs for those types we don't yet know how to instantiate (everything that isn't a template parameter!). We now instantiate default arguments for template type parameters when needed. This will be our testbed while I fill out the remaining type-instantiation logic. llvm-svn: 65649
2009-02-28 03:31:52 +08:00
// Replace the template type parameter with its corresponding
// template argument.
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
// If the corresponding template argument is NULL or doesn't exist, it's
// because we are performing instantiation from explicitly-specified
// template arguments in a function template class, but there were some
Cope with explicitly-specified function template arguments when there are fewer template arguments than there are template parameters for that function. llvm-svn: 74578
2009-07-01 08:28:38 +08:00
// arguments left unspecified.
Rewrite TreeTransform to transform types as DeclaratorInfos rather than as bare QualTypes. Don't actually exploit this yet. llvm-svn: 84716
2009-10-21 08:40:46 +08:00
if (!TemplateArgs.hasTemplateArgument(T->getDepth(), T->getIndex())) {
TemplateTypeParmTypeLoc NewTL
= TLB.push<TemplateTypeParmTypeLoc>(TL.getType());
NewTL.setNameLoc(TL.getNameLoc());
return TL.getType();
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Implement basic support for template instantiation of pack expansions whose patterns are template arguments. We can now instantiate, e.g., typedef tuple<pair<OuterTypes, InnerTypes>...> type; where OuterTypes and InnerTypes are template type parameter packs. There is a horrible inefficiency in TemplateArgumentLoc::getPackExpansionPattern(), where we need to create copies of TypeLoc data because our interfaces traffic in TypeSourceInfo pointers where they should traffic in TypeLocs instead. I've isolated in efficiency in this one routine; once we refactor our interfaces to traffic in TypeLocs, we can eliminate it. llvm-svn: 122278
2010-12-21 06:05:00 +08:00
TemplateArgument Arg = TemplateArgs(T->getDepth(), T->getIndex());
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
Distinguish between template parameter substitutions that are forming specializations and those that are done as part of rewrites. Do not create Subst* nodes in the latter. We previously had a hybrid of these two behaviors where we would only create some Subst* nodes but not others during deduction guide rewrites. No functional change intended, but the resulting ASTs are more principled.
2020-06-23 10:30:36 +08:00
if (TemplateArgs.isRewrite()) {
// We're rewriting the template parameter as a reference to another
// template parameter.
if (Arg.getKind() == TemplateArgument::Pack) {
assert(Arg.pack_size() == 1 && Arg.pack_begin()->isPackExpansion() &&
"unexpected pack arguments in template rewrite");
Arg = Arg.pack_begin()->getPackExpansionPattern();
}
assert(Arg.getKind() == TemplateArgument::Type &&
"unexpected nontype template argument kind in template rewrite");
QualType NewT = Arg.getAsType();
assert(isa<TemplateTypeParmType>(NewT) &&
"type parm not rewritten to type parm");
auto NewTL = TLB.push<TemplateTypeParmTypeLoc>(NewT);
NewTL.setNameLoc(TL.getNameLoc());
return NewT;
}
Implement basic support for template instantiation of pack expansions whose patterns are template arguments. We can now instantiate, e.g., typedef tuple<pair<OuterTypes, InnerTypes>...> type; where OuterTypes and InnerTypes are template type parameter packs. There is a horrible inefficiency in TemplateArgumentLoc::getPackExpansionPattern(), where we need to create copies of TypeLoc data because our interfaces traffic in TypeSourceInfo pointers where they should traffic in TypeLocs instead. I've isolated in efficiency in this one routine; once we refactor our interfaces to traffic in TypeLocs, we can eliminate it. llvm-svn: 122278
2010-12-21 06:05:00 +08:00
if (T->isParameterPack()) {
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
assert(Arg.getKind() == TemplateArgument::Pack &&
Implement basic support for template instantiation of pack expansions whose patterns are template arguments. We can now instantiate, e.g., typedef tuple<pair<OuterTypes, InnerTypes>...> type; where OuterTypes and InnerTypes are template type parameter packs. There is a horrible inefficiency in TemplateArgumentLoc::getPackExpansionPattern(), where we need to create copies of TypeLoc data because our interfaces traffic in TypeSourceInfo pointers where they should traffic in TypeLocs instead. I've isolated in efficiency in this one routine; once we refactor our interfaces to traffic in TypeLocs, we can eliminate it. llvm-svn: 122278
2010-12-21 06:05:00 +08:00
"Missing argument pack");
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
Implement basic support for template instantiation of pack expansions whose patterns are template arguments. We can now instantiate, e.g., typedef tuple<pair<OuterTypes, InnerTypes>...> type; where OuterTypes and InnerTypes are template type parameter packs. There is a horrible inefficiency in TemplateArgumentLoc::getPackExpansionPattern(), where we need to create copies of TypeLoc data because our interfaces traffic in TypeSourceInfo pointers where they should traffic in TypeLocs instead. I've isolated in efficiency in this one routine; once we refactor our interfaces to traffic in TypeLocs, we can eliminate it. llvm-svn: 122278
2010-12-21 06:05:00 +08:00
if (getSema().ArgumentPackSubstitutionIndex == -1) {
Start implementing support for substitution into pack expansions that involve template parameter packs at multiple template levels that occur within the signatures members of class templates (and partial specializations thereof). This is a work-in-progress that is deficient in several ways, notably: - It only works for template type parameter packs, but we need to also support non-type template parameter packs and template template parameter packs. - It doesn't keep track of the lengths of the substituted argument packs in the expansion, so it can't properly diagnose length mismatches. However, this is a concrete step in the right direction. llvm-svn: 123425
2011-01-14 10:55:32 +08:00
// We have the template argument pack, but we're not expanding the
// enclosing pack expansion yet. Just save the template argument
// pack for later substitution.
QualType Result
= getSema().Context.getSubstTemplateTypeParmPackType(T, Arg);
SubstTemplateTypeParmPackTypeLoc NewTL
= TLB.push<SubstTemplateTypeParmPackTypeLoc>(Result);
NewTL.setNameLoc(TL.getNameLoc());
return Result;
Implement basic support for template instantiation of pack expansions whose patterns are template arguments. We can now instantiate, e.g., typedef tuple<pair<OuterTypes, InnerTypes>...> type; where OuterTypes and InnerTypes are template type parameter packs. There is a horrible inefficiency in TemplateArgumentLoc::getPackExpansionPattern(), where we need to create copies of TypeLoc data because our interfaces traffic in TypeSourceInfo pointers where they should traffic in TypeLocs instead. I've isolated in efficiency in this one routine; once we refactor our interfaces to traffic in TypeLocs, we can eliminate it. llvm-svn: 122278
2010-12-21 06:05:00 +08:00
}
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
Fix for template substitution with packs. When we see a pack, and replace it with a template argument which is also a pack, we want to use the pack pattern, not the expanded pack. The caller should take care of expanding the pack afterwards. Fixes PR16646. llvm-svn: 186713
2013-07-20 03:40:38 +08:00
Arg = getPackSubstitutedTemplateArgument(getSema(), Arg);
Implement basic support for template instantiation of pack expansions whose patterns are template arguments. We can now instantiate, e.g., typedef tuple<pair<OuterTypes, InnerTypes>...> type; where OuterTypes and InnerTypes are template type parameter packs. There is a horrible inefficiency in TemplateArgumentLoc::getPackExpansionPattern(), where we need to create copies of TypeLoc data because our interfaces traffic in TypeSourceInfo pointers where they should traffic in TypeLocs instead. I've isolated in efficiency in this one routine; once we refactor our interfaces to traffic in TypeLocs, we can eliminate it. llvm-svn: 122278
2010-12-21 06:05:00 +08:00
}
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
Implement basic support for template instantiation of pack expansions whose patterns are template arguments. We can now instantiate, e.g., typedef tuple<pair<OuterTypes, InnerTypes>...> type; where OuterTypes and InnerTypes are template type parameter packs. There is a horrible inefficiency in TemplateArgumentLoc::getPackExpansionPattern(), where we need to create copies of TypeLoc data because our interfaces traffic in TypeSourceInfo pointers where they should traffic in TypeLocs instead. I've isolated in efficiency in this one routine; once we refactor our interfaces to traffic in TypeLocs, we can eliminate it. llvm-svn: 122278
2010-12-21 06:05:00 +08:00
assert(Arg.getKind() == TemplateArgument::Type &&
Implement the basic approach for instantiating types, with a lot of FIXME'd stubs for those types we don't yet know how to instantiate (everything that isn't a template parameter!). We now instantiate default arguments for template type parameters when needed. This will be our testbed while I fill out the remaining type-instantiation logic. llvm-svn: 65649
2009-02-28 03:31:52 +08:00
"Template argument kind mismatch");
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
Implement basic support for template instantiation of pack expansions whose patterns are template arguments. We can now instantiate, e.g., typedef tuple<pair<OuterTypes, InnerTypes>...> type; where OuterTypes and InnerTypes are template type parameter packs. There is a horrible inefficiency in TemplateArgumentLoc::getPackExpansionPattern(), where we need to create copies of TypeLoc data because our interfaces traffic in TypeSourceInfo pointers where they should traffic in TypeLocs instead. I've isolated in efficiency in this one routine; once we refactor our interfaces to traffic in TypeLocs, we can eliminate it. llvm-svn: 122278
2010-12-21 06:05:00 +08:00
QualType Replacement = Arg.getAsType();
When performing template-substitution into a type, don't just replace the TemplateTypeParmType with the substituted type directly; instead, replace it with a SubstTemplateTypeParmType which will note that the type was originally written as a template type parameter. This makes it reasonable to preserve source information even through template substitution. Also define the new SubstTemplateTypeParmType class, obviously. For consistency with current behavior, we stringize these types as if they were the underlying type. I'm not sure this is the right thing to do. At any rate, I paled at adding yet another clause to the don't-desugar 'if' statement, so I extracted a function to do it. The new function also does The Right Thing more often, I think: e.g. if we have a chain of typedefs leading to a vector type, we will now desugar all but the last one. llvm-svn: 84412
2009-10-18 17:09:24 +08:00
// TODO: only do this uniquing once, at the start of instantiation.
Rewrite TreeTransform to transform types as DeclaratorInfos rather than as bare QualTypes. Don't actually exploit this yet. llvm-svn: 84716
2009-10-21 08:40:46 +08:00
QualType Result
= getSema().Context.getSubstTemplateTypeParmType(T, Replacement);
SubstTemplateTypeParmTypeLoc NewTL
= TLB.push<SubstTemplateTypeParmTypeLoc>(Result);
NewTL.setNameLoc(TL.getNameLoc());
return Result;
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
}
Implement the basic approach for instantiating types, with a lot of FIXME'd stubs for those types we don't yet know how to instantiate (everything that isn't a template parameter!). We now instantiate default arguments for template type parameters when needed. This will be our testbed while I fill out the remaining type-instantiation logic. llvm-svn: 65649
2009-02-28 03:31:52 +08:00
// The template type parameter comes from an inner template (e.g.,
// the template parameter list of a member template inside the
// template we are instantiating). Create a new template type
// parameter with the template "level" reduced by one.
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
TemplateTypeParmDecl *NewTTPDecl = nullptr;
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
if (TemplateTypeParmDecl *OldTTPDecl = T->getDecl())
NewTTPDecl = cast_or_null<TemplateTypeParmDecl>(
TransformDecl(TL.getNameLoc(), OldTTPDecl));
PR32010: Fix template argument depth mixup when forming implicit constructor template deduction guides for class template argument deduction. Ensure that we have a local instantiation scope for tracking the instantiated parameters. Additionally, unusually, we're substituting at depth 1 and leaving depth 0 alone; make sure that we don't reduce template parameter depth by 2 for inner parameters in the process. (This is probably also broken for alias templates in the case where they're expanded within a dependent context, but this patch doesn't fix that.) llvm-svn: 295696
2017-02-21 14:30:38 +08:00
QualType Result = getSema().Context.getTemplateTypeParmType(
T->getDepth() - TemplateArgs.getNumSubstitutedLevels(), T->getIndex(),
T->isParameterPack(), NewTTPDecl);
Rewrite TreeTransform to transform types as DeclaratorInfos rather than as bare QualTypes. Don't actually exploit this yet. llvm-svn: 84716
2009-10-21 08:40:46 +08:00
TemplateTypeParmTypeLoc NewTL = TLB.push<TemplateTypeParmTypeLoc>(Result);
NewTL.setNameLoc(TL.getNameLoc());
return Result;
Start implementing support for substitution into pack expansions that involve template parameter packs at multiple template levels that occur within the signatures members of class templates (and partial specializations thereof). This is a work-in-progress that is deficient in several ways, notably: - It only works for template type parameter packs, but we need to also support non-type template parameter packs and template template parameter packs. - It doesn't keep track of the lengths of the substituted argument packs in the expansion, so it can't properly diagnose length mismatches. However, this is a concrete step in the right direction. llvm-svn: 123425
2011-01-14 10:55:32 +08:00
}
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
QualType
Start implementing support for substitution into pack expansions that involve template parameter packs at multiple template levels that occur within the signatures members of class templates (and partial specializations thereof). This is a work-in-progress that is deficient in several ways, notably: - It only works for template type parameter packs, but we need to also support non-type template parameter packs and template template parameter packs. - It doesn't keep track of the lengths of the substituted argument packs in the expansion, so it can't properly diagnose length mismatches. However, this is a concrete step in the right direction. llvm-svn: 123425
2011-01-14 10:55:32 +08:00
TemplateInstantiator::TransformSubstTemplateTypeParmPackType(
TypeLocBuilder &TLB,
SubstTemplateTypeParmPackTypeLoc TL) {
if (getSema().ArgumentPackSubstitutionIndex == -1) {
// We aren't expanding the parameter pack, so just return ourselves.
SubstTemplateTypeParmPackTypeLoc NewTL
= TLB.push<SubstTemplateTypeParmPackTypeLoc>(TL.getType());
NewTL.setNameLoc(TL.getNameLoc());
return TL.getType();
}
Fix for template substitution with packs. When we see a pack, and replace it with a template argument which is also a pack, we want to use the pack pattern, not the expanded pack. The caller should take care of expanding the pack afterwards. Fixes PR16646. llvm-svn: 186713
2013-07-20 03:40:38 +08:00
TemplateArgument Arg = TL.getTypePtr()->getArgumentPack();
Arg = getPackSubstitutedTemplateArgument(getSema(), Arg);
QualType Result = Arg.getAsType();
Start implementing support for substitution into pack expansions that involve template parameter packs at multiple template levels that occur within the signatures members of class templates (and partial specializations thereof). This is a work-in-progress that is deficient in several ways, notably: - It only works for template type parameter packs, but we need to also support non-type template parameter packs and template template parameter packs. - It doesn't keep track of the lengths of the substituted argument packs in the expansion, so it can't properly diagnose length mismatches. However, this is a concrete step in the right direction. llvm-svn: 123425
2011-01-14 10:55:32 +08:00
Result = getSema().Context.getSubstTemplateTypeParmType(
TL.getTypePtr()->getReplacedParameter(),
Result);
SubstTemplateTypeParmTypeLoc NewTL
= TLB.push<SubstTemplateTypeParmTypeLoc>(Result);
NewTL.setNameLoc(TL.getNameLoc());
return Result;
Implement template instantiation for pointer, reference, and (some) array types. Semantic checking for the construction of these types has been factored out of GetTypeForDeclarator and into separate subroutines (BuildPointerType, BuildReferenceType, BuildArrayType). We'll be doing the same thing for all other types (and declarations and expressions). As part of this, moved the type-instantiation functions into a class in an anonymous namespace. llvm-svn: 65663
2009-02-28 08:25:32 +08:00
}
Implement the basic approach for instantiating types, with a lot of FIXME'd stubs for those types we don't yet know how to instantiate (everything that isn't a template parameter!). We now instantiate default arguments for template type parameters when needed. This will be our testbed while I fill out the remaining type-instantiation logic. llvm-svn: 65649
2009-02-28 03:31:52 +08:00
[Concepts] Requires Expressions Implement support for C++2a requires-expressions. Re-commit after compilation failure on some platforms due to alignment issues with PointerIntPair. Differential Revision: https://reviews.llvm.org/D50360
2020-01-18 15:11:43 +08:00
template<typename EntityPrinter>
static concepts::Requirement::SubstitutionDiagnostic *
createSubstDiag(Sema &S, TemplateDeductionInfo &Info, EntityPrinter Printer) {
SmallString<128> Message;
SourceLocation ErrorLoc;
if (Info.hasSFINAEDiagnostic()) {
PartialDiagnosticAt PDA(SourceLocation(),
PartialDiagnostic::NullDiagnostic{});
Info.takeSFINAEDiagnostic(PDA);
PDA.second.EmitToString(S.getDiagnostics(), Message);
ErrorLoc = PDA.first;
} else {
ErrorLoc = Info.getLocation();
}
char *MessageBuf = new (S.Context) char[Message.size()];
std::copy(Message.begin(), Message.end(), MessageBuf);
SmallString<128> Entity;
llvm::raw_svector_ostream OS(Entity);
Printer(OS);
char *EntityBuf = new (S.Context) char[Entity.size()];
std::copy(Entity.begin(), Entity.end(), EntityBuf);
return new (S.Context) concepts::Requirement::SubstitutionDiagnostic{
StringRef(EntityBuf, Entity.size()), ErrorLoc,
StringRef(MessageBuf, Message.size())};
}
concepts::TypeRequirement *
TemplateInstantiator::TransformTypeRequirement(concepts::TypeRequirement *Req) {
if (!Req->isDependent() && !AlwaysRebuild())
return Req;
if (Req->isSubstitutionFailure()) {
if (AlwaysRebuild())
return RebuildTypeRequirement(
Req->getSubstitutionDiagnostic());
return Req;
}
Sema::SFINAETrap Trap(SemaRef);
TemplateDeductionInfo Info(Req->getType()->getTypeLoc().getBeginLoc());
Sema::InstantiatingTemplate TypeInst(SemaRef,
Req->getType()->getTypeLoc().getBeginLoc(), Req, Info,
Req->getType()->getTypeLoc().getSourceRange());
if (TypeInst.isInvalid())
return nullptr;
TypeSourceInfo *TransType = TransformType(Req->getType());
if (!TransType || Trap.hasErrorOccurred())
return RebuildTypeRequirement(createSubstDiag(SemaRef, Info,
[&] (llvm::raw_ostream& OS) {
Req->getType()->getType().print(OS, SemaRef.getPrintingPolicy());
}));
return RebuildTypeRequirement(TransType);
}
concepts::ExprRequirement *
TemplateInstantiator::TransformExprRequirement(concepts::ExprRequirement *Req) {
if (!Req->isDependent() && !AlwaysRebuild())
return Req;
Sema::SFINAETrap Trap(SemaRef);
llvm::PointerUnion<Expr *, concepts::Requirement::SubstitutionDiagnostic *>
TransExpr;
if (Req->isExprSubstitutionFailure())
TransExpr = Req->getExprSubstitutionDiagnostic();
else {
[clang] fix crash on template instantiation of invalid requires expressions See PR48656. The implementation of the template instantiation of requires expressions was incorrectly trying to get the expression from an 'ExprRequirement' before checking if it was an error state. Signed-off-by: Matheus Izvekov <mizvekov@gmail.com> Reviewed By: rsmith Differential Revision: https://reviews.llvm.org/D107399
2021-08-04 04:10:34 +08:00
Expr *E = Req->getExpr();
TemplateDeductionInfo Info(E->getBeginLoc());
Sema::InstantiatingTemplate ExprInst(SemaRef, E->getBeginLoc(), Req, Info,
E->getSourceRange());
[Concepts] Requires Expressions Implement support for C++2a requires-expressions. Re-commit after compilation failure on some platforms due to alignment issues with PointerIntPair. Differential Revision: https://reviews.llvm.org/D50360
2020-01-18 15:11:43 +08:00
if (ExprInst.isInvalid())
return nullptr;
[clang] fix crash on template instantiation of invalid requires expressions See PR48656. The implementation of the template instantiation of requires expressions was incorrectly trying to get the expression from an 'ExprRequirement' before checking if it was an error state. Signed-off-by: Matheus Izvekov <mizvekov@gmail.com> Reviewed By: rsmith Differential Revision: https://reviews.llvm.org/D107399
2021-08-04 04:10:34 +08:00
ExprResult TransExprRes = TransformExpr(E);
[Concepts] Requires Expressions Implement support for C++2a requires-expressions. Re-commit after compilation failure on some platforms due to alignment issues with PointerIntPair. Differential Revision: https://reviews.llvm.org/D50360
2020-01-18 15:11:43 +08:00
if (TransExprRes.isInvalid() || Trap.hasErrorOccurred())
[clang] fix crash on template instantiation of invalid requires expressions See PR48656. The implementation of the template instantiation of requires expressions was incorrectly trying to get the expression from an 'ExprRequirement' before checking if it was an error state. Signed-off-by: Matheus Izvekov <mizvekov@gmail.com> Reviewed By: rsmith Differential Revision: https://reviews.llvm.org/D107399
2021-08-04 04:10:34 +08:00
TransExpr = createSubstDiag(SemaRef, Info, [&](llvm::raw_ostream &OS) {
E->printPretty(OS, nullptr, SemaRef.getPrintingPolicy());
});
[Concepts] Requires Expressions Implement support for C++2a requires-expressions. Re-commit after compilation failure on some platforms due to alignment issues with PointerIntPair. Differential Revision: https://reviews.llvm.org/D50360
2020-01-18 15:11:43 +08:00
else
TransExpr = TransExprRes.get();
}
llvm::Optional<concepts::ExprRequirement::ReturnTypeRequirement> TransRetReq;
const auto &RetReq = Req->getReturnTypeRequirement();
if (RetReq.isEmpty())
TransRetReq.emplace();
else if (RetReq.isSubstitutionFailure())
TransRetReq.emplace(RetReq.getSubstitutionDiagnostic());
else if (RetReq.isTypeConstraint()) {
TemplateParameterList *OrigTPL =
RetReq.getTypeConstraintTemplateParameterList();
[clang] fix crash on template instantiation of invalid requires expressions See PR48656. The implementation of the template instantiation of requires expressions was incorrectly trying to get the expression from an 'ExprRequirement' before checking if it was an error state. Signed-off-by: Matheus Izvekov <mizvekov@gmail.com> Reviewed By: rsmith Differential Revision: https://reviews.llvm.org/D107399
2021-08-04 04:10:34 +08:00
TemplateDeductionInfo Info(OrigTPL->getTemplateLoc());
[Concepts] Requires Expressions Implement support for C++2a requires-expressions. Re-commit after compilation failure on some platforms due to alignment issues with PointerIntPair. Differential Revision: https://reviews.llvm.org/D50360
2020-01-18 15:11:43 +08:00
Sema::InstantiatingTemplate TPLInst(SemaRef, OrigTPL->getTemplateLoc(),
Req, Info, OrigTPL->getSourceRange());
if (TPLInst.isInvalid())
return nullptr;
TemplateParameterList *TPL =
TransformTemplateParameterList(OrigTPL);
if (!TPL)
TransRetReq.emplace(createSubstDiag(SemaRef, Info,
[&] (llvm::raw_ostream& OS) {
RetReq.getTypeConstraint()->getImmediatelyDeclaredConstraint()
->printPretty(OS, nullptr, SemaRef.getPrintingPolicy());
}));
else {
TPLInst.Clear();
TransRetReq.emplace(TPL);
}
}
assert(TransRetReq.hasValue() &&
"All code paths leading here must set TransRetReq");
if (Expr *E = TransExpr.dyn_cast<Expr *>())
return RebuildExprRequirement(E, Req->isSimple(), Req->getNoexceptLoc(),
std::move(*TransRetReq));
return RebuildExprRequirement(
TransExpr.get<concepts::Requirement::SubstitutionDiagnostic *>(),
Req->isSimple(), Req->getNoexceptLoc(), std::move(*TransRetReq));
}
concepts::NestedRequirement *
TemplateInstantiator::TransformNestedRequirement(
concepts::NestedRequirement *Req) {
if (!Req->isDependent() && !AlwaysRebuild())
return Req;
if (Req->isSubstitutionFailure()) {
if (AlwaysRebuild())
return RebuildNestedRequirement(
Req->getSubstitutionDiagnostic());
return Req;
}
Sema::InstantiatingTemplate ReqInst(SemaRef,
Req->getConstraintExpr()->getBeginLoc(), Req,
Sema::InstantiatingTemplate::ConstraintsCheck{},
Req->getConstraintExpr()->getSourceRange());
ExprResult TransConstraint;
TemplateDeductionInfo Info(Req->getConstraintExpr()->getBeginLoc());
{
EnterExpressionEvaluationContext ContextRAII(
SemaRef, Sema::ExpressionEvaluationContext::ConstantEvaluated);
Sema::SFINAETrap Trap(SemaRef);
Sema::InstantiatingTemplate ConstrInst(SemaRef,
Req->getConstraintExpr()->getBeginLoc(), Req, Info,
Req->getConstraintExpr()->getSourceRange());
if (ConstrInst.isInvalid())
return nullptr;
TransConstraint = TransformExpr(Req->getConstraintExpr());
if (TransConstraint.isInvalid() || Trap.hasErrorOccurred())
return RebuildNestedRequirement(createSubstDiag(SemaRef, Info,
[&] (llvm::raw_ostream& OS) {
Req->getConstraintExpr()->printPretty(OS, nullptr,
SemaRef.getPrintingPolicy());
}));
}
return RebuildNestedRequirement(TransConstraint.get());
}
Remove \brief commands from doxygen comments. This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
2018-05-09 09:00:01 +08:00
/// Perform substitution on the type T with a given set of template
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
/// arguments.
Implement the basic approach for instantiating types, with a lot of FIXME'd stubs for those types we don't yet know how to instantiate (everything that isn't a template parameter!). We now instantiate default arguments for template type parameters when needed. This will be our testbed while I fill out the remaining type-instantiation logic. llvm-svn: 65649
2009-02-28 03:31:52 +08:00
///
/// This routine substitutes the given template arguments into the
/// type T and produces the instantiated type.
///
/// \param T the type into which the template arguments will be
/// substituted. If this type is not dependent, it will be returned
/// immediately.
///
Still more Doxygen documentation fixes: * Escape #, < and @ symbols where Doxygen would try to interpret them; * Fix several function param documentation where names had got out of sync; * Delete param documentation referring to parameters that no longer exist. llvm-svn: 158472
2012-06-15 05:40:34 +08:00
/// \param Args the template arguments that will be
Implement the basic approach for instantiating types, with a lot of FIXME'd stubs for those types we don't yet know how to instantiate (everything that isn't a template parameter!). We now instantiate default arguments for template type parameters when needed. This will be our testbed while I fill out the remaining type-instantiation logic. llvm-svn: 65649
2009-02-28 03:31:52 +08:00
/// substituted for the top-level template parameters within T.
///
/// \param Loc the location in the source code where this substitution
/// is being performed. It will typically be the location of the
/// declarator (if we're instantiating the type of some declaration)
/// or the location of the type in the source code (if, e.g., we're
/// instantiating the type of a cast expression).
///
/// \param Entity the name of the entity associated with a declaration
/// being instantiated (if any). May be empty to indicate that there
/// is no such entity (if, e.g., this is a type that occurs as part of
/// a cast expression) or that the entity has no name (e.g., an
/// unnamed function parameter).
///
Towards P0091R3: parsing support for class template argument deduction in typename-specifiers. This reinstates r293455, reverted in r293455, with a fix for cv-qualifier handling on dependent typename-specifiers. llvm-svn: 293544
2017-01-31 04:39:26 +08:00
/// \param AllowDeducedTST Whether a DeducedTemplateSpecializationType is
/// acceptable as the top level type of the result.
///
Implement the basic approach for instantiating types, with a lot of FIXME'd stubs for those types we don't yet know how to instantiate (everything that isn't a template parameter!). We now instantiate default arguments for template type parameters when needed. This will be our testbed while I fill out the remaining type-instantiation logic. llvm-svn: 65649
2009-02-28 03:31:52 +08:00
/// \returns If the instantiation succeeds, the instantiated
/// type. Otherwise, produces diagnostics and returns a NULL type.
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 *Sema::SubstType(TypeSourceInfo *T,
Clone Sema::SubstType for DeclaratorInfos. llvm-svn: 84724
2009-10-21 08:58:09 +08:00
const MultiLevelTemplateArgumentList &Args,
SourceLocation Loc,
Towards P0091R3: parsing support for class template argument deduction in typename-specifiers. This reinstates r293455, reverted in r293455, with a fix for cv-qualifier handling on dependent typename-specifiers. llvm-svn: 293544
2017-01-31 04:39:26 +08:00
DeclarationName Entity,
bool AllowDeducedTST) {
Rename ActiveTemplateInstantiation to CodeSynthesisContext in preparation for using it for other kinds of context (where we currently produce context notes in a highly ad-hoc manner). llvm-svn: 295919
2017-02-23 09:43:54 +08:00
assert(!CodeSynthesisContexts.empty() &&
Clone Sema::SubstType for DeclaratorInfos. llvm-svn: 84724
2009-10-21 08:58:09 +08:00
"Cannot perform an instantiation without some context on the "
"instantiation stack");
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
if (!T->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
!T->getType()->isVariablyModifiedType())
Clone Sema::SubstType for DeclaratorInfos. llvm-svn: 84724
2009-10-21 08:58:09 +08:00
return T;
TemplateInstantiator Instantiator(*this, Args, Loc, Entity);
Towards P0091R3: parsing support for class template argument deduction in typename-specifiers. This reinstates r293455, reverted in r293455, with a fix for cv-qualifier handling on dependent typename-specifiers. llvm-svn: 293544
2017-01-31 04:39:26 +08:00
return AllowDeducedTST ? Instantiator.TransformTypeWithDeducedTST(T)
: Instantiator.TransformType(T);
Clone Sema::SubstType for DeclaratorInfos. llvm-svn: 84724
2009-10-21 08:58:09 +08:00
}
Initial implementation of function parameter packs. This implementation allows: 1) Declaration of function parameter packs 2) Instantiation of function parameter packs within function types. 3) Template argument deduction of function parameter packs when matching two function types. We're missing all of the important template-instantiation logic for function template definitions, along with template argument deduction from the argument list of a function call, so don't even think of trying to use these for real yet. llvm-svn: 122926
2011-01-06 07:12:31 +08:00
TypeSourceInfo *Sema::SubstType(TypeLoc TL,
const MultiLevelTemplateArgumentList &Args,
SourceLocation Loc,
DeclarationName Entity) {
Rename ActiveTemplateInstantiation to CodeSynthesisContext in preparation for using it for other kinds of context (where we currently produce context notes in a highly ad-hoc manner). llvm-svn: 295919
2017-02-23 09:43:54 +08:00
assert(!CodeSynthesisContexts.empty() &&
Initial implementation of function parameter packs. This implementation allows: 1) Declaration of function parameter packs 2) Instantiation of function parameter packs within function types. 3) Template argument deduction of function parameter packs when matching two function types. We're missing all of the important template-instantiation logic for function template definitions, along with template argument deduction from the argument list of a function call, so don't even think of trying to use these for real yet. llvm-svn: 122926
2011-01-06 07:12:31 +08:00
"Cannot perform an instantiation without some context on the "
"instantiation stack");
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
Initial implementation of function parameter packs. This implementation allows: 1) Declaration of function parameter packs 2) Instantiation of function parameter packs within function types. 3) Template argument deduction of function parameter packs when matching two function types. We're missing all of the important template-instantiation logic for function template definitions, along with template argument deduction from the argument list of a function call, so don't even think of trying to use these for real yet. llvm-svn: 122926
2011-01-06 07:12:31 +08:00
if (TL.getType().isNull())
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Initial implementation of function parameter packs. This implementation allows: 1) Declaration of function parameter packs 2) Instantiation of function parameter packs within function types. 3) Template argument deduction of function parameter packs when matching two function types. We're missing all of the important template-instantiation logic for function template definitions, along with template argument deduction from the argument list of a function call, so don't even think of trying to use these for real yet. llvm-svn: 122926
2011-01-06 07:12:31 +08:00
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
if (!TL.getType()->isInstantiationDependentType() &&
Initial implementation of function parameter packs. This implementation allows: 1) Declaration of function parameter packs 2) Instantiation of function parameter packs within function types. 3) Template argument deduction of function parameter packs when matching two function types. We're missing all of the important template-instantiation logic for function template definitions, along with template argument deduction from the argument list of a function call, so don't even think of trying to use these for real yet. llvm-svn: 122926
2011-01-06 07:12:31 +08:00
!TL.getType()->isVariablyModifiedType()) {
// FIXME: Make a copy of the TypeLoc data here, so that we can
// return a new TypeSourceInfo. Inefficient!
TypeLocBuilder TLB;
TLB.pushFullCopy(TL);
return TLB.getTypeSourceInfo(Context, TL.getType());
}
TemplateInstantiator Instantiator(*this, Args, Loc, Entity);
TypeLocBuilder TLB;
TLB.reserve(TL.getFullDataSize());
QualType Result = Instantiator.TransformType(TLB, TL);
if (Result.isNull())
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Initial implementation of function parameter packs. This implementation allows: 1) Declaration of function parameter packs 2) Instantiation of function parameter packs within function types. 3) Template argument deduction of function parameter packs when matching two function types. We're missing all of the important template-instantiation logic for function template definitions, along with template argument deduction from the argument list of a function call, so don't even think of trying to use these for real yet. llvm-svn: 122926
2011-01-06 07:12:31 +08:00
return TLB.getTypeSourceInfo(Context, Result);
}
Clone Sema::SubstType for DeclaratorInfos. llvm-svn: 84724
2009-10-21 08:58:09 +08:00
/// Deprecated form of the above.
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
QualType Sema::SubstType(QualType T,
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,
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
SourceLocation Loc, DeclarationName Entity) {
Rename ActiveTemplateInstantiation to CodeSynthesisContext in preparation for using it for other kinds of context (where we currently produce context notes in a highly ad-hoc manner). llvm-svn: 295919
2017-02-23 09:43:54 +08:00
assert(!CodeSynthesisContexts.empty() &&
Extend the notion of active template instantiations to include the context of a template-id for which we need to instantiate default template arguments. In the TextDiagnosticPrinter, don't suppress the caret diagnostic if we are producing a non-note diagnostic that follows a note diagnostic with the same location, because notes are (conceptually) a part of the warning or error that comes before them. llvm-svn: 66572
2009-03-11 04:44:00 +08:00
"Cannot perform an instantiation without some context on the "
"instantiation stack");
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
// If T is not a dependent type or a variably-modified type, there
// is nothing to do.
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 (!T->isInstantiationDependentType() && !T->isVariablyModifiedType())
Implement the basic approach for instantiating types, with a lot of FIXME'd stubs for those types we don't yet know how to instantiate (everything that isn't a template parameter!). We now instantiate default arguments for template type parameters when needed. This will be our testbed while I fill out the remaining type-instantiation logic. llvm-svn: 65649
2009-02-28 03:31:52 +08:00
return T;
Refactor template instantiation for types into a generic tree transformation template (TreeTransform) that handles the transformation and reconstruction of AST nodes. Template instantiation for types is a (relatively small) customization of the generic tree transformation. llvm-svn: 78071
2009-08-05 00:50:30 +08:00
TemplateInstantiator Instantiator(*this, TemplateArgs, Loc, Entity);
return Instantiator.TransformType(T);
Implement the basic approach for instantiating types, with a lot of FIXME'd stubs for those types we don't yet know how to instantiate (everything that isn't a template parameter!). We now instantiate default arguments for template type parameters when needed. This will be our testbed while I fill out the remaining type-instantiation logic. llvm-svn: 65649
2009-02-28 03:31:52 +08:00
}
Implement the basics of implicit instantiation of class templates, in response to attempts to diagnose an "incomplete" type. This will force us to use DiagnoseIncompleteType more regularly (rather than looking at isIncompleteType), but that's also a good thing. Implicit instantiation is still very simplistic, and will create a new definition for the class template specialization (as it should) but it only actually instantiates the base classes and attaches those. Actually instantiating class members will follow. Also, instantiate the types of non-type template parameters before checking them, allowing, e.g., template<typename T, T Value> struct Constant; to work properly. llvm-svn: 65924
2009-03-03 12:44:36 +08:00
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
static bool NeedsInstantiationAsFunctionType(TypeSourceInfo *T) {
Always build a new TypeSourceInfo for function templates with parameters RecursiveASTVisitor::TraverseFunctionHelper() traverses a function's ParmVarDecls by going to the function's getTypeSourceInfo if it exists, and `DEF_TRAVERSE_TYPELOC(FunctionProtoType` then goes to the function's ParmVarDecls. For a function template that doesn't have parameters that explicitly depend on the template parameter, we used to be clever and not build a new TypeSourceInfo. That meant that when an instantiation of such a template is visited, its TypeSourceInfo would point to the ParmVarDecls of the template, not of the instantiation, which then confused clients of RecursiveASTVisitor. So don't be clever for function templates that have parameters, even if none of the parameters depend on the type. Fixes PR26257. http://reviews.llvm.org/D16478 llvm-svn: 259428
2016-02-02 06:31:51 +08:00
if (T->getType()->isInstantiationDependentType() ||
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
T->getType()->isVariablyModifiedType())
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
return true;
Added missing IgnoreParens(). llvm-svn: 121795
2010-12-15 06:11:44 +08:00
TypeLoc TL = T->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
if (!TL.getAs<FunctionProtoTypeLoc>())
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
return false;
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 FP = TL.castAs<FunctionProtoTypeLoc>();
Always build a new TypeSourceInfo for function templates with parameters RecursiveASTVisitor::TraverseFunctionHelper() traverses a function's ParmVarDecls by going to the function's getTypeSourceInfo if it exists, and `DEF_TRAVERSE_TYPELOC(FunctionProtoType` then goes to the function's ParmVarDecls. For a function template that doesn't have parameters that explicitly depend on the template parameter, we used to be clever and not build a new TypeSourceInfo. That meant that when an instantiation of such a template is visited, its TypeSourceInfo would point to the ParmVarDecls of the template, not of the instantiation, which then confused clients of RecursiveASTVisitor. So don't be clever for function templates that have parameters, even if none of the parameters depend on the type. Fixes PR26257. http://reviews.llvm.org/D16478 llvm-svn: 259428
2016-02-02 06:31:51 +08:00
for (ParmVarDecl *P : FP.getParams()) {
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
// This must be synthesized from a typedef.
if (!P) continue;
Always build a new TypeSourceInfo for function templates with parameters RecursiveASTVisitor::TraverseFunctionHelper() traverses a function's ParmVarDecls by going to the function's getTypeSourceInfo if it exists, and `DEF_TRAVERSE_TYPELOC(FunctionProtoType` then goes to the function's ParmVarDecls. For a function template that doesn't have parameters that explicitly depend on the template parameter, we used to be clever and not build a new TypeSourceInfo. That meant that when an instantiation of such a template is visited, its TypeSourceInfo would point to the ParmVarDecls of the template, not of the instantiation, which then confused clients of RecursiveASTVisitor. So don't be clever for function templates that have parameters, even if none of the parameters depend on the type. Fixes PR26257. http://reviews.llvm.org/D16478 llvm-svn: 259428
2016-02-02 06:31:51 +08:00
// If there are any parameters, a new TypeSourceInfo that refers to the
// instantiated parameters must be built.
return true;
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
}
return false;
}
/// A form of SubstType intended specifically for instantiating the
/// type of a FunctionDecl. Its purpose is solely to force the
Instantiate exception specifications when instantiating function types (other than the type of a function declaration). We previously didn't instantiate these at all! This also covers the pathological case where the only mention of a parameter pack is within the exception specification; this gives us a second way (other than alias templates) to reach the horrible state where a type contains an unexpanded pack, but its canonical type does not. This is a re-commit of r219977: r219977 was reverted in r220038 because it hit a wrong-code bug in GCC 4.7.2. (That's gcc.gnu.org/PR56135, and affects any implicit lambda-capture of 'this' within a template.) r219977 was a re-commit of r217995, r218011, and r218053: r217995 was reverted in r218058 because it hit a rejects-valid bug in MSVC. (Incorrect overload resolution in the presence of using-declarations.) It was re-committed in r219977 with a workaround for the MSVC rejects-valid. r218011 was a workaround for an MSVC parser bug. (Incorrect desugaring of unbraced range-based for loop). llvm-svn: 221750
2014-11-12 10:00:47 +08:00
/// instantiation of default-argument expressions and to avoid
/// instantiating an exception-specification.
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 *Sema::SubstFunctionDeclType(TypeSourceInfo *T,
const MultiLevelTemplateArgumentList &Args,
SourceLocation Loc,
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
DeclarationName Entity,
CXXRecordDecl *ThisContext,
[OpenCL] Add generic AS to 'this' pointer Address spaces are cast into generic before invoking the constructor. Added support for a trailing Qualifiers object in FunctionProtoType. Note: This recommits the previously reverted patch, but now it is commited together with a fix for lldb. Differential Revision: https://reviews.llvm.org/D54862 llvm-svn: 349019
2018-12-13 18:15:27 +08:00
Qualifiers ThisTypeQuals) {
Rename ActiveTemplateInstantiation to CodeSynthesisContext in preparation for using it for other kinds of context (where we currently produce context notes in a highly ad-hoc manner). llvm-svn: 295919
2017-02-23 09:43:54 +08:00
assert(!CodeSynthesisContexts.empty() &&
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
"Cannot perform an instantiation without some context on the "
"instantiation stack");
Always build a new TypeSourceInfo for function templates with parameters RecursiveASTVisitor::TraverseFunctionHelper() traverses a function's ParmVarDecls by going to the function's getTypeSourceInfo if it exists, and `DEF_TRAVERSE_TYPELOC(FunctionProtoType` then goes to the function's ParmVarDecls. For a function template that doesn't have parameters that explicitly depend on the template parameter, we used to be clever and not build a new TypeSourceInfo. That meant that when an instantiation of such a template is visited, its TypeSourceInfo would point to the ParmVarDecls of the template, not of the instantiation, which then confused clients of RecursiveASTVisitor. So don't be clever for function templates that have parameters, even if none of the parameters depend on the type. Fixes PR26257. http://reviews.llvm.org/D16478 llvm-svn: 259428
2016-02-02 06:31:51 +08:00
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
if (!NeedsInstantiationAsFunctionType(T))
return T;
TemplateInstantiator Instantiator(*this, Args, Loc, Entity);
TypeLocBuilder TLB;
TypeLoc TL = T->getTypeLoc();
TLB.reserve(TL.getFullDataSize());
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
QualType Result;
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
Instantiate exception specifications when instantiating function types (other than the type of a function declaration). We previously didn't instantiate these at all! This also covers the pathological case where the only mention of a parameter pack is within the exception specification; this gives us a second way (other than alias templates) to reach the horrible state where a type contains an unexpanded pack, but its canonical type does not. This is a re-commit of r219977: r219977 was reverted in r220038 because it hit a wrong-code bug in GCC 4.7.2. (That's gcc.gnu.org/PR56135, and affects any implicit lambda-capture of 'this' within a template.) r219977 was a re-commit of r217995, r218011, and r218053: r217995 was reverted in r218058 because it hit a rejects-valid bug in MSVC. (Incorrect overload resolution in the presence of using-declarations.) It was re-committed in r219977 with a workaround for the MSVC rejects-valid. r218011 was a workaround for an MSVC parser bug. (Incorrect desugaring of unbraced range-based for loop). llvm-svn: 221750
2014-11-12 10:00:47 +08:00
if (FunctionProtoTypeLoc Proto =
TL.IgnoreParens().getAs<FunctionProtoTypeLoc>()) {
// Instantiate the type, other than its exception specification. The
// exception specification is instantiated in InitFunctionInstantiation
// once we've built the FunctionDecl.
// FIXME: Set the exception specification to EST_Uninstantiated here,
// instead of rebuilding the function type again later.
Result = Instantiator.TransformFunctionProtoType(
TLB, Proto, ThisContext, ThisTypeQuals,
[](FunctionProtoType::ExceptionSpecInfo &ESI,
bool &Changed) { return false; });
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
} else {
Result = Instantiator.TransformType(TLB, TL);
}
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
if (Result.isNull())
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
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
return TLB.getTypeSourceInfo(Context, Result);
}
[c++1z] Support deducing B in noexcept(B). This is not required by the standard (yet), but there seems to be reasonable support for this being a defect according to CWG discussion, and libstdc++ 7.1 relies on it working. llvm-svn: 304946
2017-06-08 05:46:22 +08:00
bool Sema::SubstExceptionSpec(SourceLocation Loc,
FunctionProtoType::ExceptionSpecInfo &ESI,
SmallVectorImpl<QualType> &ExceptionStorage,
const MultiLevelTemplateArgumentList &Args) {
assert(ESI.Type != EST_Uninstantiated);
bool Changed = false;
TemplateInstantiator Instantiator(*this, Args, Loc, DeclarationName());
return Instantiator.TransformExceptionSpec(Loc, ESI, ExceptionStorage,
Changed);
}
Instantiate exception specifications when instantiating function types (other than the type of a function declaration). We previously didn't instantiate these at all! This also covers the pathological case where the only mention of a parameter pack is within the exception specification; this gives us a second way (other than alias templates) to reach the horrible state where a type contains an unexpanded pack, but its canonical type does not. This is a re-commit of r219977: r219977 was reverted in r220038 because it hit a wrong-code bug in GCC 4.7.2. (That's gcc.gnu.org/PR56135, and affects any implicit lambda-capture of 'this' within a template.) r219977 was a re-commit of r217995, r218011, and r218053: r217995 was reverted in r218058 because it hit a rejects-valid bug in MSVC. (Incorrect overload resolution in the presence of using-declarations.) It was re-committed in r219977 with a workaround for the MSVC rejects-valid. r218011 was a workaround for an MSVC parser bug. (Incorrect desugaring of unbraced range-based for loop). llvm-svn: 221750
2014-11-12 10:00:47 +08:00
void Sema::SubstExceptionSpec(FunctionDecl *New, const FunctionProtoType *Proto,
const MultiLevelTemplateArgumentList &Args) {
FunctionProtoType::ExceptionSpecInfo ESI =
Proto->getExtProtoInfo().ExceptionSpec;
SmallVector<QualType, 4> ExceptionStorage;
Port getLocEnd -> getEndLoc Reviewers: teemperor! Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D50351 llvm-svn: 339386
2018-08-10 05:09:38 +08:00
if (SubstExceptionSpec(New->getTypeSourceInfo()->getTypeLoc().getEndLoc(),
[c++1z] Support deducing B in noexcept(B). This is not required by the standard (yet), but there seems to be reasonable support for this being a defect according to CWG discussion, and libstdc++ 7.1 relies on it working. llvm-svn: 304946
2017-06-08 05:46:22 +08:00
ESI, ExceptionStorage, Args))
Instantiate exception specifications when instantiating function types (other than the type of a function declaration). We previously didn't instantiate these at all! This also covers the pathological case where the only mention of a parameter pack is within the exception specification; this gives us a second way (other than alias templates) to reach the horrible state where a type contains an unexpanded pack, but its canonical type does not. This is a re-commit of r219977: r219977 was reverted in r220038 because it hit a wrong-code bug in GCC 4.7.2. (That's gcc.gnu.org/PR56135, and affects any implicit lambda-capture of 'this' within a template.) r219977 was a re-commit of r217995, r218011, and r218053: r217995 was reverted in r218058 because it hit a rejects-valid bug in MSVC. (Incorrect overload resolution in the presence of using-declarations.) It was re-committed in r219977 with a workaround for the MSVC rejects-valid. r218011 was a workaround for an MSVC parser bug. (Incorrect desugaring of unbraced range-based for loop). llvm-svn: 221750
2014-11-12 10:00:47 +08:00
// On error, recover by dropping the exception specification.
ESI.Type = EST_None;
UpdateExceptionSpec(New, ESI);
}
[Concepts] Instantiate invented template type parameter type-constraint along with function parameters We previously instantiated type-constraints of template type parameters along with the type parameter itself, this caused problems when the type-constraints created by abbreviated templates refreneced other parameters in the abbreviated templates. When encountering a template type parameter with a type constraint, if it is implicit, delay instantiation of the type-constraint until the function parameter which created the invented template type parameter is instantiated. Reland after fixing bug caused by another flow reaching SubstParmVarDecl and instantiating the TypeConstraint a second time.
2020-02-03 21:44:33 +08:00
namespace {
struct GetContainedInventedTypeParmVisitor :
public TypeVisitor<GetContainedInventedTypeParmVisitor,
TemplateTypeParmDecl *> {
using TypeVisitor<GetContainedInventedTypeParmVisitor,
TemplateTypeParmDecl *>::Visit;
TemplateTypeParmDecl *Visit(QualType T) {
if (T.isNull())
return nullptr;
return Visit(T.getTypePtr());
}
// The deduced type itself.
TemplateTypeParmDecl *VisitTemplateTypeParmType(
const TemplateTypeParmType *T) {
[Concepts] Add null check for TemplateTypeParmType::getDecl() in GetContainedInventedTypeParmVisitor GetContainedInventedTypeParmVisitor would not account for the case where TemplateTypeParmType::getDecl() is nullptr, causing bug #45102. Add the nullptr check.
2020-03-07 00:45:12 +08:00
if (!T->getDecl() || !T->getDecl()->isImplicit())
[Concepts] Instantiate invented template type parameter type-constraint along with function parameters We previously instantiated type-constraints of template type parameters along with the type parameter itself, this caused problems when the type-constraints created by abbreviated templates refreneced other parameters in the abbreviated templates. When encountering a template type parameter with a type constraint, if it is implicit, delay instantiation of the type-constraint until the function parameter which created the invented template type parameter is instantiated. Reland after fixing bug caused by another flow reaching SubstParmVarDecl and instantiating the TypeConstraint a second time.
2020-02-03 21:44:33 +08:00
return nullptr;
return T->getDecl();
}
// Only these types can contain 'auto' types, and subsequently be replaced
// by references to invented parameters.
TemplateTypeParmDecl *VisitElaboratedType(const ElaboratedType *T) {
return Visit(T->getNamedType());
}
TemplateTypeParmDecl *VisitPointerType(const PointerType *T) {
return Visit(T->getPointeeType());
}
TemplateTypeParmDecl *VisitBlockPointerType(const BlockPointerType *T) {
return Visit(T->getPointeeType());
}
TemplateTypeParmDecl *VisitReferenceType(const ReferenceType *T) {
return Visit(T->getPointeeTypeAsWritten());
}
TemplateTypeParmDecl *VisitMemberPointerType(const MemberPointerType *T) {
return Visit(T->getPointeeType());
}
TemplateTypeParmDecl *VisitArrayType(const ArrayType *T) {
return Visit(T->getElementType());
}
TemplateTypeParmDecl *VisitDependentSizedExtVectorType(
const DependentSizedExtVectorType *T) {
return Visit(T->getElementType());
}
TemplateTypeParmDecl *VisitVectorType(const VectorType *T) {
return Visit(T->getElementType());
}
TemplateTypeParmDecl *VisitFunctionProtoType(const FunctionProtoType *T) {
return VisitFunctionType(T);
}
TemplateTypeParmDecl *VisitFunctionType(const FunctionType *T) {
return Visit(T->getReturnType());
}
TemplateTypeParmDecl *VisitParenType(const ParenType *T) {
return Visit(T->getInnerType());
}
TemplateTypeParmDecl *VisitAttributedType(const AttributedType *T) {
return Visit(T->getModifiedType());
}
TemplateTypeParmDecl *VisitMacroQualifiedType(const MacroQualifiedType *T) {
return Visit(T->getUnderlyingType());
}
TemplateTypeParmDecl *VisitAdjustedType(const AdjustedType *T) {
return Visit(T->getOriginalType());
}
TemplateTypeParmDecl *VisitPackExpansionType(const PackExpansionType *T) {
return Visit(T->getPattern());
}
};
} // namespace
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
ParmVarDecl *Sema::SubstParmVarDecl(ParmVarDecl *OldParm,
Handle substitutions into function parameter packs whose patterns contain multiple parameter packs at different levels. llvm-svn: 123488
2011-01-15 06:40:04 +08:00
const MultiLevelTemplateArgumentList &TemplateArgs,
Store a parameter index and function prototype depth in every parameter node and use this to correctly mangle parameter references in function template signatures. A follow-up patch will improve the storage usage of these fields; here I've just done the lazy thing. llvm-svn: 130669
2011-05-02 06:35:37 +08:00
int indexAdjustment,
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,
When we're substituting into a function parameter pack and expect to get a function parameter pack (but don't due to weird substitutions), complain. Fixes the last bit of PR11848. llvm-svn: 148960
2012-01-26 00:15:54 +08:00
bool ExpectParameterPack) {
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
TypeSourceInfo *OldDI = OldParm->getTypeSourceInfo();
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
TypeSourceInfo *NewDI = nullptr;
Initial implementation of function parameter packs. This implementation allows: 1) Declaration of function parameter packs 2) Instantiation of function parameter packs within function types. 3) Template argument deduction of function parameter packs when matching two function types. We're missing all of the important template-instantiation logic for function template definitions, along with template argument deduction from the argument list of a function call, so don't even think of trying to use these for real yet. llvm-svn: 122926
2011-01-06 07:12:31 +08:00
TypeLoc OldTL = OldDI->getTypeLoc();
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
if (PackExpansionTypeLoc ExpansionTL = OldTL.getAs<PackExpansionTypeLoc>()) {
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
// We have a function parameter pack. Substitute into the pattern of the
Initial implementation of function parameter packs. This implementation allows: 1) Declaration of function parameter packs 2) Instantiation of function parameter packs within function types. 3) Template argument deduction of function parameter packs when matching two function types. We're missing all of the important template-instantiation logic for function template definitions, along with template argument deduction from the argument list of a function call, so don't even think of trying to use these for real yet. llvm-svn: 122926
2011-01-06 07:12:31 +08:00
// expansion.
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
NewDI = SubstType(ExpansionTL.getPatternLoc(), TemplateArgs,
Initial implementation of function parameter packs. This implementation allows: 1) Declaration of function parameter packs 2) Instantiation of function parameter packs within function types. 3) Template argument deduction of function parameter packs when matching two function types. We're missing all of the important template-instantiation logic for function template definitions, along with template argument deduction from the argument list of a function call, so don't even think of trying to use these for real yet. llvm-svn: 122926
2011-01-06 07:12:31 +08:00
OldParm->getLocation(), OldParm->getDeclName());
if (!NewDI)
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Initial implementation of function parameter packs. This implementation allows: 1) Declaration of function parameter packs 2) Instantiation of function parameter packs within function types. 3) Template argument deduction of function parameter packs when matching two function types. We're missing all of the important template-instantiation logic for function template definitions, along with template argument deduction from the argument list of a function call, so don't even think of trying to use these for real yet. llvm-svn: 122926
2011-01-06 07:12:31 +08:00
if (NewDI->getType()->containsUnexpandedParameterPack()) {
// We still have unexpanded parameter packs, which means that
// our function parameter is still a function parameter pack.
// Therefore, make its type a pack expansion type.
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
NewDI = CheckPackExpansion(NewDI, ExpansionTL.getEllipsisLoc(),
Handle substitutions into function parameter packs whose patterns contain multiple parameter packs at different levels. llvm-svn: 123488
2011-01-15 06:40:04 +08:00
NumExpansions);
When we're substituting into a function parameter pack and expect to get a function parameter pack (but don't due to weird substitutions), complain. Fixes the last bit of PR11848. llvm-svn: 148960
2012-01-26 00:15:54 +08:00
} else if (ExpectParameterPack) {
// We expected to get a parameter pack but didn't (because the type
// itself is not a pack expansion type), so complain. This can occur when
// the substitution goes through an alias template that "loses" the
// pack expansion.
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
Diag(OldParm->getLocation(),
When we're substituting into a function parameter pack and expect to get a function parameter pack (but don't due to weird substitutions), complain. Fixes the last bit of PR11848. llvm-svn: 148960
2012-01-26 00:15:54 +08:00
diag::err_function_parameter_pack_without_parameter_packs)
<< NewDI->getType();
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
}
Initial implementation of function parameter packs. This implementation allows: 1) Declaration of function parameter packs 2) Instantiation of function parameter packs within function types. 3) Template argument deduction of function parameter packs when matching two function types. We're missing all of the important template-instantiation logic for function template definitions, along with template argument deduction from the argument list of a function call, so don't even think of trying to use these for real yet. llvm-svn: 122926
2011-01-06 07:12:31 +08:00
} else {
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
NewDI = SubstType(OldDI, TemplateArgs, OldParm->getLocation(),
Initial implementation of function parameter packs. This implementation allows: 1) Declaration of function parameter packs 2) Instantiation of function parameter packs within function types. 3) Template argument deduction of function parameter packs when matching two function types. We're missing all of the important template-instantiation logic for function template definitions, along with template argument deduction from the argument list of a function call, so don't even think of trying to use these for real yet. llvm-svn: 122926
2011-01-06 07:12:31 +08:00
OldParm->getDeclName());
}
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
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
if (!NewDI)
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Be sure to instantiate the parameters of a function, even when the function's type is (strictly speaking) non-dependent. This ensures that, e.g., default function arguments get instantiated properly. And, since I couldn't resist, collapse the two implementations of function-parameter instantiation into calls to a single, new function (Sema::SubstParmVarDecl), since the two had nearly identical code (and each had bugs the other didn't!). More importantly, factored out the semantic analysis of a parameter declaration into Sema::CheckParameter, which is called both by Sema::ActOnParamDeclarator (when parameters are parsed) and when a parameter is instantiated. Previously, we were missing some Objective-C and address-space checks on instantiated function parameters. Fixes PR6733. llvm-svn: 101029
2010-04-12 15:48:19 +08:00
if (NewDI->getType()->isVoidType()) {
Diag(OldParm->getLocation(), diag::err_param_with_void_type);
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Be sure to instantiate the parameters of a function, even when the function's type is (strictly speaking) non-dependent. This ensures that, e.g., default function arguments get instantiated properly. And, since I couldn't resist, collapse the two implementations of function-parameter instantiation into calls to a single, new function (Sema::SubstParmVarDecl), since the two had nearly identical code (and each had bugs the other didn't!). More importantly, factored out the semantic analysis of a parameter declaration into Sema::CheckParameter, which is called both by Sema::ActOnParamDeclarator (when parameters are parsed) and when a parameter is instantiated. Previously, we were missing some Objective-C and address-space checks on instantiated function parameters. Fixes PR6733. llvm-svn: 101029
2010-04-12 15:48:19 +08:00
}
[Concepts] Instantiate invented template type parameter type-constraint along with function parameters We previously instantiated type-constraints of template type parameters along with the type parameter itself, this caused problems when the type-constraints created by abbreviated templates refreneced other parameters in the abbreviated templates. When encountering a template type parameter with a type constraint, if it is implicit, delay instantiation of the type-constraint until the function parameter which created the invented template type parameter is instantiated. Reland after fixing bug caused by another flow reaching SubstParmVarDecl and instantiating the TypeConstraint a second time.
2020-02-03 21:44:33 +08:00
// In abbreviated templates, TemplateTypeParmDecls with possible
// TypeConstraints are created when the parameter list is originally parsed.
// The TypeConstraints can therefore reference other functions parameters in
// the abbreviated function template, which is why we must instantiate them
// here, when the instantiated versions of those referenced parameters are in
// scope.
if (TemplateTypeParmDecl *TTP =
GetContainedInventedTypeParmVisitor().Visit(OldDI->getType())) {
if (const TypeConstraint *TC = TTP->getTypeConstraint()) {
[Concepts] Fix incorrect check when instantiating abbreviated template type-constraints We would incorrectly check whether the type-constraint had already been initialized, causing us to ignore the invented template type constraints entirely. Also, TemplateParameterList would store incorrect information about invented type parameters when it observed them before their type-constraint was initialized, so we recreate it after initializing the function type of an abbreviated template.
2020-02-07 05:19:18 +08:00
auto *Inst = cast_or_null<TemplateTypeParmDecl>(
[Concepts] Instantiate invented template type parameter type-constraint along with function parameters We previously instantiated type-constraints of template type parameters along with the type parameter itself, this caused problems when the type-constraints created by abbreviated templates refreneced other parameters in the abbreviated templates. When encountering a template type parameter with a type constraint, if it is implicit, delay instantiation of the type-constraint until the function parameter which created the invented template type parameter is instantiated. Reland after fixing bug caused by another flow reaching SubstParmVarDecl and instantiating the TypeConstraint a second time.
2020-02-03 21:44:33 +08:00
FindInstantiatedDecl(TTP->getLocation(), TTP, TemplateArgs));
// We will first get here when instantiating the abbreviated function
// template's described function, but we might also get here later.
// Make sure we do not instantiate the TypeConstraint more than once.
[Concepts] Fix incorrect check when instantiating abbreviated template type-constraints We would incorrectly check whether the type-constraint had already been initialized, causing us to ignore the invented template type constraints entirely. Also, TemplateParameterList would store incorrect information about invented type parameters when it observed them before their type-constraint was initialized, so we recreate it after initializing the function type of an abbreviated template.
2020-02-07 05:19:18 +08:00
if (Inst && !Inst->getTypeConstraint()) {
[Concepts] Instantiate invented template type parameter type-constraint along with function parameters We previously instantiated type-constraints of template type parameters along with the type parameter itself, this caused problems when the type-constraints created by abbreviated templates refreneced other parameters in the abbreviated templates. When encountering a template type parameter with a type constraint, if it is implicit, delay instantiation of the type-constraint until the function parameter which created the invented template type parameter is instantiated. Reland after fixing bug caused by another flow reaching SubstParmVarDecl and instantiating the TypeConstraint a second time.
2020-02-03 21:44:33 +08:00
// TODO: Concepts: do not instantiate the constraint (delayed constraint
// substitution)
const ASTTemplateArgumentListInfo *TemplArgInfo
= TC->getTemplateArgsAsWritten();
TemplateArgumentListInfo InstArgs;
if (TemplArgInfo) {
InstArgs.setLAngleLoc(TemplArgInfo->LAngleLoc);
InstArgs.setRAngleLoc(TemplArgInfo->RAngleLoc);
if (Subst(TemplArgInfo->getTemplateArgs(),
TemplArgInfo->NumTemplateArgs, InstArgs, TemplateArgs))
return nullptr;
}
if (AttachTypeConstraint(
TC->getNestedNameSpecifierLoc(), TC->getConceptNameInfo(),
Clean up handling of constrained parameters in lambdas. No functionality change intended.
2021-05-13 05:19:23 +08:00
TC->getNamedConcept(), TemplArgInfo ? &InstArgs : nullptr, Inst,
[Concepts] Instantiate invented template type parameter type-constraint along with function parameters We previously instantiated type-constraints of template type parameters along with the type parameter itself, this caused problems when the type-constraints created by abbreviated templates refreneced other parameters in the abbreviated templates. When encountering a template type parameter with a type constraint, if it is implicit, delay instantiation of the type-constraint until the function parameter which created the invented template type parameter is instantiated. Reland after fixing bug caused by another flow reaching SubstParmVarDecl and instantiating the TypeConstraint a second time.
2020-02-03 21:44:33 +08:00
TTP->isParameterPack()
? cast<CXXFoldExpr>(TC->getImmediatelyDeclaredConstraint())
Clean up handling of constrained parameters in lambdas. No functionality change intended.
2021-05-13 05:19:23 +08:00
->getEllipsisLoc()
[Concepts] Instantiate invented template type parameter type-constraint along with function parameters We previously instantiated type-constraints of template type parameters along with the type parameter itself, this caused problems when the type-constraints created by abbreviated templates refreneced other parameters in the abbreviated templates. When encountering a template type parameter with a type constraint, if it is implicit, delay instantiation of the type-constraint until the function parameter which created the invented template type parameter is instantiated. Reland after fixing bug caused by another flow reaching SubstParmVarDecl and instantiating the TypeConstraint a second time.
2020-02-03 21:44:33 +08:00
: SourceLocation()))
return nullptr;
}
}
}
Be sure to instantiate the parameters of a function, even when the function's type is (strictly speaking) non-dependent. This ensures that, e.g., default function arguments get instantiated properly. And, since I couldn't resist, collapse the two implementations of function-parameter instantiation into calls to a single, new function (Sema::SubstParmVarDecl), since the two had nearly identical code (and each had bugs the other didn't!). More importantly, factored out the semantic analysis of a parameter declaration into Sema::CheckParameter, which is called both by Sema::ActOnParamDeclarator (when parameters are parsed) and when a parameter is instantiated. Previously, we were missing some Objective-C and address-space checks on instantiated function parameters. Fixes PR6733. llvm-svn: 101029
2010-04-12 15:48:19 +08:00
ParmVarDecl *NewParm = CheckParameter(Context.getTranslationUnitDecl(),
Fixed source range for all DeclaratorDecl's. llvm-svn: 127225
2011-03-08 16:55:46 +08:00
OldParm->getInnerLocStart(),
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
OldParm->getLocation(),
Fixed source range for all DeclaratorDecl's. llvm-svn: 127225
2011-03-08 16:55:46 +08:00
OldParm->getIdentifier(),
NewDI->getType(), NewDI,
Add 178663 back. http://lab.llvm.org:8011/builders/clang-x86_64-darwin10-gdb went back green before it processed the reverted 178663, so it could not have been the culprit. Revert "Revert 178663." This reverts commit 4f8a3eb2ce5d4ba422483439e20c8cbb4d953a41. llvm-svn: 178682
2013-04-04 03:27:57 +08:00
OldParm->getStorageClass());
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
if (!NewParm)
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
Be sure to instantiate the parameters of a function, even when the function's type is (strictly speaking) non-dependent. This ensures that, e.g., default function arguments get instantiated properly. And, since I couldn't resist, collapse the two implementations of function-parameter instantiation into calls to a single, new function (Sema::SubstParmVarDecl), since the two had nearly identical code (and each had bugs the other didn't!). More importantly, factored out the semantic analysis of a parameter declaration into Sema::CheckParameter, which is called both by Sema::ActOnParamDeclarator (when parameters are parsed) and when a parameter is instantiated. Previously, we were missing some Objective-C and address-space checks on instantiated function parameters. Fixes PR6733. llvm-svn: 101029
2010-04-12 15:48:19 +08:00
// Mark the (new) default argument as uninstantiated (if any).
if (OldParm->hasUninstantiatedDefaultArg()) {
Expr *Arg = OldParm->getUninstantiatedDefaultArg();
NewParm->setUninstantiatedDefaultArg(Arg);
If we end up instantiating a function parameter whose default argument has not yet been parsed, note that the default argument hasn't been parsed and keep track of all of the instantiations of that function parameter. When its default argument does get parsed, imbue the instantiations with that default argument. Fixes PR8245. llvm-svn: 116324
2010-10-13 02:23:32 +08:00
} else if (OldParm->hasUnparsedDefaultArg()) {
NewParm->setUnparsedDefaultArg();
UnparsedDefaultArgInstantiations[OldParm].push_back(NewParm);
Instantiation of local class members. If a function containing a local class is instantiated, instantiate all of local class member, including default arguments and exception specifications. This change fixes PR21332 and thus implements DR1484. Differential Revision: http://reviews.llvm.org/D9990 llvm-svn: 240974
2015-06-30 01:50:19 +08:00
} else if (Expr *Arg = OldParm->getDefaultArg()) {
FunctionDecl *OwningFunc = cast<FunctionDecl>(OldParm->getDeclContext());
PR46648: Do not eagerly instantiate default arguments for a generic lambda when instantiating a call operator specialization. We previously incorrectly thought that such substitution was happening in the context of substitution into a local scope, which is a context where we should perform eager default argument instantiation.
2020-07-10 05:11:21 +08:00
if (OwningFunc->isInLocalScopeForInstantiation()) {
Instantiate function declarations in instantiated functions. If a function declaration is found inside a template function as in: template<class T> void f() { void g(int x = T::v) except(T::w); } it must be instantiated along with the enclosing template function, including default arguments and exception specification. Together with the patch committed in r240974 this implements DR1484. Differential Revision: http://reviews.llvm.org/D11194 llvm-svn: 245810
2015-08-23 18:22:28 +08:00
// Instantiate default arguments for methods of local classes (DR1484)
// and non-defining declarations.
Sema::ContextRAII SavedContext(*this, OwningFunc);
[Sema] Fix handling of enumerators used as default arguments of lambda expressions in a function or class template. This patch makes the following changes: - Create a DependentScopeDeclRefExpr for the default argument instead of a CXXDependentScopeMemberExpr. - Pass CombineWithOuterScope=true so that the outer scope in which the enum is declared is searched for the instantiation of the enum. This is the first part of https://reviews.llvm.org/D23096. Fixes PR28795 rdar://problem/27535319 llvm-svn: 289914
2016-12-16 11:19:41 +08:00
LocalInstantiationScope Local(*this, true);
Instantiation of local class members. If a function containing a local class is instantiated, instantiate all of local class member, including default arguments and exception specifications. This change fixes PR21332 and thus implements DR1484. Differential Revision: http://reviews.llvm.org/D9990 llvm-svn: 240974
2015-06-30 01:50:19 +08:00
ExprResult NewArg = SubstExpr(Arg, TemplateArgs);
Correctly type-check the default arguments of local functions when eagerly instantiating them. rdar://23721638 llvm-svn: 255325
2015-12-11 09:56:36 +08:00
if (NewArg.isUsable()) {
// It would be nice if we still had this.
Port getLocStart -> getBeginLoc Reviewers: teemperor! Subscribers: jholewinski, whisperity, jfb, cfe-commits Differential Revision: https://reviews.llvm.org/D50350 llvm-svn: 339385
2018-08-10 05:08:08 +08:00
SourceLocation EqualLoc = NewArg.get()->getBeginLoc();
[clang] Convert a default argument expression to the parameter type... ...before checking that the default argument is valid with CheckDefaultArgumentVisitor. Currently the restrictions on a default argument are checked with the visitor CheckDefaultArgumentVisitor in ActOnParamDefaultArgument before performing the conversion to the parameter type in SetParamDefaultArgument. This was fine before the previous patch but now some valid code post-CWG 2346 is rejected: void test() { const int i2 = 0; extern void h2a(int x = i2); // FIXME: ok, not odr-use extern void h2b(int x = i2 + 0); // ok, not odr-use } This is because the reference to i2 in h2a has not been marked yet with NOUR_Constant. i2 is marked NOUR_Constant when the conversion to the parameter type is done, which is done just after. The solution is to do the conversion to the parameter type before checking the restrictions on default arguments with CheckDefaultArgumentVisitor. This has the side-benefit of improving some diagnostics. Differential Revision: https://reviews.llvm.org/D81616 Reviewed By: rsmith
2020-06-11 20:13:05 +08:00
ExprResult Result =
ConvertParamDefaultArgument(NewParm, NewArg.get(), EqualLoc);
if (Result.isInvalid())
return nullptr;
SetParamDefaultArgument(NewParm, Result.getAs<Expr>(), EqualLoc);
Correctly type-check the default arguments of local functions when eagerly instantiating them. rdar://23721638 llvm-svn: 255325
2015-12-11 09:56:36 +08:00
}
Instantiation of local class members. If a function containing a local class is instantiated, instantiate all of local class member, including default arguments and exception specifications. This change fixes PR21332 and thus implements DR1484. Differential Revision: http://reviews.llvm.org/D9990 llvm-svn: 240974
2015-06-30 01:50:19 +08:00
} else {
// FIXME: if we non-lazily instantiated non-dependent default args for
// non-dependent parameter types we could remove a bunch of duplicate
// conversion warnings for such arguments.
NewParm->setUninstantiatedDefaultArg(Arg);
}
}
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
NewParm->setHasInheritedDefaultArg(OldParm->hasInheritedDefaultArg());
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
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
if (OldParm->isParameterPack() && !NewParm->isParameterPack()) {
Fix PR11848: decree that an alias template contains an unexpanded parameter pack iff its substitution contains an unexpanded parameter pack. This has the effect that we now reject declarations such as this (which we used to crash when expanding): template<typename T> using Int = int; template<typename ...Ts> void f(Int<Ts> ...ints); The standard is inconsistent on how this case should be treated. llvm-svn: 148905
2012-01-25 10:14:59 +08:00
// Add the new parameter to the instantiated parameter pack.
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
CurrentInstantiationScope->InstantiatedLocalPackArg(OldParm, NewParm);
} else {
// Introduce an Old -> New mapping
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
CurrentInstantiationScope->InstantiatedLocal(OldParm, NewParm);
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
}
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
Fix http://llvm.org/PR7660 A ParmVarDecl instantiated from a FunctionProtoType may have Record as DeclContext, in which case isStaticDataMember() will erroneously return true. llvm-svn: 108692
2010-07-19 18:14:41 +08:00
// FIXME: OldParm may come from a FunctionProtoType, in which case CurContext
// can be anything, is this right ?
Set DeclContext of ParamVarDecl only. No need to set that of VarDecl for block variables (they are already set). Per Doug's comment. llvm-svn: 108273
2010-07-14 05:05:02 +08:00
NewParm->setDeclContext(CurContext);
Store a parameter index and function prototype depth in every parameter node and use this to correctly mangle parameter references in function template signatures. A follow-up patch will improve the storage usage of these fields; here I've just done the lazy thing. llvm-svn: 130669
2011-05-02 06:35:37 +08:00
NewParm->setScopeInfo(OldParm->getFunctionScopeDepth(),
OldParm->getFunctionScopeIndex() + indexAdjustment);
Sema: Preserve attributes on parameters in instantiated function templates. This was causing correctness issues for ARC and the static analyzer when a function template has "consumed" Objective-C object parameters (i.e. parameters that will be released by the function before returning). The fix is threefold: (1) Actually copy over the attributes from old ParmVarDecls to new ones. (2) Have Sema::BuildFunctionType only work for building FunctionProtoTypes, which it was doing anyway. This allows us to pass an ExtProtoInfo instead of a plain ExtInfo and several flags. (3) Drop param attributes as part of StripImplicitInstantiation, which is used when an implicit instantiation is followed by an explicit one. <rdar://problem/12685622> llvm-svn: 176728
2013-03-09 06:25:36 +08:00
InstantiateAttrs(TemplateArgs, OldParm, NewParm);
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
return NewParm;
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
}
Remove \brief commands from doxygen comments. This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
2018-05-09 09:00:01 +08:00
/// Substitute the given template arguments into the given set of
Factor out the template transformation of a sequence of function parameters into parameter types, so that substitution of explicitly-specified function template arguments uses the same path. This enables the use of explicitly-specified function template arguments with variadic templates. llvm-svn: 122986
2011-01-07 08:20:55 +08:00
/// parameters, producing the set of parameter types that would be generated
/// from such a substitution.
Use more ArrayRefs No functional change is intended, just a small refactoring. llvm-svn: 273647
2016-06-24 12:05:48 +08:00
bool Sema::SubstParmTypes(
SourceLocation Loc, ArrayRef<ParmVarDecl *> Params,
const FunctionProtoType::ExtParameterInfo *ExtParamInfos,
const MultiLevelTemplateArgumentList &TemplateArgs,
SmallVectorImpl<QualType> &ParamTypes,
SmallVectorImpl<ParmVarDecl *> *OutParams,
ExtParameterInfoBuilder &ParamInfos) {
Rename ActiveTemplateInstantiation to CodeSynthesisContext in preparation for using it for other kinds of context (where we currently produce context notes in a highly ad-hoc manner). llvm-svn: 295919
2017-02-23 09:43:54 +08:00
assert(!CodeSynthesisContexts.empty() &&
Factor out the template transformation of a sequence of function parameters into parameter types, so that substitution of explicitly-specified function template arguments uses the same path. This enables the use of explicitly-specified function template arguments with variadic templates. llvm-svn: 122986
2011-01-07 08:20:55 +08:00
"Cannot perform an instantiation without some context on the "
"instantiation stack");
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
TemplateInstantiator Instantiator(*this, TemplateArgs, Loc,
Factor out the template transformation of a sequence of function parameters into parameter types, so that substitution of explicitly-specified function template arguments uses the same path. This enables the use of explicitly-specified function template arguments with variadic templates. llvm-svn: 122986
2011-01-07 08:20:55 +08:00
DeclarationName());
Use more ArrayRefs No functional change is intended, just a small refactoring. llvm-svn: 273647
2016-06-24 12:05:48 +08:00
return Instantiator.TransformFunctionTypeParams(
Loc, Params, nullptr, ExtParamInfos, ParamTypes, OutParams, ParamInfos);
Factor out the template transformation of a sequence of function parameters into parameter types, so that substitution of explicitly-specified function template arguments uses the same path. This enables the use of explicitly-specified function template arguments with variadic templates. llvm-svn: 122986
2011-01-07 08:20:55 +08:00
}
Remove \brief commands from doxygen comments. This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
2018-05-09 09:00:01 +08:00
/// Perform substitution on the base class specifiers of the
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
/// given class template specialization.
Implement the basics of implicit instantiation of class templates, in response to attempts to diagnose an "incomplete" type. This will force us to use DiagnoseIncompleteType more regularly (rather than looking at isIncompleteType), but that's also a good thing. Implicit instantiation is still very simplistic, and will create a new definition for the class template specialization (as it should) but it only actually instantiates the base classes and attaches those. Actually instantiating class members will follow. Also, instantiate the types of non-type template parameters before checking them, allowing, e.g., template<typename T, T Value> struct Constant; to work properly. llvm-svn: 65924
2009-03-03 12:44:36 +08:00
///
/// Produces a diagnostic and returns true on error, returns false and
/// attaches the instantiated base classes to the class template
/// specialization if successful.
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
bool
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
Sema::SubstBaseSpecifiers(CXXRecordDecl *Instantiation,
CXXRecordDecl *Pattern,
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) {
Implement the basics of implicit instantiation of class templates, in response to attempts to diagnose an "incomplete" type. This will force us to use DiagnoseIncompleteType more regularly (rather than looking at isIncompleteType), but that's also a good thing. Implicit instantiation is still very simplistic, and will create a new definition for the class template specialization (as it should) but it only actually instantiates the base classes and attaches those. Actually instantiating class members will follow. Also, instantiate the types of non-type template parameters before checking them, allowing, e.g., template<typename T, T Value> struct Constant; to work properly. llvm-svn: 65924
2009-03-03 12:44:36 +08:00
bool Invalid = false;
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<CXXBaseSpecifier*, 4> InstantiatedBases;
Change range-based for-loops to be -Wrange-loop-analysis clean. No functionality change. llvm-svn: 234964
2015-04-15 09:21:42 +08:00
for (const auto &Base : Pattern->bases()) {
[C++11] Replacing CXXRecordDecl iterators bases_begin() and bases_end() with iterator_range bases(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203803
2014-03-13 23:41:46 +08:00
if (!Base.getType()->isDependentType()) {
if (const CXXRecordDecl *RD = Base.getType()->getAsCXXRecordDecl()) {
Propagate the invalid bit from bases to derived template classes. Fixes PR16292. llvm-svn: 184581
2013-06-22 02:58:32 +08:00
if (RD->isInvalidDecl())
Instantiation->setInvalidDecl();
}
[C++11] Replacing CXXRecordDecl iterators bases_begin() and bases_end() with iterator_range bases(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203803
2014-03-13 23:41:46 +08:00
InstantiatedBases.push_back(new (Context) CXXBaseSpecifier(Base));
Implement the basics of implicit instantiation of class templates, in response to attempts to diagnose an "incomplete" type. This will force us to use DiagnoseIncompleteType more regularly (rather than looking at isIncompleteType), but that's also a good thing. Implicit instantiation is still very simplistic, and will create a new definition for the class template specialization (as it should) but it only actually instantiates the base classes and attaches those. Actually instantiating class members will follow. Also, instantiate the types of non-type template parameters before checking them, allowing, e.g., template<typename T, T Value> struct Constant; to work properly. llvm-svn: 65924
2009-03-03 12:44:36 +08:00
continue;
}
Implement pack expansions whose pattern is a base-specifier. llvm-svn: 122782
2011-01-04 06:36:02 +08:00
SourceLocation EllipsisLoc;
When we're substituting into a parameter-type-list nested inside the pattern of an expansion, and we have a paramameter that is not a parameter pack, don't suppress substitution of parameter packs within this context. llvm-svn: 126819
2011-03-02 10:04:06 +08:00
TypeSourceInfo *BaseTypeLoc;
[C++11] Replacing CXXRecordDecl iterators bases_begin() and bases_end() with iterator_range bases(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203803
2014-03-13 23:41:46 +08:00
if (Base.isPackExpansion()) {
Implement pack expansions whose pattern is a base-specifier. llvm-svn: 122782
2011-01-04 06:36:02 +08:00
// This is a pack expansion. See whether we should expand it now, or
// wait until later.
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;
[C++11] Replacing CXXRecordDecl iterators bases_begin() and bases_end() with iterator_range bases(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203803
2014-03-13 23:41:46 +08:00
collectUnexpandedParameterPacks(Base.getTypeSourceInfo()->getTypeLoc(),
Implement pack expansions whose pattern is a base-specifier. llvm-svn: 122782
2011-01-04 06:36:02 +08:00
Unexpanded);
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;
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
if (CheckParameterPacksForExpansion(Base.getEllipsisLoc(),
[C++11] Replacing CXXRecordDecl iterators bases_begin() and bases_end() with iterator_range bases(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203803
2014-03-13 23:41:46 +08:00
Base.getSourceRange(),
ArrayRef-ifying the UnexpandedParameterPacks passed to Sema::CheckParameterPacksForExpansion llvm-svn: 140290
2011-09-22 10:34:54 +08:00
Unexpanded,
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +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 expansions whose pattern is a base-specifier. llvm-svn: 122782
2011-01-04 06:36:02 +08:00
NumExpansions)) {
Invalid = true;
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;
Implement pack expansions whose pattern is a base-specifier. llvm-svn: 122782
2011-01-04 06:36:02 +08:00
}
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
Implement pack expansions whose pattern is a base-specifier. llvm-svn: 122782
2011-01-04 06:36:02 +08:00
// If we should expand this pack expansion now, do so.
if (ShouldExpand) {
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 expansions whose pattern is a base-specifier. llvm-svn: 122782
2011-01-04 06:36:02 +08:00
Sema::ArgumentPackSubstitutionIndexRAII SubstIndex(*this, I);
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
[C++11] Replacing CXXRecordDecl iterators bases_begin() and bases_end() with iterator_range bases(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203803
2014-03-13 23:41:46 +08:00
TypeSourceInfo *BaseTypeLoc = SubstType(Base.getTypeSourceInfo(),
Implement pack expansions whose pattern is a base-specifier. llvm-svn: 122782
2011-01-04 06:36:02 +08:00
TemplateArgs,
[C++11] Replacing CXXRecordDecl iterators bases_begin() and bases_end() with iterator_range bases(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203803
2014-03-13 23:41:46 +08:00
Base.getSourceRange().getBegin(),
Implement pack expansions whose pattern is a base-specifier. llvm-svn: 122782
2011-01-04 06:36:02 +08:00
DeclarationName());
if (!BaseTypeLoc) {
Invalid = true;
continue;
}
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
Implement pack expansions whose pattern is a base-specifier. llvm-svn: 122782
2011-01-04 06:36:02 +08:00
if (CXXBaseSpecifier *InstantiatedBase
= CheckBaseSpecifier(Instantiation,
[C++11] Replacing CXXRecordDecl iterators bases_begin() and bases_end() with iterator_range bases(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203803
2014-03-13 23:41:46 +08:00
Base.getSourceRange(),
Base.isVirtual(),
Base.getAccessSpecifierAsWritten(),
Implement pack expansions whose pattern is a base-specifier. llvm-svn: 122782
2011-01-04 06:36:02 +08:00
BaseTypeLoc,
SourceLocation()))
InstantiatedBases.push_back(InstantiatedBase);
else
Invalid = true;
}
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
Implement pack expansions whose pattern is a base-specifier. llvm-svn: 122782
2011-01-04 06:36:02 +08:00
continue;
}
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
Implement pack expansions whose pattern is a base-specifier. llvm-svn: 122782
2011-01-04 06:36:02 +08:00
// The resulting base specifier will (still) be a pack expansion.
[C++11] Replacing CXXRecordDecl iterators bases_begin() and bases_end() with iterator_range bases(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203803
2014-03-13 23:41:46 +08:00
EllipsisLoc = Base.getEllipsisLoc();
When we're substituting into a parameter-type-list nested inside the pattern of an expansion, and we have a paramameter that is not a parameter pack, don't suppress substitution of parameter packs within this context. llvm-svn: 126819
2011-03-02 10:04:06 +08:00
Sema::ArgumentPackSubstitutionIndexRAII SubstIndex(*this, -1);
[C++11] Replacing CXXRecordDecl iterators bases_begin() and bases_end() with iterator_range bases(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203803
2014-03-13 23:41:46 +08:00
BaseTypeLoc = SubstType(Base.getTypeSourceInfo(),
When we're substituting into a parameter-type-list nested inside the pattern of an expansion, and we have a paramameter that is not a parameter pack, don't suppress substitution of parameter packs within this context. llvm-svn: 126819
2011-03-02 10:04:06 +08:00
TemplateArgs,
[C++11] Replacing CXXRecordDecl iterators bases_begin() and bases_end() with iterator_range bases(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203803
2014-03-13 23:41:46 +08:00
Base.getSourceRange().getBegin(),
When we're substituting into a parameter-type-list nested inside the pattern of an expansion, and we have a paramameter that is not a parameter pack, don't suppress substitution of parameter packs within this context. llvm-svn: 126819
2011-03-02 10:04:06 +08:00
DeclarationName());
} else {
[C++11] Replacing CXXRecordDecl iterators bases_begin() and bases_end() with iterator_range bases(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203803
2014-03-13 23:41:46 +08:00
BaseTypeLoc = SubstType(Base.getTypeSourceInfo(),
When we're substituting into a parameter-type-list nested inside the pattern of an expansion, and we have a paramameter that is not a parameter pack, don't suppress substitution of parameter packs within this context. llvm-svn: 126819
2011-03-02 10:04:06 +08:00
TemplateArgs,
[C++11] Replacing CXXRecordDecl iterators bases_begin() and bases_end() with iterator_range bases(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203803
2014-03-13 23:41:46 +08:00
Base.getSourceRange().getBegin(),
When we're substituting into a parameter-type-list nested inside the pattern of an expansion, and we have a paramameter that is not a parameter pack, don't suppress substitution of parameter packs within this context. llvm-svn: 126819
2011-03-02 10:04:06 +08:00
DeclarationName());
Implement pack expansions whose pattern is a base-specifier. llvm-svn: 122782
2011-01-04 06:36:02 +08:00
}
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
Add source location information to C++ base specifiers. llvm-svn: 109396
2010-07-27 00:56:01 +08:00
if (!BaseTypeLoc) {
Implement the basics of implicit instantiation of class templates, in response to attempts to diagnose an "incomplete" type. This will force us to use DiagnoseIncompleteType more regularly (rather than looking at isIncompleteType), but that's also a good thing. Implicit instantiation is still very simplistic, and will create a new definition for the class template specialization (as it should) but it only actually instantiates the base classes and attaches those. Actually instantiating class members will follow. Also, instantiate the types of non-type template parameters before checking them, allowing, e.g., template<typename T, T Value> struct Constant; to work properly. llvm-svn: 65924
2009-03-03 12:44:36 +08:00
Invalid = true;
continue;
}
if (CXXBaseSpecifier *InstantiatedBase
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
= CheckBaseSpecifier(Instantiation,
[C++11] Replacing CXXRecordDecl iterators bases_begin() and bases_end() with iterator_range bases(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203803
2014-03-13 23:41:46 +08:00
Base.getSourceRange(),
Base.isVirtual(),
Base.getAccessSpecifierAsWritten(),
Implement pack expansions whose pattern is a base-specifier. llvm-svn: 122782
2011-01-04 06:36:02 +08:00
BaseTypeLoc,
EllipsisLoc))
Implement the basics of implicit instantiation of class templates, in response to attempts to diagnose an "incomplete" type. This will force us to use DiagnoseIncompleteType more regularly (rather than looking at isIncompleteType), but that's also a good thing. Implicit instantiation is still very simplistic, and will create a new definition for the class template specialization (as it should) but it only actually instantiates the base classes and attaches those. Actually instantiating class members will follow. Also, instantiate the types of non-type template parameters before checking them, allowing, e.g., template<typename T, T Value> struct Constant; to work properly. llvm-svn: 65924
2009-03-03 12:44:36 +08:00
InstantiatedBases.push_back(InstantiatedBase);
else
Invalid = true;
}
[Sema] ArrayRef-ize ActOnBaseSpecifiers. NFC llvm-svn: 256478
2015-12-28 05:55:19 +08:00
if (!Invalid && AttachBaseSpecifiers(Instantiation, InstantiatedBases))
Implement the basics of implicit instantiation of class templates, in response to attempts to diagnose an "incomplete" type. This will force us to use DiagnoseIncompleteType more regularly (rather than looking at isIncompleteType), but that's also a good thing. Implicit instantiation is still very simplistic, and will create a new definition for the class template specialization (as it should) but it only actually instantiates the base classes and attaches those. Actually instantiating class members will follow. Also, instantiate the types of non-type template parameters before checking them, allowing, e.g., template<typename T, T Value> struct Constant; to work properly. llvm-svn: 65924
2009-03-03 12:44:36 +08:00
Invalid = true;
return Invalid;
}
Delayed template instantiation of late-parsed attributes. llvm-svn: 148595
2012-01-21 06:50:54 +08:00
// Defined via #include from SemaTemplateInstantiateDecl.cpp
Move instantiateTemplateAttribute into the sema namespace, make helpers static. llvm-svn: 149864
2012-02-06 19:13:08 +08:00
namespace clang {
namespace sema {
Attr *instantiateTemplateAttribute(const Attr *At, ASTContext &C, Sema &S,
const MultiLevelTemplateArgumentList &TemplateArgs);
Correct class-template deprecation behavior-REDUX Correct class-template deprecation behavior Based on the comment in the test, and my reading of the standard, a deprecated warning should be issued in the following case: template<typename T> [[deprecated]] class Foo{}; Foo<int> f; This was not the case, because the ClassTemplateSpecializationDecl creation did not also copy the deprecated attribute. Note: I did NOT audit the complete set of attributes to see WHICH ones should be copied, so instead I simply copy ONLY the deprecated attribute. Previous DiffRev: https://reviews.llvm.org/D27486, was reverted. This patch fixes the issues brought up here by the reverter: https://reviews.llvm.org/rL298410 Differential Revision: https://reviews.llvm.org/D31245 llvm-svn: 298634
2017-03-24 02:51:54 +08:00
Attr *instantiateTemplateAttributeForDecl(
const Attr *At, ASTContext &C, Sema &S,
const MultiLevelTemplateArgumentList &TemplateArgs);
Move instantiateTemplateAttribute into the sema namespace, make helpers static. llvm-svn: 149864
2012-02-06 19:13:08 +08:00
}
}
Delayed template instantiation of late-parsed attributes. llvm-svn: 148595
2012-01-21 06:50:54 +08:00
Remove \brief commands from doxygen comments. This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
2018-05-09 09:00:01 +08:00
/// Instantiate the definition of a class from a given pattern.
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
///
/// \param PointOfInstantiation The point of instantiation within the
/// source code.
///
/// \param Instantiation is the declaration whose definition is being
/// instantiated. This will be either a class template specialization
/// or a member class of a class template specialization.
///
/// \param Pattern is the pattern from which the instantiation
/// occurs. This will be either the declaration of a class template or
/// the declaration of a member class of a class template.
///
/// \param TemplateArgs The template arguments to be substituted into
/// the pattern.
///
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
/// \param TSK the kind of implicit or explicit instantiation to perform.
Try to complete a type before looking for conversion functions within that type. Note that we do not produce a diagnostic if the type is incomplete; rather, we just don't look for conversion functions. Fixes PR4660. llvm-svn: 79919
2009-08-24 23:23:48 +08:00
///
/// \param Complain whether to complain if the class cannot be instantiated due
/// to the lack of a definition.
///
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
/// \returns true if an error occurred, false otherwise.
bool
Sema::InstantiateClass(SourceLocation PointOfInstantiation,
CXXRecordDecl *Instantiation, CXXRecordDecl *Pattern,
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,
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
TemplateSpecializationKind TSK,
Try to complete a type before looking for conversion functions within that type. Note that we do not produce a diagnostic if the type is incomplete; rather, we just don't look for conversion functions. Fixes PR4660. llvm-svn: 79919
2009-08-24 23:23:48 +08:00
bool Complain) {
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
CXXRecordDecl *PatternDef
Eliminate the ASTContext parameter from RecordDecl::getDefinition() and CXXRecordDecl::getDefinition(); it's totally unnecessary. No functionality change. llvm-svn: 95836
2010-02-11 09:04:33 +08:00
= cast_or_null<CXXRecordDecl>(Pattern->getDefinition());
PR28794: Don't try to instantiate function templates which are not visible. Reviewed by Richard Smith. llvm-svn: 279164
2016-08-19 06:01:25 +08:00
if (DiagnoseUninstantiableTemplate(PointOfInstantiation, Instantiation,
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
Instantiation->getInstantiatedFromMemberClass(),
Pattern, PatternDef, TSK, Complain))
Implement the basics of implicit instantiation of class templates, in response to attempts to diagnose an "incomplete" type. This will force us to use DiagnoseIncompleteType more regularly (rather than looking at isIncompleteType), but that's also a good thing. Implicit instantiation is still very simplistic, and will create a new definition for the class template specialization (as it should) but it only actually instantiates the base classes and attaches those. Actually instantiating class members will follow. Also, instantiate the types of non-type template parameters before checking them, allowing, e.g., template<typename T, T Value> struct Constant; to work properly. llvm-svn: 65924
2009-03-03 12:44:36 +08:00
return true;
Adds `-ftime-trace` option to clang that produces Chrome `chrome://tracing` compatible JSON profiling output dumps. This change adds hierarchical "time trace" profiling blocks that can be visualized in Chrome, in a "flame chart" style. Each profiling block can have a "detail" string that for example indicates the file being processed, template name being instantiated, function being optimized etc. This is taken from GitHub PR: https://github.com/aras-p/llvm-project-20170507/pull/2 Patch by Aras Pranckevičius. Differential Revision: https://reviews.llvm.org/D58675 llvm-svn: 357340
2019-03-30 16:42:48 +08:00
llvm::TimeTraceScope TimeScope("InstantiateClass", [&]() {
make -ftime-trace also print template arguments Without this, I get e.g. 'PerformPendingInstantiations' -> 'std::fill', now I get 'std::fill<unsigned long *, int>'. Differential Revision: https://reviews.llvm.org/D61822 llvm-svn: 360539
2019-05-12 18:39:21 +08:00
std::string Name;
llvm::raw_string_ostream OS(Name);
Instantiation->getNameForDiagnostic(OS, getPrintingPolicy(),
/*Qualified=*/true);
return Name;
Adds `-ftime-trace` option to clang that produces Chrome `chrome://tracing` compatible JSON profiling output dumps. This change adds hierarchical "time trace" profiling blocks that can be visualized in Chrome, in a "flame chart" style. Each profiling block can have a "detail" string that for example indicates the file being processed, template name being instantiated, function being optimized etc. This is taken from GitHub PR: https://github.com/aras-p/llvm-project-20170507/pull/2 Patch by Aras Pranckevičius. Differential Revision: https://reviews.llvm.org/D58675 llvm-svn: 357340
2019-03-30 16:42:48 +08:00
});
Instantiation for member classes of class templates. Note that only the declarations of member classes are instantiated when the owning class template is instantiated. The definitions of such member classes are instantiated when a complete type is required. This change also introduces the injected-class-name into a class template specialization. llvm-svn: 67707
2009-03-26 05:17:03 +08:00
Pattern = PatternDef;
Implement the basics of implicit instantiation of class templates, in response to attempts to diagnose an "incomplete" type. This will force us to use DiagnoseIncompleteType more regularly (rather than looking at isIncompleteType), but that's also a good thing. Implicit instantiation is still very simplistic, and will create a new definition for the class template specialization (as it should) but it only actually instantiates the base classes and attaches those. Actually instantiating class members will follow. Also, instantiate the types of non-type template parameters before checking them, allowing, e.g., template<typename T, T Value> struct Constant; to work properly. llvm-svn: 65924
2009-03-03 12:44:36 +08:00
Remove \brief commands from doxygen comments. This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
2018-05-09 09:00:01 +08:00
// Record the point of instantiation.
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
if (MemberSpecializationInfo *MSInfo
Check the interactions between explicit instantiations and template specializations. Work in progress; there's more cleanup required to actually use the new CheckSpecializationInstantiationRedecl checker uniformly. llvm-svn: 84185
2009-10-15 23:54:05 +08:00
= Instantiation->getMemberSpecializationInfo()) {
MSInfo->setTemplateSpecializationKind(TSK);
MSInfo->setPointOfInstantiation(PointOfInstantiation);
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
} else if (ClassTemplateSpecializationDecl *Spec
Fix a crash on invalid, http://llvm.org/pr11599 llvm-svn: 146988
2011-12-21 04:32:49 +08:00
= dyn_cast<ClassTemplateSpecializationDecl>(Instantiation)) {
Only set the point of instantiation for an implicit or explicit instantiation once we have committed to performing the instantiation. As part of this, make our makeshift template-instantiation location information suck slightly less. Fixes PR5264. llvm-svn: 85209
2009-10-27 14:26:26 +08:00
Spec->setTemplateSpecializationKind(TSK);
Spec->setPointOfInstantiation(PointOfInstantiation);
Check the interactions between explicit instantiations and template specializations. Work in progress; there's more cleanup required to actually use the new CheckSpecializationInstantiationRedecl checker uniformly. llvm-svn: 84185
2009-10-15 23:54:05 +08:00
}
When a type's definition is instantiated, the definition becomes visible, even if the type's declaration was previously instantiated in an unimported module. (For an imported type definition, this already worked, because the source location is set to the location of the definition, but for locally-instantiated type definitions, it did not.) llvm-svn: 203425
2014-03-10 08:04:29 +08:00
Fix notes regarding the instantiation of member classes (and test 'em). llvm-svn: 67708
2009-03-26 05:23:52 +08:00
InstantiatingTemplate Inst(*this, PointOfInstantiation, Instantiation);
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())
Limit the template instantiation depth to some user-configurable value (default: 99). Beyond this limit, produce an error and consider the current template instantiation a failure. The stack we're building to track the instantiations will, eventually, be used to produce instantiation backtraces from diagnostics within template instantiation. However, we're not quite there yet. This adds a new Clang driver option -ftemplate-depth=NNN, which should eventually be generated from the GCC command-line operation -ftemplate-depth-NNN (note the '-' rather than the '='!). I did not make the driver changes to do this mapping. llvm-svn: 66513
2009-03-10 08:06:19 +08:00
return true;
PR12298 et al: don't recursively instantiate a template specialization from within the instantiation of that same specialization. This could previously happen for eagerly-instantiated function templates, variable templates, exception specifications, default arguments, and a handful of other cases. We still have an issue here for default template arguments that recursively make use of themselves and likewise for substitution into the type of a non-type template parameter, but in those cases we're producing a different entity each time, so they should instead be caught by the instantiation depth limit. However, currently we will typically run out of stack before we reach it. :( llvm-svn: 280190
2016-08-31 10:15:21 +08:00
assert(!Inst.isAlreadyInstantiating() && "should have been caught by caller");
Sink PrettyDeclStackTrace down to the AST library ...and add some very basic stack trace entries for module building. This would have helped track down rdar://problem/38434694 sooner. llvm-svn: 328276
2018-03-23 08:07:18 +08:00
PrettyDeclStackTraceEntry CrashInfo(Context, Instantiation, SourceLocation(),
Produce better pretty stack traces from crashes in template instantiation: add pretty stack trace entries for all cases where we instantiate the definition of something, and include the fully-qualified name with template arguments in the name of the instantiated entity. llvm-svn: 270904
2016-05-27 04:23:13 +08:00
"instantiating class definition");
Limit the template instantiation depth to some user-configurable value (default: 99). Beyond this limit, produce an error and consider the current template instantiation a failure. The stack we're building to track the instantiations will, eventually, be used to produce instantiation backtraces from diagnostics within template instantiation. However, we're not quite there yet. This adds a new Clang driver option -ftemplate-depth=NNN, which should eventually be generated from the GCC command-line operation -ftemplate-depth-NNN (note the '-' rather than the '='!). I did not make the driver changes to do this mapping. llvm-svn: 66513
2009-03-10 08:06:19 +08:00
Implement the basics of implicit instantiation of class templates, in response to attempts to diagnose an "incomplete" type. This will force us to use DiagnoseIncompleteType more regularly (rather than looking at isIncompleteType), but that's also a good thing. Implicit instantiation is still very simplistic, and will create a new definition for the class template specialization (as it should) but it only actually instantiates the base classes and attaches those. Actually instantiating class members will follow. Also, instantiate the types of non-type template parameters before checking them, allowing, e.g., template<typename T, T Value> struct Constant; to work properly. llvm-svn: 65924
2009-03-03 12:44:36 +08:00
// Enter the scope of this instantiation. We don't use
// PushDeclContext because we don't have a scope.
Properly switch into the declaring scope of a template when performing template argument deduction or (more importantly) the final substitution required by such deduction. Makes access control magically work in these cases. Fixes PR6967. llvm-svn: 102572
2010-04-29 08:35:03 +08:00
ContextRAII SavedContext(*this, Instantiation);
[NFC, Scoped Enum] Convert Sema::ExpressionEvaluationContext into a scoped Enum - also replace direct equality checks against the ConstantEvaluated enumerator with isConstantEvaluted(), in anticipation of adding finer granularity to the various ConstantEvaluated contexts and reinstating certain restrictions on where lambda expressions can occur in C++17. - update the clang tablegen backend that uses these Enumerators, and add the relevant scope where needed. llvm-svn: 299316
2017-04-02 05:30:49 +08:00
EnterExpressionEvaluationContext EvalContext(
*this, Sema::ExpressionEvaluationContext::PotentiallyEvaluated);
Implement the basics of implicit instantiation of class templates, in response to attempts to diagnose an "incomplete" type. This will force us to use DiagnoseIncompleteType more regularly (rather than looking at isIncompleteType), but that's also a good thing. Implicit instantiation is still very simplistic, and will create a new definition for the class template specialization (as it should) but it only actually instantiates the base classes and attaches those. Actually instantiating class members will follow. Also, instantiate the types of non-type template parameters before checking them, allowing, e.g., template<typename T, T Value> struct Constant; to work properly. llvm-svn: 65924
2009-03-03 12:44:36 +08:00
Each non-local class instantiation is its own local instantiation scope. Fixes PR6619. llvm-svn: 99377
2010-03-24 09:33:17 +08:00
// If this is an instantiation of a local class, merge this local
// instantiation scope with the enclosing scope. Otherwise, every
// instantiation of a class has its own local instantiation scope.
bool MergeWithParentScope = !Instantiation->isDefinedOutsideFunctionOrMethod();
Move more stuff out of Sema.h. llvm-svn: 112026
2010-08-25 13:32:35 +08:00
LocalInstantiationScope Scope(*this, MergeWithParentScope);
Each non-local class instantiation is its own local instantiation scope. Fixes PR6619. llvm-svn: 99377
2010-03-24 09:33:17 +08:00
[Sema] Prevent InstantiateClass from checking unrelated exception specs. Sema::InstantiateClass should check only exception specs added during class instantiation and ignore already present delayed specs. This fixes a case where we instantiate a class before parsing member initializers, check exceptions for a different class and fail to find a member initializer. Which is required for comparing exception specs for explicitly-defaulted and implicit default constructor. With the fix we are still checking exception specs but only after member initializers are present. Removing errors in crash-unparsed-exception.cpp is acceptable according to discussion in PR24000 because other compilers accept code in crash-unparsed-exception.cpp as valid. rdar://problem/34167492 Reviewers: davide, rsmith Reviewed By: rsmith Subscribers: dim, cfe-commits Differential Revision: https://reviews.llvm.org/D37881 llvm-svn: 313906
2017-09-22 03:54:12 +08:00
// Some class state isn't processed immediately but delayed till class
// instantiation completes. We may not be ready to handle any delayed state
// already on the stack as it might correspond to a different class, so save
// it now and put it back later.
SavePendingParsedClassStateRAII SavedPendingParsedClassState(*this);
[dllexport] Sort out emission order of delayed exported classes Relands r260194 with a fix. If we have a template that transitions from an extern template to an explicitly instantiated dllexport template, we would add that class to the delayed exported class list without flushing it. For explicit instantiations, we can just flush the list of delayed classes immediately. We don't have to worry about the bug fixed in r260194 in this case because explicit instantiations can only occur at file and namespace scope. Fixes PR26490. llvm-svn: 262056
2016-02-27 03:51:02 +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
// Pull attributes from the pattern onto the instantiation.
InstantiateAttrs(TemplateArgs, Pattern, Instantiation);
Implement the basics of implicit instantiation of class templates, in response to attempts to diagnose an "incomplete" type. This will force us to use DiagnoseIncompleteType more regularly (rather than looking at isIncompleteType), but that's also a good thing. Implicit instantiation is still very simplistic, and will create a new definition for the class template specialization (as it should) but it only actually instantiates the base classes and attaches those. Actually instantiating class members will follow. Also, instantiate the types of non-type template parameters before checking them, allowing, e.g., template<typename T, T Value> struct Constant; to work properly. llvm-svn: 65924
2009-03-03 12:44:36 +08:00
// Start the definition of this instantiation.
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
Instantiation->startDefinition();
When a type's definition is instantiated, the definition becomes visible, even if the type's declaration was previously instantiated in an unimported module. (For an imported type definition, this already worked, because the source location is set to the location of the definition, but for locally-instantiated type definitions, it did not.) llvm-svn: 203425
2014-03-10 08:04:29 +08:00
// The instantiation is visible here, even if it was first declared in an
// unimported module.
PR33552: Distinguish between declarations that are owned by no module and declarations that are owned but unconditionally visible. This allows us to set declarations as visible even if they have a local owning module, without losing information. In turn, that means that our Objective-C support can keep on incorrectly assuming the "hidden" bit on the declaration is the whole story with regard to name visibility. This will also be useful once we support the C++ Modules TS export semantics. Objective-C name visibility is still incorrect in any case where the "hidden" bit is not the complete story: for instance, in Objective-C++ the set of visible categories will be wrong during template instantiation, and with local submodule visibility enabled it will be wrong when building modules. Fixing that will require a major overhaul of how visibility is handled for Objective-C (and particularly for categories). llvm-svn: 306075
2017-06-23 09:04:34 +08:00
Instantiation->setVisibleDespiteOwningModule();
When a type's definition is instantiated, the definition becomes visible, even if the type's declaration was previously instantiated in an unimported module. (For an imported type definition, this already worked, because the source location is set to the location of the definition, but for locally-instantiated type definitions, it did not.) llvm-svn: 203425
2014-03-10 08:04:29 +08:00
// FIXME: This loses the as-written tag kind for an explicit instantiation.
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
Instantiation->setTagKind(Pattern->getTagKind());
Implement the basics of implicit instantiation of class templates, in response to attempts to diagnose an "incomplete" type. This will force us to use DiagnoseIncompleteType more regularly (rather than looking at isIncompleteType), but that's also a good thing. Implicit instantiation is still very simplistic, and will create a new definition for the class template specialization (as it should) but it only actually instantiates the base classes and attaches those. Actually instantiating class members will follow. Also, instantiate the types of non-type template parameters before checking them, allowing, e.g., template<typename T, T Value> struct Constant; to work properly. llvm-svn: 65924
2009-03-03 12:44:36 +08:00
Clarify the difference between substitution and instantiation by renaming functions that don't instantiate definitions. llvm-svn: 80037
2009-08-26 06:02:44 +08:00
// Do substitution on the base class specifiers.
if (SubstBaseSpecifiers(Instantiation, Pattern, TemplateArgs))
Be more eager about setting the 'Invalid' bit on an invalid class template instantiation. I wasn't able to reproduce this down to anything small enough to put in our test suite, but it's "obviously" okay to set the invalid bit earlier and precludes a known-broken-but-not-marked-broken class from being used elsewhere. llvm-svn: 159584
2012-07-03 05:00:41 +08:00
Instantiation->setInvalidDecl();
Implement the basics of implicit instantiation of class templates, in response to attempts to diagnose an "incomplete" type. This will force us to use DiagnoseIncompleteType more regularly (rather than looking at isIncompleteType), but that's also a good thing. Implicit instantiation is still very simplistic, and will create a new definition for the class template specialization (as it should) but it only actually instantiates the base classes and attaches those. Actually instantiating class members will follow. Also, instantiate the types of non-type template parameters before checking them, allowing, e.g., template<typename T, T Value> struct Constant; to work properly. llvm-svn: 65924
2009-03-03 12:44:36 +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
TemplateDeclInstantiator Instantiator(*this, Instantiation, TemplateArgs);
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> Fields;
Delayed template instantiation of late-parsed attributes. llvm-svn: 148595
2012-01-21 06:50:54 +08:00
// Delay instantiation of late parsed attributes.
LateInstantiatedAttrVec LateAttrs;
Instantiator.enableLateAttributeInstantiation(&LateAttrs);
[c++20] P1064R0: Allow virtual function calls in constant expression evaluation. This reinstates r360559, reverted in r360580, with a fix to avoid crashing if evaluation-for-overflow mode encounters a virtual call on an object of a class with a virtual base class, and to generally not try to resolve virtual function calls to objects whose (notional) vptrs are not readable. (The standard rules are unclear here, but this seems like a reasonable approach.) llvm-svn: 360635
2019-05-14 07:35:21 +08:00
bool MightHaveConstexprVirtualFunctions = false;
[C++11] Replacing DeclBase iterators decls_begin() and decls_end() with iterator_range decls(). The same is true for the noload versions of these APIs. Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203278
2014-03-08 03:56:05 +08:00
for (auto *Member : Pattern->decls()) {
Don't instantiate members not belonging in the semantic context of the template. e.g. for: template <int i> class A { class B *g; }; 'class B' has the template as lexical context but semantically it is introduced in namespace scope. Fixes rdar://8611125 & http://llvm.org/PR8505 llvm-svn: 118235
2010-11-04 11:18:57 +08:00
// Don't instantiate members not belonging in this semantic context.
// e.g. for:
// @code
// template <int i> class A {
// class B *g;
// };
// @endcode
// 'class B' has the template as lexical context but semantically it is
// introduced in namespace scope.
[C++11] Replacing DeclBase iterators decls_begin() and decls_end() with iterator_range decls(). The same is true for the noload versions of these APIs. Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203278
2014-03-08 03:56:05 +08:00
if (Member->getDeclContext() != Pattern)
Don't instantiate members not belonging in the semantic context of the template. e.g. for: template <int i> class A { class B *g; }; 'class B' has the template as lexical context but semantically it is introduced in namespace scope. Fixes rdar://8611125 & http://llvm.org/PR8505 llvm-svn: 118235
2010-11-04 11:18:57 +08:00
continue;
[Sema] Fix crash on BlockExprs in a default member initializers Clang would crash when instantiating a BlockDecl that appeared in a default-member-initializer of a class template. Fix this by deferring the instantiation until we instantate the BlockExpr. rdar://41200624 Differential revision: https://reviews.llvm.org/D49688 llvm-svn: 337766
2018-07-24 06:47:37 +08:00
// BlockDecls can appear in a default-member-initializer. They must be the
// child of a BlockExpr, so we only know how to instantiate them from there.
Don't instantiate lambda closure types in default member initializers when instantiating the enclosing class. We'll build new lambda closure types if and when we instantiate the default member initializer, and instantiating the closure type by itself can go wrong in cases where we fully-instantiate nested classes (in explicit instantiations of the enclosing class and when the enclosing class is a local class) -- we will instantiate the 'operator()' as a regular function rather than as a lambda call operator, so it doesn't get to use its captures, has the wrong 'this' type, etc.
2020-10-21 08:35:15 +08:00
// Similarly, lambda closure types are recreated when instantiating the
// corresponding LambdaExpr.
if (isa<BlockDecl>(Member) ||
(isa<CXXRecordDecl>(Member) && cast<CXXRecordDecl>(Member)->isLambda()))
[Sema] Fix crash on BlockExprs in a default member initializers Clang would crash when instantiating a BlockDecl that appeared in a default-member-initializer of a class template. Fix this by deferring the instantiation until we instantate the BlockExpr. rdar://41200624 Differential revision: https://reviews.llvm.org/D49688 llvm-svn: 337766
2018-07-24 06:47:37 +08:00
continue;
[C++11] Replacing DeclBase iterators decls_begin() and decls_end() with iterator_range decls(). The same is true for the noload versions of these APIs. Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203278
2014-03-08 03:56:05 +08:00
if (Member->isInvalidDecl()) {
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
Instantiation->setInvalidDecl();
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
continue;
}
[C++11] Replacing DeclBase iterators decls_begin() and decls_end() with iterator_range decls(). The same is true for the noload versions of these APIs. Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203278
2014-03-08 03:56:05 +08:00
Decl *NewMember = Instantiator.Visit(Member);
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 (NewMember) {
Implement support for C++11 in-class initialization of non-static data members. llvm-svn: 132878
2011-06-12 01:19:42 +08:00
if (FieldDecl *Field = dyn_cast<FieldDecl>(NewMember)) {
DeclPtrTy -> Decl * llvm-svn: 111733
2010-08-21 17:40:31 +08:00
Fields.push_back(Field);
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
} else if (EnumDecl *Enum = dyn_cast<EnumDecl>(NewMember)) {
// C++11 [temp.inst]p1: The implicit instantiation of a class template
// specialization causes the implicit instantiation of the definitions
// of unscoped member enumerations.
// Record a point of instantiation for this implicit instantiation.
When defining a forward-declared enum, don't try to attach the definition to a previous declaration if the redeclaration is invalid. That way lies madness. Fixes a crash-on-invalid reported by Abramo. llvm-svn: 153349
2012-03-24 07:09:08 +08:00
if (TSK == TSK_ImplicitInstantiation && !Enum->isScoped() &&
Enum->isCompleteDefinition()) {
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
MemberSpecializationInfo *MSInfo =Enum->getMemberSpecializationInfo();
assert(MSInfo && "no spec info for member enum specialization");
MSInfo->setTemplateSpecializationKind(TSK_ImplicitInstantiation);
MSInfo->setPointOfInstantiation(PointOfInstantiation);
}
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
} else if (StaticAssertDecl *SA = dyn_cast<StaticAssertDecl>(NewMember)) {
if (SA->isFailed()) {
// A static_assert failed. Bail out; instantiating this
// class is probably not meaningful.
Instantiation->setInvalidDecl();
break;
}
[c++20] P1064R0: Allow virtual function calls in constant expression evaluation. This reinstates r360559, reverted in r360580, with a fix to avoid crashing if evaluation-for-overflow mode encounters a virtual call on an object of a class with a virtual base class, and to generally not try to resolve virtual function calls to objects whose (notional) vptrs are not readable. (The standard rules are unclear here, but this seems like a reasonable approach.) llvm-svn: 360635
2019-05-14 07:35:21 +08:00
} else if (CXXMethodDecl *MD = dyn_cast<CXXMethodDecl>(NewMember)) {
if (MD->isConstexpr() && !MD->getFriendObjectKind() &&
(MD->isVirtualAsWritten() || Instantiation->getNumBases()))
MightHaveConstexprVirtualFunctions = true;
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
}
if (NewMember->isInvalidDecl())
Be more eager about setting the 'Invalid' bit on an invalid class template instantiation. I wasn't able to reproduce this down to anything small enough to put in our test suite, but it's "obviously" okay to set the invalid bit earlier and precludes a known-broken-but-not-marked-broken class from being used elsewhere. llvm-svn: 159584
2012-07-03 05:00:41 +08:00
Instantiation->setInvalidDecl();
Refactor instantiation of declarations within a template into a much cleaner visitor framework. Added a visitor for declarations, which is quite similar to the visitor for statatements. llvm-svn: 67104
2009-03-18 05:15:40 +08:00
} else {
// FIXME: Eventually, a NULL return will mean that one of the
Be more eager about setting the 'Invalid' bit on an invalid class template instantiation. I wasn't able to reproduce this down to anything small enough to put in our test suite, but it's "obviously" okay to set the invalid bit earlier and precludes a known-broken-but-not-marked-broken class from being used elsewhere. llvm-svn: 159584
2012-07-03 05:00:41 +08:00
// instantiations was a semantic disaster, and we'll want to mark the
// declaration invalid.
// For now, we expect to skip some members that we can't yet handle.
Add basic, hackish support for instantiation of typedefs in a class template. More importantly, start to sort out the issues regarding complete types and nested-name-specifiers, especially the question of: when do we instantiate a class template specialization that occurs to the left of a '::' in a nested-name-specifier? llvm-svn: 66662
2009-03-12 00:48:53 +08:00
}
}
Implement basic template instantiation for fields. Reshuffle checking for FieldDecls so that the parser and the template instantiation make use of the same semantic checking module. llvm-svn: 66685
2009-03-12 02:59:21 +08:00
// Finish checking fields.
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
ActOnFields(nullptr, Instantiation->getLocation(), Instantiation, Fields,
AttributeList de-listifying: Basically, "AttributeList" loses all list-like mechanisms, ParsedAttributes is switched to use a TinyPtrVector (and a ParsedAttributesView is created to have a non-allocating attributes list). DeclaratorChunk gets the later kind, Declarator/DeclSpec keep ParsedAttributes. Iterators are added to the ParsedAttribute types so that for-loops work. llvm-svn: 336945
2018-07-13 05:09:05 +08:00
SourceLocation(), SourceLocation(), ParsedAttributesView());
[c++20] Fix handling of unqualified lookups from a defaulted comparison function. We need to perform unqualified lookups from the context of a defaulted comparison, but not until we implicitly define the function, at which point we can't do those lookups any more. So perform the lookup from the end of the class containing the =default declaration and store the lookup results on the defaulted function until we synthesize the body.
2019-12-06 05:37:35 +08:00
CheckCompletedCXXClass(nullptr, Instantiation);
Implement support for C++11 in-class initialization of non-static data members. llvm-svn: 132878
2011-06-12 01:19:42 +08:00
MS ABI: Build C++ default argument exprs for exported template classes This was an omission from r232229. llvm-svn: 232554
2015-03-18 05:51:43 +08:00
// Default arguments are parsed, if not instantiated. We can go instantiate
Actually delay processing DelayedDllExportClasses until the outermost class is finished (PR40006) This was already the intention of DelayedDllExportClasses, but code such as this would break it: template<typename> struct Tmpl {}; struct Outer { struct Inner { __declspec(dllexport) Inner() = default; unsigned int x = 0; }; Tmpl<Inner> y; }; ActOnFinishCXXNonNestedClass() would get called when the instantiation of Templ<Inner> is finished, even though the compiler is still not finished with Outer, causing the compile fail. This hooks into Sema::{Push,Pop}ParsingClass() to avoid calling ActOnFinishCXXNonNestedClass() for template instantiations while a class is being parsed. Differential revision: https://reviews.llvm.org/D70905
2019-12-02 23:25:23 +08:00
// default arg exprs for default constructors if necessary now. Unless we're
// parsing a class, in which case wait until that's finished.
if (ParsingClassDepth == 0)
ActOnFinishCXXNonNestedClass();
MS ABI: Build C++ default argument exprs for exported template classes This was an omission from r232229. llvm-svn: 232554
2015-03-18 05:51:43 +08:00
Delayed template instantiation of late-parsed attributes. llvm-svn: 148595
2012-01-21 06:50:54 +08:00
// Instantiate late parsed attributes, and attach them to their decls.
// See Sema::InstantiateAttrs
for (LateInstantiatedAttrVec::iterator I = LateAttrs.begin(),
E = LateAttrs.end(); I != E; ++I) {
assert(CurrentInstantiationScope == Instantiator.getStartingScope());
CurrentInstantiationScope = I->Scope;
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>(I->NewDecl);
CXXRecordDecl *ThisContext =
dyn_cast_or_null<CXXRecordDecl>(ND->getDeclContext());
[OpenCL] Add generic AS to 'this' pointer Address spaces are cast into generic before invoking the constructor. Added support for a trailing Qualifiers object in FunctionProtoType. Note: This recommits the previously reverted patch, but now it is commited together with a fix for lldb. Differential Revision: https://reviews.llvm.org/D54862 llvm-svn: 349019
2018-12-13 18:15:27 +08:00
CXXThisScopeRAII ThisScope(*this, ThisContext, Qualifiers(),
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
ND && ND->isCXXInstanceMember());
Delayed template instantiation of late-parsed attributes. llvm-svn: 148595
2012-01-21 06:50:54 +08:00
Attr *NewAttr =
instantiateTemplateAttribute(I->TmplAttr, Context, *this, TemplateArgs);
[clang] Check for nullptr when instantiating late attrs This was already done in SemaTemplateInstantiateDecl.cpp, but not in SemaTemplateInstantiate.cpp. Anecdotally I've seen some clangd crashes where coredumps point to this being a problem, but I cannot reproduce this so far. Differential Revision: https://reviews.llvm.org/D94933
2021-01-19 06:16:05 +08:00
if (NewAttr)
I->NewDecl->addAttr(NewAttr);
Delayed template instantiation of late-parsed attributes. llvm-svn: 148595
2012-01-21 06:50:54 +08:00
LocalInstantiationScope::deleteScopes(I->Scope,
Instantiator.getStartingScope());
}
Instantiator.disableLateAttributeInstantiation();
LateAttrs.clear();
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
ActOnFinishDelayedMemberInitializers(Instantiation);
Implement support for C++11 in-class initialization of non-static data members. llvm-svn: 132878
2011-06-12 01:19:42 +08:00
When a type's definition is instantiated, the definition becomes visible, even if the type's declaration was previously instantiated in an unimported module. (For an imported type definition, this already worked, because the source location is set to the location of the definition, but for locally-instantiated type definitions, it did not.) llvm-svn: 203425
2014-03-10 08:04:29 +08:00
// FIXME: We should do something similar for explicit instantiations so they
// end up in the right module.
Fixed implicit instantiations source range. llvm-svn: 144977
2011-11-18 16:08:52 +08:00
if (TSK == TSK_ImplicitInstantiation) {
For class template implicit instantiation, also update its location to point to the pattern template that it came from, otherwise we had this situation: template <typename T1, typename T2> struct S { }; template <typename T> struct S<T, int> { }; void f() { S<int, int> s; // location of declaration "S<int, int>" was of "S<T1, T2>" not "S<T, int>" } llvm-svn: 150290
2012-02-11 09:59:57 +08:00
Instantiation->setLocation(Pattern->getLocation());
Fixed implicit instantiations source range. llvm-svn: 144977
2011-11-18 16:08:52 +08:00
Instantiation->setLocStart(Pattern->getInnerLocStart());
[AST] Keep track of the left brace source location of a tag decl. This is useful for source modification tools. There will be a follow-up commit using it. llvm-svn: 275590
2016-07-16 02:11:33 +08:00
Instantiation->setBraceRange(Pattern->getBraceRange());
Fixed implicit instantiations source range. llvm-svn: 144977
2011-11-18 16:08:52 +08:00
}
Fixed source range for template implicit instantiations. llvm-svn: 141018
2011-10-04 04:34:03 +08:00
Be more eager about setting the 'Invalid' bit on an invalid class template instantiation. I wasn't able to reproduce this down to anything small enough to put in our test suite, but it's "obviously" okay to set the invalid bit earlier and precludes a known-broken-but-not-marked-broken class from being used elsewhere. llvm-svn: 159584
2012-07-03 05:00:41 +08:00
if (!Instantiation->isInvalidDecl()) {
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
// Perform any dependent diagnostics from the pattern.
[SemaCXX] Handle lack of TypeSourceInfo on special member functions in templated lambdas During template instantiation involving templated lambdas, clang could hit an assertion in `TemplateDeclInstantiator::SubstFunctionType` since the functions are not associated with any `TypeSourceInfo`: `assert(OldTInfo && "substituting function without type source info");` This path is triggered when using templated lambdas like the one added as a test to this patch. To fix this: - Create `TypeSourceInfo`s for special members and make sure the template instantiator can get through all patterns. - Introduce a `SpecialMemberTypeInfoRebuilder` tree transform to rewrite such member function arguments. Without this, we get errors like: `error: only special member functions and comparison operators may be defaulted` since `getDefaultedFunctionKind` can't properly recognize these functions as special members as part of `SetDeclDefaulted`. Fixes PR45828 and PR44848 Differential Revision: https://reviews.llvm.org/D88327
2021-06-23 06:14:26 +08:00
if (Pattern->isDependentContext())
PerformDependentDiagnostics(Pattern, TemplateArgs);
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
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
// Instantiate any out-of-line class template partial
// specializations now.
If a partial specialization of a member template is declared within a class template and defined outside it, don't instantiate it twice when instantiating the surrounding class template specialization. That would cause us to reject the code because we think two partial specializations instantiated to produce the same signature. llvm-svn: 191418
2013-09-26 11:49:48 +08:00
for (TemplateDeclInstantiator::delayed_partial_spec_iterator
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
P = Instantiator.delayed_partial_spec_begin(),
PEnd = Instantiator.delayed_partial_spec_end();
P != PEnd; ++P) {
if (!Instantiator.InstantiateClassTemplatePartialSpecialization(
If a partial specialization of a member template is declared within a class template and defined outside it, don't instantiate it twice when instantiating the surrounding class template specialization. That would cause us to reject the code because we think two partial specializations instantiated to produce the same signature. llvm-svn: 191418
2013-09-26 11:49:48 +08:00
P->first, P->second)) {
Instantiation->setInvalidDecl();
break;
}
}
// Instantiate any out-of-line variable template partial
// specializations now.
for (TemplateDeclInstantiator::delayed_var_partial_spec_iterator
P = Instantiator.delayed_var_partial_spec_begin(),
PEnd = Instantiator.delayed_var_partial_spec_end();
P != PEnd; ++P) {
if (!Instantiator.InstantiateVarTemplatePartialSpecialization(
P->first, P->second)) {
Be more eager about setting the 'Invalid' bit on an invalid class template instantiation. I wasn't able to reproduce this down to anything small enough to put in our test suite, but it's "obviously" okay to set the invalid bit earlier and precludes a known-broken-but-not-marked-broken class from being used elsewhere. llvm-svn: 159584
2012-07-03 05:00:41 +08:00
Instantiation->setInvalidDecl();
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
break;
}
}
}
Implement the basics of implicit instantiation of class templates, in response to attempts to diagnose an "incomplete" type. This will force us to use DiagnoseIncompleteType more regularly (rather than looking at isIncompleteType), but that's also a good thing. Implicit instantiation is still very simplistic, and will create a new definition for the class template specialization (as it should) but it only actually instantiates the base classes and attaches those. Actually instantiating class members will follow. Also, instantiate the types of non-type template parameters before checking them, allowing, e.g., template<typename T, T Value> struct Constant; to work properly. llvm-svn: 65924
2009-03-03 12:44:36 +08:00
// Exit the scope of this instantiation.
Properly switch into the declaring scope of a template when performing template argument deduction or (more importantly) the final substitution required by such deduction. Makes access control magically work in these cases. Fixes PR6967. llvm-svn: 102572
2010-04-29 08:35:03 +08:00
SavedContext.pop();
Implement the basics of implicit instantiation of class templates, in response to attempts to diagnose an "incomplete" type. This will force us to use DiagnoseIncompleteType more regularly (rather than looking at isIncompleteType), but that's also a good thing. Implicit instantiation is still very simplistic, and will create a new definition for the class template specialization (as it should) but it only actually instantiates the base classes and attaches those. Actually instantiating class members will follow. Also, instantiate the types of non-type template parameters before checking them, allowing, e.g., template<typename T, T Value> struct Constant; to work properly. llvm-svn: 65924
2009-03-03 12:44:36 +08:00
Be more eager about setting the 'Invalid' bit on an invalid class template instantiation. I wasn't able to reproduce this down to anything small enough to put in our test suite, but it's "obviously" okay to set the invalid bit earlier and precludes a known-broken-but-not-marked-broken class from being used elsewhere. llvm-svn: 159584
2012-07-03 05:00:41 +08:00
if (!Instantiation->isInvalidDecl()) {
Rework when and how vtables are emitted, by tracking where vtables are "used" (e.g., we will refer to the vtable in the generated code) and when they are defined (i.e., because we've seen the key function definition). Previously, we were effectively tracking "potential definitions" rather than uses, so we were a bit too eager about emitting vtables for classes without key functions. The new scheme: - For every use of a vtable, Sema calls MarkVTableUsed() to indicate the use. For example, this occurs when calling a virtual member function of the class, defining a constructor of that class type, dynamic_cast'ing from that type to a derived class, casting to/through a virtual base class, etc. - For every definition of a vtable, Sema calls MarkVTableUsed() to indicate the definition. This happens at the end of the translation unit for classes whose key function has been defined (so we can delay computation of the key function; see PR6564), and will also occur with explicit template instantiation definitions. - For every vtable defined/used, we mark all of the virtual member functions of that vtable as defined/used, unless we know that the key function is in another translation unit. This instantiates virtual member functions when needed. - At the end of the translation unit, Sema tells CodeGen (via the ASTConsumer) which vtables must be defined (CodeGen will define them) and which may be used (for which CodeGen will define the vtables lazily). From a language perspective, both the old and the new schemes are permissible: we're allowed to instantiate virtual member functions whenever we want per the standard. However, all other C++ compilers were more lazy than we were, and our eagerness was both a performance issue (we instantiated too much) and a portability problem (we broke Boost test cases, which now pass). Notes: (1) There's a ton of churn in the tests, because the order in which vtables get emitted to IR has changed. I've tried to isolate some of the larger tests from these issues. (2) Some diagnostics related to implicitly-instantiated/implicitly-defined virtual member functions have moved to the point of first use/definition. It's better this way. (3) I could use a review of the places where we MarkVTableUsed, to see if I missed any place where the language effectively requires a vtable. Fixes PR7114 and PR6564. llvm-svn: 103718
2010-05-14 00:44:06 +08:00
// Always emit the vtable for an explicit instantiation definition
[c++20] P1064R0: Allow virtual function calls in constant expression evaluation. This reinstates r360559, reverted in r360580, with a fix to avoid crashing if evaluation-for-overflow mode encounters a virtual call on an object of a class with a virtual base class, and to generally not try to resolve virtual function calls to objects whose (notional) vptrs are not readable. (The standard rules are unclear here, but this seems like a reasonable approach.) llvm-svn: 360635
2019-05-14 07:35:21 +08:00
// of a polymorphic class template specialization. Otherwise, eagerly
// instantiate only constexpr virtual functions in preparation for their use
// in constant evaluation.
Rework when and how vtables are emitted, by tracking where vtables are "used" (e.g., we will refer to the vtable in the generated code) and when they are defined (i.e., because we've seen the key function definition). Previously, we were effectively tracking "potential definitions" rather than uses, so we were a bit too eager about emitting vtables for classes without key functions. The new scheme: - For every use of a vtable, Sema calls MarkVTableUsed() to indicate the use. For example, this occurs when calling a virtual member function of the class, defining a constructor of that class type, dynamic_cast'ing from that type to a derived class, casting to/through a virtual base class, etc. - For every definition of a vtable, Sema calls MarkVTableUsed() to indicate the definition. This happens at the end of the translation unit for classes whose key function has been defined (so we can delay computation of the key function; see PR6564), and will also occur with explicit template instantiation definitions. - For every vtable defined/used, we mark all of the virtual member functions of that vtable as defined/used, unless we know that the key function is in another translation unit. This instantiates virtual member functions when needed. - At the end of the translation unit, Sema tells CodeGen (via the ASTConsumer) which vtables must be defined (CodeGen will define them) and which may be used (for which CodeGen will define the vtables lazily). From a language perspective, both the old and the new schemes are permissible: we're allowed to instantiate virtual member functions whenever we want per the standard. However, all other C++ compilers were more lazy than we were, and our eagerness was both a performance issue (we instantiated too much) and a portability problem (we broke Boost test cases, which now pass). Notes: (1) There's a ton of churn in the tests, because the order in which vtables get emitted to IR has changed. I've tried to isolate some of the larger tests from these issues. (2) Some diagnostics related to implicitly-instantiated/implicitly-defined virtual member functions have moved to the point of first use/definition. It's better this way. (3) I could use a review of the places where we MarkVTableUsed, to see if I missed any place where the language effectively requires a vtable. Fixes PR7114 and PR6564. llvm-svn: 103718
2010-05-14 00:44:06 +08:00
if (TSK == TSK_ExplicitInstantiationDefinition)
MarkVTableUsed(PointOfInstantiation, Instantiation, true);
[c++20] P1064R0: Allow virtual function calls in constant expression evaluation. This reinstates r360559, reverted in r360580, with a fix to avoid crashing if evaluation-for-overflow mode encounters a virtual call on an object of a class with a virtual base class, and to generally not try to resolve virtual function calls to objects whose (notional) vptrs are not readable. (The standard rules are unclear here, but this seems like a reasonable approach.) llvm-svn: 360635
2019-05-14 07:35:21 +08:00
else if (MightHaveConstexprVirtualFunctions)
MarkVirtualMembersReferenced(PointOfInstantiation, Instantiation,
/*ConstexprOnly*/ true);
Rework when and how vtables are emitted, by tracking where vtables are "used" (e.g., we will refer to the vtable in the generated code) and when they are defined (i.e., because we've seen the key function definition). Previously, we were effectively tracking "potential definitions" rather than uses, so we were a bit too eager about emitting vtables for classes without key functions. The new scheme: - For every use of a vtable, Sema calls MarkVTableUsed() to indicate the use. For example, this occurs when calling a virtual member function of the class, defining a constructor of that class type, dynamic_cast'ing from that type to a derived class, casting to/through a virtual base class, etc. - For every definition of a vtable, Sema calls MarkVTableUsed() to indicate the definition. This happens at the end of the translation unit for classes whose key function has been defined (so we can delay computation of the key function; see PR6564), and will also occur with explicit template instantiation definitions. - For every vtable defined/used, we mark all of the virtual member functions of that vtable as defined/used, unless we know that the key function is in another translation unit. This instantiates virtual member functions when needed. - At the end of the translation unit, Sema tells CodeGen (via the ASTConsumer) which vtables must be defined (CodeGen will define them) and which may be used (for which CodeGen will define the vtables lazily). From a language perspective, both the old and the new schemes are permissible: we're allowed to instantiate virtual member functions whenever we want per the standard. However, all other C++ compilers were more lazy than we were, and our eagerness was both a performance issue (we instantiated too much) and a portability problem (we broke Boost test cases, which now pass). Notes: (1) There's a ton of churn in the tests, because the order in which vtables get emitted to IR has changed. I've tried to isolate some of the larger tests from these issues. (2) Some diagnostics related to implicitly-instantiated/implicitly-defined virtual member functions have moved to the point of first use/definition. It's better this way. (3) I could use a review of the places where we MarkVTableUsed, to see if I missed any place where the language effectively requires a vtable. Fixes PR7114 and PR6564. llvm-svn: 103718
2010-05-14 00:44:06 +08:00
}
Inform the consumer on invalid template instantiations. Some clients which want to track state need the information whether a template was instantiated and made invalid. Differential revision: https://reviews.llvm.org/D92248
2021-01-05 16:11:33 +08:00
Consumer.HandleTagDeclDefinition(Instantiation);
Be more eager about setting the 'Invalid' bit on an invalid class template instantiation. I wasn't able to reproduce this down to anything small enough to put in our test suite, but it's "obviously" okay to set the invalid bit earlier and precludes a known-broken-but-not-marked-broken class from being used elsewhere. llvm-svn: 159584
2012-07-03 05:00:41 +08:00
return Instantiation->isInvalidDecl();
Implement the basics of implicit instantiation of class templates, in response to attempts to diagnose an "incomplete" type. This will force us to use DiagnoseIncompleteType more regularly (rather than looking at isIncompleteType), but that's also a good thing. Implicit instantiation is still very simplistic, and will create a new definition for the class template specialization (as it should) but it only actually instantiates the base classes and attaches those. Actually instantiating class members will follow. Also, instantiate the types of non-type template parameters before checking them, allowing, e.g., template<typename T, T Value> struct Constant; to work properly. llvm-svn: 65924
2009-03-03 12:44:36 +08:00
}
Introduce a new expression type, UnresolvedDeclRefExpr, that describes dependent qualified-ids such as Fibonacci<N - 1>::value where N is a template parameter. These references are "unresolved" because the name is dependent and, therefore, cannot be resolved to a declaration node (as we would do for a DeclRefExpr or QualifiedDeclRefExpr). UnresolvedDeclRefExprs instantiate to DeclRefExprs, QualifiedDeclRefExprs, etc. Also, be a bit more careful about keeping only a single set of specializations for a class template, and instantiating from the definition of that template rather than a previous declaration. In general, we need a better solution for this for all TagDecls, because it's too easy to accidentally look at a declaration that isn't the definition. We can now process a simple Fibonacci computation described as a template metaprogram. llvm-svn: 67308
2009-03-20 01:26:29 +08:00
Remove \brief commands from doxygen comments. This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
2018-05-09 09:00:01 +08:00
/// Instantiate the definition of an enum from a given pattern.
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
///
/// \param PointOfInstantiation The point of instantiation within the
/// source code.
/// \param Instantiation is the declaration whose definition is being
/// instantiated. This will be a member enumeration of a class
/// temploid specialization, or a local enumeration within a
/// function temploid specialization.
/// \param Pattern The templated declaration from which the instantiation
/// occurs.
/// \param TemplateArgs The template arguments to be substituted into
/// the pattern.
/// \param TSK The kind of implicit or explicit instantiation to perform.
///
/// \return \c true if an error occurred, \c false otherwise.
bool Sema::InstantiateEnum(SourceLocation PointOfInstantiation,
EnumDecl *Instantiation, EnumDecl *Pattern,
const MultiLevelTemplateArgumentList &TemplateArgs,
TemplateSpecializationKind TSK) {
EnumDecl *PatternDef = Pattern->getDefinition();
PR28794: Don't try to instantiate function templates which are not visible. Reviewed by Richard Smith. llvm-svn: 279164
2016-08-19 06:01:25 +08:00
if (DiagnoseUninstantiableTemplate(PointOfInstantiation, Instantiation,
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
Instantiation->getInstantiatedFromMemberEnum(),
Pattern, PatternDef, TSK,/*Complain*/true))
return true;
Pattern = PatternDef;
// Record the point of instantiation.
if (MemberSpecializationInfo *MSInfo
= Instantiation->getMemberSpecializationInfo()) {
MSInfo->setTemplateSpecializationKind(TSK);
MSInfo->setPointOfInstantiation(PointOfInstantiation);
}
InstantiatingTemplate Inst(*this, PointOfInstantiation, Instantiation);
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())
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 true;
PR12298 et al: don't recursively instantiate a template specialization from within the instantiation of that same specialization. This could previously happen for eagerly-instantiated function templates, variable templates, exception specifications, default arguments, and a handful of other cases. We still have an issue here for default template arguments that recursively make use of themselves and likewise for substitution into the type of a non-type template parameter, but in those cases we're producing a different entity each time, so they should instead be caught by the instantiation depth limit. However, currently we will typically run out of stack before we reach it. :( llvm-svn: 280190
2016-08-31 10:15:21 +08:00
if (Inst.isAlreadyInstantiating())
return false;
Sink PrettyDeclStackTrace down to the AST library ...and add some very basic stack trace entries for module building. This would have helped track down rdar://problem/38434694 sooner. llvm-svn: 328276
2018-03-23 08:07:18 +08:00
PrettyDeclStackTraceEntry CrashInfo(Context, Instantiation, SourceLocation(),
Produce better pretty stack traces from crashes in template instantiation: add pretty stack trace entries for all cases where we instantiate the definition of something, and include the fully-qualified name with template arguments in the name of the instantiated entity. llvm-svn: 270904
2016-05-27 04:23:13 +08:00
"instantiating enum definition");
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
When a type's definition is instantiated, the definition becomes visible, even if the type's declaration was previously instantiated in an unimported module. (For an imported type definition, this already worked, because the source location is set to the location of the definition, but for locally-instantiated type definitions, it did not.) llvm-svn: 203425
2014-03-10 08:04:29 +08:00
// The instantiation is visible here, even if it was first declared in an
// unimported module.
PR33552: Distinguish between declarations that are owned by no module and declarations that are owned but unconditionally visible. This allows us to set declarations as visible even if they have a local owning module, without losing information. In turn, that means that our Objective-C support can keep on incorrectly assuming the "hidden" bit on the declaration is the whole story with regard to name visibility. This will also be useful once we support the C++ Modules TS export semantics. Objective-C name visibility is still incorrect in any case where the "hidden" bit is not the complete story: for instance, in Objective-C++ the set of visible categories will be wrong during template instantiation, and with local submodule visibility enabled it will be wrong when building modules. Fixing that will require a major overhaul of how visibility is handled for Objective-C (and particularly for categories). llvm-svn: 306075
2017-06-23 09:04:34 +08:00
Instantiation->setVisibleDespiteOwningModule();
When a type's definition is instantiated, the definition becomes visible, even if the type's declaration was previously instantiated in an unimported module. (For an imported type definition, this already worked, because the source location is set to the location of the definition, but for locally-instantiated type definitions, it did not.) llvm-svn: 203425
2014-03-10 08:04:29 +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
// Enter the scope of this instantiation. We don't use
// PushDeclContext because we don't have a scope.
ContextRAII SavedContext(*this, Instantiation);
[NFC, Scoped Enum] Convert Sema::ExpressionEvaluationContext into a scoped Enum - also replace direct equality checks against the ConstantEvaluated enumerator with isConstantEvaluted(), in anticipation of adding finer granularity to the various ConstantEvaluated contexts and reinstating certain restrictions on where lambda expressions can occur in C++17. - update the clang tablegen backend that uses these Enumerators, and add the relevant scope where needed. llvm-svn: 299316
2017-04-02 05:30:49 +08:00
EnterExpressionEvaluationContext EvalContext(
*this, Sema::ExpressionEvaluationContext::PotentiallyEvaluated);
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
LocalInstantiationScope Scope(*this, /*MergeWithParentScope*/true);
// Pull attributes from the pattern onto the instantiation.
InstantiateAttrs(TemplateArgs, Pattern, Instantiation);
TemplateDeclInstantiator Instantiator(*this, Instantiation, TemplateArgs);
Instantiator.InstantiateEnumDefinition(Instantiation, Pattern);
// Exit the scope of this instantiation.
SavedContext.pop();
return Instantiation->isInvalidDecl();
}
Handle use of default member initializers before end of outermost class Specifically, when we have this situation: struct A { template <typename T> struct B { int m1 = sizeof(A); }; B<int> m2; }; We can't parse m1's initializer eagerly because we need A to be complete. Therefore we wait until the end of A's class scope to parse it. However, we can trigger instantiation of B before the end of A, which will attempt to instantiate the field decls eagerly, and it would build a bad field decl instantiation that said it had an initializer but actually lacked one. Fixed by deferring instantiation of default member initializers until they are needed during constructor analysis. This addresses a long standing FIXME in the code. Fixes PR19195. Reviewed By: rsmith Differential Revision: http://reviews.llvm.org/D5690 llvm-svn: 222192
2014-11-18 07:36:45 +08:00
Remove \brief commands from doxygen comments. This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
2018-05-09 09:00:01 +08:00
/// Instantiate the definition of a field from the given pattern.
Handle use of default member initializers before end of outermost class Specifically, when we have this situation: struct A { template <typename T> struct B { int m1 = sizeof(A); }; B<int> m2; }; We can't parse m1's initializer eagerly because we need A to be complete. Therefore we wait until the end of A's class scope to parse it. However, we can trigger instantiation of B before the end of A, which will attempt to instantiate the field decls eagerly, and it would build a bad field decl instantiation that said it had an initializer but actually lacked one. Fixed by deferring instantiation of default member initializers until they are needed during constructor analysis. This addresses a long standing FIXME in the code. Fixes PR19195. Reviewed By: rsmith Differential Revision: http://reviews.llvm.org/D5690 llvm-svn: 222192
2014-11-18 07:36:45 +08:00
///
/// \param PointOfInstantiation The point of instantiation within the
/// source code.
/// \param Instantiation is the declaration whose definition is being
/// instantiated. This will be a class of a class temploid
/// specialization, or a local enumeration within a function temploid
/// specialization.
/// \param Pattern The templated declaration from which the instantiation
/// occurs.
/// \param TemplateArgs The template arguments to be substituted into
/// the pattern.
///
/// \return \c true if an error occurred, \c false otherwise.
bool Sema::InstantiateInClassInitializer(
SourceLocation PointOfInstantiation, FieldDecl *Instantiation,
FieldDecl *Pattern, const MultiLevelTemplateArgumentList &TemplateArgs) {
// If there is no initializer, we don't need to do anything.
if (!Pattern->hasInClassInitializer())
return false;
assert(Instantiation->getInClassInitStyle() ==
Pattern->getInClassInitStyle() &&
"pattern and instantiation disagree about init style");
// Error out if we haven't parsed the initializer of the pattern yet because
// we are waiting for the closing brace of the outer class.
Expr *OldInit = Pattern->getInClassInitializer();
if (!OldInit) {
RecordDecl *PatternRD = Pattern->getParent();
RecordDecl *OutermostClass = PatternRD->getOuterLexicalRecordContext();
Make diagnostic for use of default member initializer before enclosing class is complete a little more general; it is produced in other cases than the one that it previously talked about. llvm-svn: 287713
2016-11-23 06:55:12 +08:00
Diag(PointOfInstantiation,
Use "default member initializer" instead of "in-class initializer" for diagnostics. This changes some diagnostics to use terminology from the standard rather than invented terminology, which improves consistency with other diagnostics as well. There are no functional changes intended other than wording and naming.
2020-09-30 03:03:29 +08:00
diag::err_default_member_initializer_not_yet_parsed)
Make diagnostic for use of default member initializer before enclosing class is complete a little more general; it is produced in other cases than the one that it previously talked about. llvm-svn: 287713
2016-11-23 06:55:12 +08:00
<< OutermostClass << Pattern;
Use "default member initializer" instead of "in-class initializer" for diagnostics. This changes some diagnostics to use terminology from the standard rather than invented terminology, which improves consistency with other diagnostics as well. There are no functional changes intended other than wording and naming.
2020-09-30 03:03:29 +08:00
Diag(Pattern->getEndLoc(),
diag::note_default_member_initializer_not_yet_parsed);
Handle use of default member initializers before end of outermost class Specifically, when we have this situation: struct A { template <typename T> struct B { int m1 = sizeof(A); }; B<int> m2; }; We can't parse m1's initializer eagerly because we need A to be complete. Therefore we wait until the end of A's class scope to parse it. However, we can trigger instantiation of B before the end of A, which will attempt to instantiate the field decls eagerly, and it would build a bad field decl instantiation that said it had an initializer but actually lacked one. Fixed by deferring instantiation of default member initializers until they are needed during constructor analysis. This addresses a long standing FIXME in the code. Fixes PR19195. Reviewed By: rsmith Differential Revision: http://reviews.llvm.org/D5690 llvm-svn: 222192
2014-11-18 07:36:45 +08:00
Instantiation->setInvalidDecl();
return true;
}
InstantiatingTemplate Inst(*this, PointOfInstantiation, Instantiation);
if (Inst.isInvalid())
return true;
PR12298 et al: don't recursively instantiate a template specialization from within the instantiation of that same specialization. This could previously happen for eagerly-instantiated function templates, variable templates, exception specifications, default arguments, and a handful of other cases. We still have an issue here for default template arguments that recursively make use of themselves and likewise for substitution into the type of a non-type template parameter, but in those cases we're producing a different entity each time, so they should instead be caught by the instantiation depth limit. However, currently we will typically run out of stack before we reach it. :( llvm-svn: 280190
2016-08-31 10:15:21 +08:00
if (Inst.isAlreadyInstantiating()) {
// Error out if we hit an instantiation cycle for this initializer.
Use "default member initializer" instead of "in-class initializer" for diagnostics. This changes some diagnostics to use terminology from the standard rather than invented terminology, which improves consistency with other diagnostics as well. There are no functional changes intended other than wording and naming.
2020-09-30 03:03:29 +08:00
Diag(PointOfInstantiation, diag::err_default_member_initializer_cycle)
PR12298 et al: don't recursively instantiate a template specialization from within the instantiation of that same specialization. This could previously happen for eagerly-instantiated function templates, variable templates, exception specifications, default arguments, and a handful of other cases. We still have an issue here for default template arguments that recursively make use of themselves and likewise for substitution into the type of a non-type template parameter, but in those cases we're producing a different entity each time, so they should instead be caught by the instantiation depth limit. However, currently we will typically run out of stack before we reach it. :( llvm-svn: 280190
2016-08-31 10:15:21 +08:00
<< Instantiation;
return true;
}
Sink PrettyDeclStackTrace down to the AST library ...and add some very basic stack trace entries for module building. This would have helped track down rdar://problem/38434694 sooner. llvm-svn: 328276
2018-03-23 08:07:18 +08:00
PrettyDeclStackTraceEntry CrashInfo(Context, Instantiation, SourceLocation(),
Produce better pretty stack traces from crashes in template instantiation: add pretty stack trace entries for all cases where we instantiate the definition of something, and include the fully-qualified name with template arguments in the name of the instantiated entity. llvm-svn: 270904
2016-05-27 04:23:13 +08:00
"instantiating default member init");
Handle use of default member initializers before end of outermost class Specifically, when we have this situation: struct A { template <typename T> struct B { int m1 = sizeof(A); }; B<int> m2; }; We can't parse m1's initializer eagerly because we need A to be complete. Therefore we wait until the end of A's class scope to parse it. However, we can trigger instantiation of B before the end of A, which will attempt to instantiate the field decls eagerly, and it would build a bad field decl instantiation that said it had an initializer but actually lacked one. Fixed by deferring instantiation of default member initializers until they are needed during constructor analysis. This addresses a long standing FIXME in the code. Fixes PR19195. Reviewed By: rsmith Differential Revision: http://reviews.llvm.org/D5690 llvm-svn: 222192
2014-11-18 07:36:45 +08:00
// Enter the scope of this instantiation. We don't use PushDeclContext because
// we don't have a scope.
ContextRAII SavedContext(*this, Instantiation->getParent());
[NFC, Scoped Enum] Convert Sema::ExpressionEvaluationContext into a scoped Enum - also replace direct equality checks against the ConstantEvaluated enumerator with isConstantEvaluted(), in anticipation of adding finer granularity to the various ConstantEvaluated contexts and reinstating certain restrictions on where lambda expressions can occur in C++17. - update the clang tablegen backend that uses these Enumerators, and add the relevant scope where needed. llvm-svn: 299316
2017-04-02 05:30:49 +08:00
EnterExpressionEvaluationContext EvalContext(
*this, Sema::ExpressionEvaluationContext::PotentiallyEvaluated);
Handle use of default member initializers before end of outermost class Specifically, when we have this situation: struct A { template <typename T> struct B { int m1 = sizeof(A); }; B<int> m2; }; We can't parse m1's initializer eagerly because we need A to be complete. Therefore we wait until the end of A's class scope to parse it. However, we can trigger instantiation of B before the end of A, which will attempt to instantiate the field decls eagerly, and it would build a bad field decl instantiation that said it had an initializer but actually lacked one. Fixed by deferring instantiation of default member initializers until they are needed during constructor analysis. This addresses a long standing FIXME in the code. Fixes PR19195. Reviewed By: rsmith Differential Revision: http://reviews.llvm.org/D5690 llvm-svn: 222192
2014-11-18 07:36:45 +08:00
Combine instantiation context of field initializer with context of class. Inclass initializer is instantiated in its own LocalInstantiationScope. It causes problems when instantiating local classes - when instantiation scope is searched for DeclContext of the field, the search fails. As a solution, the instantiation scope of field initializer is combined with its outer scope. This patch fixes PR23194. Differential Revision: http://reviews.llvm.org/D9258 llvm-svn: 236005
2015-04-29 01:58:47 +08:00
LocalInstantiationScope Scope(*this, true);
Handle use of default member initializers before end of outermost class Specifically, when we have this situation: struct A { template <typename T> struct B { int m1 = sizeof(A); }; B<int> m2; }; We can't parse m1's initializer eagerly because we need A to be complete. Therefore we wait until the end of A's class scope to parse it. However, we can trigger instantiation of B before the end of A, which will attempt to instantiate the field decls eagerly, and it would build a bad field decl instantiation that said it had an initializer but actually lacked one. Fixed by deferring instantiation of default member initializers until they are needed during constructor analysis. This addresses a long standing FIXME in the code. Fixes PR19195. Reviewed By: rsmith Differential Revision: http://reviews.llvm.org/D5690 llvm-svn: 222192
2014-11-18 07:36:45 +08:00
// Instantiate the initializer.
ActOnStartCXXInClassMemberInitializer();
[OpenCL] Add generic AS to 'this' pointer Address spaces are cast into generic before invoking the constructor. Added support for a trailing Qualifiers object in FunctionProtoType. Note: This recommits the previously reverted patch, but now it is commited together with a fix for lldb. Differential Revision: https://reviews.llvm.org/D54862 llvm-svn: 349019
2018-12-13 18:15:27 +08:00
CXXThisScopeRAII ThisScope(*this, Instantiation->getParent(), Qualifiers());
Handle use of default member initializers before end of outermost class Specifically, when we have this situation: struct A { template <typename T> struct B { int m1 = sizeof(A); }; B<int> m2; }; We can't parse m1's initializer eagerly because we need A to be complete. Therefore we wait until the end of A's class scope to parse it. However, we can trigger instantiation of B before the end of A, which will attempt to instantiate the field decls eagerly, and it would build a bad field decl instantiation that said it had an initializer but actually lacked one. Fixed by deferring instantiation of default member initializers until they are needed during constructor analysis. This addresses a long standing FIXME in the code. Fixes PR19195. Reviewed By: rsmith Differential Revision: http://reviews.llvm.org/D5690 llvm-svn: 222192
2014-11-18 07:36:45 +08:00
ExprResult NewInit = SubstInitializer(OldInit, TemplateArgs,
/*CXXDirectInit=*/false);
Expr *Init = NewInit.get();
assert((!Init || !isa<ParenListExpr>(Init)) && "call-style init in class");
ActOnFinishCXXInClassMemberInitializer(
Port getLocStart -> getBeginLoc Reviewers: teemperor! Subscribers: jholewinski, whisperity, jfb, cfe-commits Differential Revision: https://reviews.llvm.org/D50350 llvm-svn: 339385
2018-08-10 05:08:08 +08:00
Instantiation, Init ? Init->getBeginLoc() : SourceLocation(), Init);
Handle use of default member initializers before end of outermost class Specifically, when we have this situation: struct A { template <typename T> struct B { int m1 = sizeof(A); }; B<int> m2; }; We can't parse m1's initializer eagerly because we need A to be complete. Therefore we wait until the end of A's class scope to parse it. However, we can trigger instantiation of B before the end of A, which will attempt to instantiate the field decls eagerly, and it would build a bad field decl instantiation that said it had an initializer but actually lacked one. Fixed by deferring instantiation of default member initializers until they are needed during constructor analysis. This addresses a long standing FIXME in the code. Fixes PR19195. Reviewed By: rsmith Differential Revision: http://reviews.llvm.org/D5690 llvm-svn: 222192
2014-11-18 07:36:45 +08:00
PR29097: add an update record when we instantiate the default member initializer of an imported field. llvm-svn: 279667
2016-08-25 05:25:37 +08:00
if (auto *L = getASTMutationListener())
L->DefaultMemberInitializerInstantiated(Instantiation);
Handle use of default member initializers before end of outermost class Specifically, when we have this situation: struct A { template <typename T> struct B { int m1 = sizeof(A); }; B<int> m2; }; We can't parse m1's initializer eagerly because we need A to be complete. Therefore we wait until the end of A's class scope to parse it. However, we can trigger instantiation of B before the end of A, which will attempt to instantiate the field decls eagerly, and it would build a bad field decl instantiation that said it had an initializer but actually lacked one. Fixed by deferring instantiation of default member initializers until they are needed during constructor analysis. This addresses a long standing FIXME in the code. Fixes PR19195. Reviewed By: rsmith Differential Revision: http://reviews.llvm.org/D5690 llvm-svn: 222192
2014-11-18 07:36:45 +08:00
// Return true if the in-class initializer is still missing.
return !Instantiation->getInClassInitializer();
}
Introduce support for emitting diagnostics (warnings + their notes) that are suppressed during template argument deduction. This change queues diagnostics computed during template argument deduction. Then, if the resulting function template specialization or partial specialization is chosen by overload resolution or partial ordering (respectively), we will emit the queued diagnostics at that point. This addresses most of PR6784. However, the check for unnamed/local template arguments (which existed before this change) is still only skin-deep, and needs to be extended to look deeper into types. It must be improved to finish PR6784. llvm-svn: 116373
2010-10-13 07:32:35 +08:00
namespace {
Remove \brief commands from doxygen comments. This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
2018-05-09 09:00:01 +08:00
/// A partial specialization whose template arguments have matched
Introduce support for emitting diagnostics (warnings + their notes) that are suppressed during template argument deduction. This change queues diagnostics computed during template argument deduction. Then, if the resulting function template specialization or partial specialization is chosen by overload resolution or partial ordering (respectively), we will emit the queued diagnostics at that point. This addresses most of PR6784. However, the check for unnamed/local template arguments (which existed before this change) is still only skin-deep, and needs to be extended to look deeper into types. It must be improved to finish PR6784. llvm-svn: 116373
2010-10-13 07:32:35 +08:00
/// a given template-id.
struct PartialSpecMatchResult {
ClassTemplatePartialSpecializationDecl *Partial;
TemplateArgumentList *Args;
};
}
Fix a couple of class template argument deduction crashes with libc++'s tuple. RecursiveASTVisitor was not properly recursing through a SubstTemplateTypeParmTypes, resulting in crashes in pack expansion where we couldn't always find an unexpanded pack within a pack expansion. We also have an issue where substitution of deduced template arguments for an implicit deduction guide creates the "impossible" case of naming a non-dependent member of the current instantiation, but within a specialization that is actually instantiated from a different (partial/explicit) specialization of the template. We resolve this by declaring that constructors that do so can only be used to deduce specializations of the primary template. I'm running this past CWG to see if people agree this is the right thing to do. llvm-svn: 304862
2017-06-07 10:42:27 +08:00
bool Sema::usesPartialOrExplicitSpecialization(
SourceLocation Loc, ClassTemplateSpecializationDecl *ClassTemplateSpec) {
if (ClassTemplateSpec->getTemplateSpecializationKind() ==
TSK_ExplicitSpecialization)
return true;
SmallVector<ClassTemplatePartialSpecializationDecl *, 4> PartialSpecs;
ClassTemplateSpec->getSpecializedTemplate()
->getPartialSpecializations(PartialSpecs);
for (unsigned I = 0, N = PartialSpecs.size(); I != N; ++I) {
TemplateDeductionInfo Info(Loc);
if (!DeduceTemplateArguments(PartialSpecs[I],
ClassTemplateSpec->getTemplateArgs(), Info))
return true;
}
return false;
}
PR31514: Add recursive self-instantiation check during template argument deduction in partial ordering. This prevents us from crashing due to attempting to instantiate the same class template specialization definition multiple times. (Debug builds also appear to sometimes hit the stack limit before hitting the instantiation depth limit in this case.) llvm-svn: 291407
2017-01-09 06:45:21 +08:00
/// Get the instantiation pattern to use to instantiate the definition of a
/// given ClassTemplateSpecializationDecl (either the pattern of the primary
/// template or of a partial specialization).
Ensure that we don't leave behind "InstantiatingSpecialization" entries after destroying an InstantiatingTemplate object. This previously caused us to (silently!) bail out of class template instantiation, thinking we'd produced an error, in some corner cases.
2020-12-11 08:49:27 +08:00
static ActionResult<CXXRecordDecl *>
PR31514: Add recursive self-instantiation check during template argument deduction in partial ordering. This prevents us from crashing due to attempting to instantiate the same class template specialization definition multiple times. (Debug builds also appear to sometimes hit the stack limit before hitting the instantiation depth limit in this case.) llvm-svn: 291407
2017-01-09 06:45:21 +08:00
getPatternForClassTemplateSpecialization(
Sema &S, SourceLocation PointOfInstantiation,
Refactor for clarity and simplicity. llvm-svn: 188974
2013-08-22 08:59:14 +08:00
ClassTemplateSpecializationDecl *ClassTemplateSpec,
Ensure that we don't leave behind "InstantiatingSpecialization" entries after destroying an InstantiatingTemplate object. This previously caused us to (silently!) bail out of class template instantiation, thinking we'd produced an error, in some corner cases.
2020-12-11 08:49:27 +08:00
TemplateSpecializationKind TSK) {
PR31514: Add recursive self-instantiation check during template argument deduction in partial ordering. This prevents us from crashing due to attempting to instantiate the same class template specialization definition multiple times. (Debug builds also appear to sometimes hit the stack limit before hitting the instantiation depth limit in this case.) llvm-svn: 291407
2017-01-09 06:45:21 +08:00
Sema::InstantiatingTemplate Inst(S, PointOfInstantiation, ClassTemplateSpec);
Ensure that we don't leave behind "InstantiatingSpecialization" entries after destroying an InstantiatingTemplate object. This previously caused us to (silently!) bail out of class template instantiation, thinking we'd produced an error, in some corner cases.
2020-12-11 08:49:27 +08:00
if (Inst.isInvalid())
return {/*Invalid=*/true};
if (Inst.isAlreadyInstantiating())
return {/*Invalid=*/false};
PR31514: Add recursive self-instantiation check during template argument deduction in partial ordering. This prevents us from crashing due to attempting to instantiate the same class template specialization definition multiple times. (Debug builds also appear to sometimes hit the stack limit before hitting the instantiation depth limit in this case.) llvm-svn: 291407
2017-01-09 06:45:21 +08:00
[Sema] Fix assertion when constructor is disabled with partially specialized template. The added test case was triggering assertion > Assertion failed: (!SpecializedTemplate.is<SpecializedPartialSpecialization*>() && "Already set to a class template partial specialization!"), function setInstantiationOf, file clang/include/clang/AST/DeclTemplate.h, line 1825. It was happening with ClassTemplateSpecializationDecl `enable_if_not_same<int, int>`. Because this template is specialized for equal types not to have a definition, it wasn't instantiated and its specialization kind remained TSK_Undeclared. And because it was implicit instantiation, we didn't mark the decl as invalid. So when we try to find the best matching partial specialization the second time, we hit the assertion as partial specialization is already set. Fix by reusing stored partial specialization when available, instead of looking for the best match every time. rdar://problem/39524996 Reviewers: rsmith, arphaman Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D46909 llvm-svn: 332509
2018-05-17 02:28:58 +08:00
llvm::PointerUnion<ClassTemplateDecl *,
ClassTemplatePartialSpecializationDecl *>
Specialized = ClassTemplateSpec->getSpecializedTemplateOrPartial();
if (!Specialized.is<ClassTemplatePartialSpecializationDecl *>()) {
// Find best matching specialization.
ClassTemplateDecl *Template = ClassTemplateSpec->getSpecializedTemplate();
// C++ [temp.class.spec.match]p1:
// When a class template is used in a context that requires an
// instantiation of the class, it is necessary to determine
// whether the instantiation is to be generated using the primary
// template or one of the partial specializations. This is done by
// matching the template arguments of the class template
// specialization with the template argument lists of the partial
// specializations.
typedef PartialSpecMatchResult MatchResult;
SmallVector<MatchResult, 4> Matched;
SmallVector<ClassTemplatePartialSpecializationDecl *, 4> PartialSpecs;
Template->getPartialSpecializations(PartialSpecs);
TemplateSpecCandidateSet FailedCandidates(PointOfInstantiation);
for (unsigned I = 0, N = PartialSpecs.size(); I != N; ++I) {
ClassTemplatePartialSpecializationDecl *Partial = PartialSpecs[I];
TemplateDeductionInfo Info(FailedCandidates.getLocation());
if (Sema::TemplateDeductionResult Result = S.DeduceTemplateArguments(
Partial, ClassTemplateSpec->getTemplateArgs(), Info)) {
// Store the failed-deduction information for use in diagnostics, later.
// TODO: Actually use the failed-deduction info?
FailedCandidates.addCandidate().set(
DeclAccessPair::make(Template, AS_public), Partial,
MakeDeductionFailureInfo(S.Context, Result, Info));
(void)Result;
} else {
Matched.push_back(PartialSpecMatchResult());
Matched.back().Partial = Partial;
Matched.back().Args = Info.take();
}
Improve template argument deduction to keep track of why template argument deduction failed. For example, given template<typename T> struct is_same<T, T> { ... }; template argument deduction will fail for is_same<int, float>, and now reports enough information Right now, we don't do anything with this extra information, but it can be used for informative diagnostics that say, e.g., "template argument deduction failed because T was deduced to 'int' in one context and 'float' in another". llvm-svn: 73237
2009-06-13 02:26:56 +08:00
}
Initial infrastructure for class template partial specialization. Here we have the basics of declaring and storing class template partial specializations, matching class template partial specializations at instantiation time via (limited) template argument deduction, and using the class template partial specialization's pattern for instantiation. This patch is enough to make a simple is_pointer type trait work, but not much else. llvm-svn: 72662
2009-05-31 17:31:02 +08:00
[Sema] Fix assertion when constructor is disabled with partially specialized template. The added test case was triggering assertion > Assertion failed: (!SpecializedTemplate.is<SpecializedPartialSpecialization*>() && "Already set to a class template partial specialization!"), function setInstantiationOf, file clang/include/clang/AST/DeclTemplate.h, line 1825. It was happening with ClassTemplateSpecializationDecl `enable_if_not_same<int, int>`. Because this template is specialized for equal types not to have a definition, it wasn't instantiated and its specialization kind remained TSK_Undeclared. And because it was implicit instantiation, we didn't mark the decl as invalid. So when we try to find the best matching partial specialization the second time, we hit the assertion as partial specialization is already set. Fix by reusing stored partial specialization when available, instead of looking for the best match every time. rdar://problem/39524996 Reviewers: rsmith, arphaman Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D46909 llvm-svn: 332509
2018-05-17 02:28:58 +08:00
// If we're dealing with a member template where the template parameters
// have been instantiated, this provides the original template parameters
// from which the member template's parameters were instantiated.
Remove a whole lot of unused variables There are about 30 removed in this patch, generated by a new FixIt I haven't got round to submitting yet. llvm-svn: 195814
2013-11-27 13:22:15 +08:00
[Sema] Fix assertion when constructor is disabled with partially specialized template. The added test case was triggering assertion > Assertion failed: (!SpecializedTemplate.is<SpecializedPartialSpecialization*>() && "Already set to a class template partial specialization!"), function setInstantiationOf, file clang/include/clang/AST/DeclTemplate.h, line 1825. It was happening with ClassTemplateSpecializationDecl `enable_if_not_same<int, int>`. Because this template is specialized for equal types not to have a definition, it wasn't instantiated and its specialization kind remained TSK_Undeclared. And because it was implicit instantiation, we didn't mark the decl as invalid. So when we try to find the best matching partial specialization the second time, we hit the assertion as partial specialization is already set. Fix by reusing stored partial specialization when available, instead of looking for the best match every time. rdar://problem/39524996 Reviewers: rsmith, arphaman Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D46909 llvm-svn: 332509
2018-05-17 02:28:58 +08:00
if (Matched.size() >= 1) {
SmallVectorImpl<MatchResult>::iterator Best = Matched.begin();
if (Matched.size() == 1) {
// -- If exactly one matching specialization is found, the
// instantiation is generated from that specialization.
// We don't need to do anything for this.
} else {
// -- If more than one matching specialization is found, the
// partial order rules (14.5.4.2) are used to determine
// whether one of the specializations is more specialized
// than the others. If none of the specializations is more
// specialized than all of the other matching
// specializations, then the use of the class template is
// ambiguous and the program is ill-formed.
for (SmallVectorImpl<MatchResult>::iterator P = Best + 1,
PEnd = Matched.end();
P != PEnd; ++P) {
if (S.getMoreSpecializedPartialSpecialization(
P->Partial, Best->Partial, PointOfInstantiation) ==
P->Partial)
Best = P;
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
}
[Sema] Fix assertion when constructor is disabled with partially specialized template. The added test case was triggering assertion > Assertion failed: (!SpecializedTemplate.is<SpecializedPartialSpecialization*>() && "Already set to a class template partial specialization!"), function setInstantiationOf, file clang/include/clang/AST/DeclTemplate.h, line 1825. It was happening with ClassTemplateSpecializationDecl `enable_if_not_same<int, int>`. Because this template is specialized for equal types not to have a definition, it wasn't instantiated and its specialization kind remained TSK_Undeclared. And because it was implicit instantiation, we didn't mark the decl as invalid. So when we try to find the best matching partial specialization the second time, we hit the assertion as partial specialization is already set. Fix by reusing stored partial specialization when available, instead of looking for the best match every time. rdar://problem/39524996 Reviewers: rsmith, arphaman Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D46909 llvm-svn: 332509
2018-05-17 02:28:58 +08:00
// Determine if the best partial specialization is more specialized than
// the others.
bool Ambiguous = false;
Use SmallVectorImpl instead of SmallVector for iterators and references to avoid specifying the vector size unnecessarily. llvm-svn: 185610
2013-07-04 11:08:24 +08:00
for (SmallVectorImpl<MatchResult>::iterator P = Matched.begin(),
PEnd = Matched.end();
[Sema] Fix assertion when constructor is disabled with partially specialized template. The added test case was triggering assertion > Assertion failed: (!SpecializedTemplate.is<SpecializedPartialSpecialization*>() && "Already set to a class template partial specialization!"), function setInstantiationOf, file clang/include/clang/AST/DeclTemplate.h, line 1825. It was happening with ClassTemplateSpecializationDecl `enable_if_not_same<int, int>`. Because this template is specialized for equal types not to have a definition, it wasn't instantiated and its specialization kind remained TSK_Undeclared. And because it was implicit instantiation, we didn't mark the decl as invalid. So when we try to find the best matching partial specialization the second time, we hit the assertion as partial specialization is already set. Fix by reusing stored partial specialization when available, instead of looking for the best match every time. rdar://problem/39524996 Reviewers: rsmith, arphaman Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D46909 llvm-svn: 332509
2018-05-17 02:28:58 +08:00
P != PEnd; ++P) {
if (P != Best && S.getMoreSpecializedPartialSpecialization(
P->Partial, Best->Partial,
PointOfInstantiation) != Best->Partial) {
Ambiguous = true;
break;
}
}
if (Ambiguous) {
// Partial ordering did not produce a clear winner. Complain.
Inst.Clear();
ClassTemplateSpec->setInvalidDecl();
S.Diag(PointOfInstantiation,
diag::err_partial_spec_ordering_ambiguous)
<< ClassTemplateSpec;
// Print the matching partial specializations.
for (SmallVectorImpl<MatchResult>::iterator P = Matched.begin(),
PEnd = Matched.end();
P != PEnd; ++P)
S.Diag(P->Partial->getLocation(), diag::note_partial_spec_match)
<< S.getTemplateArgumentBindingsText(
P->Partial->getTemplateParameters(), *P->Args);
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
Ensure that we don't leave behind "InstantiatingSpecialization" entries after destroying an InstantiatingTemplate object. This previously caused us to (silently!) bail out of class template instantiation, thinking we'd produced an error, in some corner cases.
2020-12-11 08:49:27 +08:00
return {/*Invalid=*/true};
[Sema] Fix assertion when constructor is disabled with partially specialized template. The added test case was triggering assertion > Assertion failed: (!SpecializedTemplate.is<SpecializedPartialSpecialization*>() && "Already set to a class template partial specialization!"), function setInstantiationOf, file clang/include/clang/AST/DeclTemplate.h, line 1825. It was happening with ClassTemplateSpecializationDecl `enable_if_not_same<int, int>`. Because this template is specialized for equal types not to have a definition, it wasn't instantiated and its specialization kind remained TSK_Undeclared. And because it was implicit instantiation, we didn't mark the decl as invalid. So when we try to find the best matching partial specialization the second time, we hit the assertion as partial specialization is already set. Fix by reusing stored partial specialization when available, instead of looking for the best match every time. rdar://problem/39524996 Reviewers: rsmith, arphaman Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D46909 llvm-svn: 332509
2018-05-17 02:28:58 +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
}
[Sema] Fix assertion when constructor is disabled with partially specialized template. The added test case was triggering assertion > Assertion failed: (!SpecializedTemplate.is<SpecializedPartialSpecialization*>() && "Already set to a class template partial specialization!"), function setInstantiationOf, file clang/include/clang/AST/DeclTemplate.h, line 1825. It was happening with ClassTemplateSpecializationDecl `enable_if_not_same<int, int>`. Because this template is specialized for equal types not to have a definition, it wasn't instantiated and its specialization kind remained TSK_Undeclared. And because it was implicit instantiation, we didn't mark the decl as invalid. So when we try to find the best matching partial specialization the second time, we hit the assertion as partial specialization is already set. Fix by reusing stored partial specialization when available, instead of looking for the best match every time. rdar://problem/39524996 Reviewers: rsmith, arphaman Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D46909 llvm-svn: 332509
2018-05-17 02:28:58 +08:00
ClassTemplateSpec->setInstantiationOf(Best->Partial, Best->Args);
} else {
// -- If no matches are found, the instantiation is generated
// from the primary template.
Implement partial ordering of class template partial specializations (C++ [temp.class.order]). llvm-svn: 81866
2009-09-16 00:23:51 +08:00
}
[Sema] Fix assertion when constructor is disabled with partially specialized template. The added test case was triggering assertion > Assertion failed: (!SpecializedTemplate.is<SpecializedPartialSpecialization*>() && "Already set to a class template partial specialization!"), function setInstantiationOf, file clang/include/clang/AST/DeclTemplate.h, line 1825. It was happening with ClassTemplateSpecializationDecl `enable_if_not_same<int, int>`. Because this template is specialized for equal types not to have a definition, it wasn't instantiated and its specialization kind remained TSK_Undeclared. And because it was implicit instantiation, we didn't mark the decl as invalid. So when we try to find the best matching partial specialization the second time, we hit the assertion as partial specialization is already set. Fix by reusing stored partial specialization when available, instead of looking for the best match every time. rdar://problem/39524996 Reviewers: rsmith, arphaman Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D46909 llvm-svn: 332509
2018-05-17 02:28:58 +08:00
}
CXXRecordDecl *Pattern = nullptr;
Specialized = ClassTemplateSpec->getSpecializedTemplateOrPartial();
if (auto *PartialSpec =
Specialized.dyn_cast<ClassTemplatePartialSpecializationDecl *>()) {
Implement partial ordering of class template partial specializations (C++ [temp.class.order]). llvm-svn: 81866
2009-09-16 00:23:51 +08:00
// Instantiate using the best class template partial specialization.
[Sema] Fix assertion when constructor is disabled with partially specialized template. The added test case was triggering assertion > Assertion failed: (!SpecializedTemplate.is<SpecializedPartialSpecialization*>() && "Already set to a class template partial specialization!"), function setInstantiationOf, file clang/include/clang/AST/DeclTemplate.h, line 1825. It was happening with ClassTemplateSpecializationDecl `enable_if_not_same<int, int>`. Because this template is specialized for equal types not to have a definition, it wasn't instantiated and its specialization kind remained TSK_Undeclared. And because it was implicit instantiation, we didn't mark the decl as invalid. So when we try to find the best matching partial specialization the second time, we hit the assertion as partial specialization is already set. Fix by reusing stored partial specialization when available, instead of looking for the best match every time. rdar://problem/39524996 Reviewers: rsmith, arphaman Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D46909 llvm-svn: 332509
2018-05-17 02:28:58 +08:00
while (PartialSpec->getInstantiatedFromMember()) {
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 we've found an explicit specialization of this class template,
// stop here and use that as the pattern.
[Sema] Fix assertion when constructor is disabled with partially specialized template. The added test case was triggering assertion > Assertion failed: (!SpecializedTemplate.is<SpecializedPartialSpecialization*>() && "Already set to a class template partial specialization!"), function setInstantiationOf, file clang/include/clang/AST/DeclTemplate.h, line 1825. It was happening with ClassTemplateSpecializationDecl `enable_if_not_same<int, int>`. Because this template is specialized for equal types not to have a definition, it wasn't instantiated and its specialization kind remained TSK_Undeclared. And because it was implicit instantiation, we didn't mark the decl as invalid. So when we try to find the best matching partial specialization the second time, we hit the assertion as partial specialization is already set. Fix by reusing stored partial specialization when available, instead of looking for the best match every time. rdar://problem/39524996 Reviewers: rsmith, arphaman Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D46909 llvm-svn: 332509
2018-05-17 02:28:58 +08:00
if (PartialSpec->isMemberSpecialization())
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
break;
[Sema] Fix assertion when constructor is disabled with partially specialized template. The added test case was triggering assertion > Assertion failed: (!SpecializedTemplate.is<SpecializedPartialSpecialization*>() && "Already set to a class template partial specialization!"), function setInstantiationOf, file clang/include/clang/AST/DeclTemplate.h, line 1825. It was happening with ClassTemplateSpecializationDecl `enable_if_not_same<int, int>`. Because this template is specialized for equal types not to have a definition, it wasn't instantiated and its specialization kind remained TSK_Undeclared. And because it was implicit instantiation, we didn't mark the decl as invalid. So when we try to find the best matching partial specialization the second time, we hit the assertion as partial specialization is already set. Fix by reusing stored partial specialization when available, instead of looking for the best match every time. rdar://problem/39524996 Reviewers: rsmith, arphaman Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D46909 llvm-svn: 332509
2018-05-17 02:28:58 +08:00
PartialSpec = PartialSpec->getInstantiatedFromMember();
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
}
[Sema] Fix assertion when constructor is disabled with partially specialized template. The added test case was triggering assertion > Assertion failed: (!SpecializedTemplate.is<SpecializedPartialSpecialization*>() && "Already set to a class template partial specialization!"), function setInstantiationOf, file clang/include/clang/AST/DeclTemplate.h, line 1825. It was happening with ClassTemplateSpecializationDecl `enable_if_not_same<int, int>`. Because this template is specialized for equal types not to have a definition, it wasn't instantiated and its specialization kind remained TSK_Undeclared. And because it was implicit instantiation, we didn't mark the decl as invalid. So when we try to find the best matching partial specialization the second time, we hit the assertion as partial specialization is already set. Fix by reusing stored partial specialization when available, instead of looking for the best match every time. rdar://problem/39524996 Reviewers: rsmith, arphaman Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D46909 llvm-svn: 332509
2018-05-17 02:28:58 +08:00
Pattern = PartialSpec;
It looks like we've finished off matching of class template partial specializations; add comments and update the C++ status page llvm-svn: 73263
2009-06-13 06:31:52 +08:00
} else {
[Sema] Fix assertion when constructor is disabled with partially specialized template. The added test case was triggering assertion > Assertion failed: (!SpecializedTemplate.is<SpecializedPartialSpecialization*>() && "Already set to a class template partial specialization!"), function setInstantiationOf, file clang/include/clang/AST/DeclTemplate.h, line 1825. It was happening with ClassTemplateSpecializationDecl `enable_if_not_same<int, int>`. Because this template is specialized for equal types not to have a definition, it wasn't instantiated and its specialization kind remained TSK_Undeclared. And because it was implicit instantiation, we didn't mark the decl as invalid. So when we try to find the best matching partial specialization the second time, we hit the assertion as partial specialization is already set. Fix by reusing stored partial specialization when available, instead of looking for the best match every time. rdar://problem/39524996 Reviewers: rsmith, arphaman Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D46909 llvm-svn: 332509
2018-05-17 02:28:58 +08:00
ClassTemplateDecl *Template = ClassTemplateSpec->getSpecializedTemplate();
while (Template->getInstantiatedFromMemberTemplate()) {
When explicitly specializing a member that is a template, mark the template as a specialization. For example, this occurs with: template<typename T> struct X { template<typename U> struct Inner { /* ... */ }; }; template<> template<typename T> struct X<int>::Inner { T member; }; We need to treat templates that are member specializations as special in two contexts: - When looking for a definition of a member template, we look through the instantiation chain until we hit the primary template *or a member specialization*. This allows us to distinguish between the primary "Inner" definition and the X<int>::Inner definition, above. - When computing all of the levels of template arguments needed to instantiate a member template, don't add template arguments from contexts outside of the instantiation of a member specialization, since the user has already manually substituted those arguments. Fix up the existing test for p18, which was actually wrong (but we didn't diagnose it because of our poor handling of member specializations of templates), and add a new test for member specializations of templates. llvm-svn: 83974
2009-10-14 00:30:37 +08:00
// If we've found an explicit specialization of this class template,
// stop here and use that as the pattern.
[Sema] Fix assertion when constructor is disabled with partially specialized template. The added test case was triggering assertion > Assertion failed: (!SpecializedTemplate.is<SpecializedPartialSpecialization*>() && "Already set to a class template partial specialization!"), function setInstantiationOf, file clang/include/clang/AST/DeclTemplate.h, line 1825. It was happening with ClassTemplateSpecializationDecl `enable_if_not_same<int, int>`. Because this template is specialized for equal types not to have a definition, it wasn't instantiated and its specialization kind remained TSK_Undeclared. And because it was implicit instantiation, we didn't mark the decl as invalid. So when we try to find the best matching partial specialization the second time, we hit the assertion as partial specialization is already set. Fix by reusing stored partial specialization when available, instead of looking for the best match every time. rdar://problem/39524996 Reviewers: rsmith, arphaman Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D46909 llvm-svn: 332509
2018-05-17 02:28:58 +08:00
if (Template->isMemberSpecialization())
When explicitly specializing a member that is a template, mark the template as a specialization. For example, this occurs with: template<typename T> struct X { template<typename U> struct Inner { /* ... */ }; }; template<> template<typename T> struct X<int>::Inner { T member; }; We need to treat templates that are member specializations as special in two contexts: - When looking for a definition of a member template, we look through the instantiation chain until we hit the primary template *or a member specialization*. This allows us to distinguish between the primary "Inner" definition and the X<int>::Inner definition, above. - When computing all of the levels of template arguments needed to instantiate a member template, don't add template arguments from contexts outside of the instantiation of a member specialization, since the user has already manually substituted those arguments. Fix up the existing test for p18, which was actually wrong (but we didn't diagnose it because of our poor handling of member specializations of templates), and add a new test for member specializations of templates. llvm-svn: 83974
2009-10-14 00:30:37 +08:00
break;
[Sema] Fix assertion when constructor is disabled with partially specialized template. The added test case was triggering assertion > Assertion failed: (!SpecializedTemplate.is<SpecializedPartialSpecialization*>() && "Already set to a class template partial specialization!"), function setInstantiationOf, file clang/include/clang/AST/DeclTemplate.h, line 1825. It was happening with ClassTemplateSpecializationDecl `enable_if_not_same<int, int>`. Because this template is specialized for equal types not to have a definition, it wasn't instantiated and its specialization kind remained TSK_Undeclared. And because it was implicit instantiation, we didn't mark the decl as invalid. So when we try to find the best matching partial specialization the second time, we hit the assertion as partial specialization is already set. Fix by reusing stored partial specialization when available, instead of looking for the best match every time. rdar://problem/39524996 Reviewers: rsmith, arphaman Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D46909 llvm-svn: 332509
2018-05-17 02:28:58 +08:00
Template = Template->getInstantiatedFromMemberTemplate();
When explicitly specializing a member that is a template, mark the template as a specialization. For example, this occurs with: template<typename T> struct X { template<typename U> struct Inner { /* ... */ }; }; template<> template<typename T> struct X<int>::Inner { T member; }; We need to treat templates that are member specializations as special in two contexts: - When looking for a definition of a member template, we look through the instantiation chain until we hit the primary template *or a member specialization*. This allows us to distinguish between the primary "Inner" definition and the X<int>::Inner definition, above. - When computing all of the levels of template arguments needed to instantiate a member template, don't add template arguments from contexts outside of the instantiation of a member specialization, since the user has already manually substituted those arguments. Fix up the existing test for p18, which was actually wrong (but we didn't diagnose it because of our poor handling of member specializations of templates), and add a new test for member specializations of templates. llvm-svn: 83974
2009-10-14 00:30:37 +08:00
}
[Sema] Fix assertion when constructor is disabled with partially specialized template. The added test case was triggering assertion > Assertion failed: (!SpecializedTemplate.is<SpecializedPartialSpecialization*>() && "Already set to a class template partial specialization!"), function setInstantiationOf, file clang/include/clang/AST/DeclTemplate.h, line 1825. It was happening with ClassTemplateSpecializationDecl `enable_if_not_same<int, int>`. Because this template is specialized for equal types not to have a definition, it wasn't instantiated and its specialization kind remained TSK_Undeclared. And because it was implicit instantiation, we didn't mark the decl as invalid. So when we try to find the best matching partial specialization the second time, we hit the assertion as partial specialization is already set. Fix by reusing stored partial specialization when available, instead of looking for the best match every time. rdar://problem/39524996 Reviewers: rsmith, arphaman Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D46909 llvm-svn: 332509
2018-05-17 02:28:58 +08:00
Pattern = Template->getTemplatedDecl();
Initial infrastructure for class template partial specialization. Here we have the basics of declaring and storing class template partial specializations, matching class template partial specializations at instantiation time via (limited) template argument deduction, and using the class template partial specialization's pattern for instantiation. This patch is enough to make a simple is_pointer type trait work, but not much else. llvm-svn: 72662
2009-05-31 17:31:02 +08:00
}
Instantiation for member classes of class templates. Note that only the declarations of member classes are instantiated when the owning class template is instantiated. The definitions of such member classes are instantiated when a complete type is required. This change also introduces the injected-class-name into a class template specialization. llvm-svn: 67707
2009-03-26 05:17:03 +08:00
PR31514: Add recursive self-instantiation check during template argument deduction in partial ordering. This prevents us from crashing due to attempting to instantiate the same class template specialization definition multiple times. (Debug builds also appear to sometimes hit the stack limit before hitting the instantiation depth limit in this case.) llvm-svn: 291407
2017-01-09 06:45:21 +08:00
return Pattern;
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
PR31514: Add recursive self-instantiation check during template argument deduction in partial ordering. This prevents us from crashing due to attempting to instantiate the same class template specialization definition multiple times. (Debug builds also appear to sometimes hit the stack limit before hitting the instantiation depth limit in this case.) llvm-svn: 291407
2017-01-09 06:45:21 +08:00
bool Sema::InstantiateClassTemplateSpecialization(
SourceLocation PointOfInstantiation,
ClassTemplateSpecializationDecl *ClassTemplateSpec,
TemplateSpecializationKind TSK, bool Complain) {
// Perform the actual instantiation on the canonical declaration.
ClassTemplateSpec = cast<ClassTemplateSpecializationDecl>(
ClassTemplateSpec->getCanonicalDecl());
if (ClassTemplateSpec->isInvalidDecl())
return true;
Ensure that we don't leave behind "InstantiatingSpecialization" entries after destroying an InstantiatingTemplate object. This previously caused us to (silently!) bail out of class template instantiation, thinking we'd produced an error, in some corner cases.
2020-12-11 08:49:27 +08:00
ActionResult<CXXRecordDecl *> Pattern =
getPatternForClassTemplateSpecialization(*this, PointOfInstantiation,
ClassTemplateSpec, TSK);
if (!Pattern.isUsable())
return Pattern.isInvalid();
PR31514: Add recursive self-instantiation check during template argument deduction in partial ordering. This prevents us from crashing due to attempting to instantiate the same class template specialization definition multiple times. (Debug builds also appear to sometimes hit the stack limit before hitting the instantiation depth limit in this case.) llvm-svn: 291407
2017-01-09 06:45:21 +08:00
Ensure that we don't leave behind "InstantiatingSpecialization" entries after destroying an InstantiatingTemplate object. This previously caused us to (silently!) bail out of class template instantiation, thinking we'd produced an error, in some corner cases.
2020-12-11 08:49:27 +08:00
return InstantiateClass(
PointOfInstantiation, ClassTemplateSpec, Pattern.get(),
getTemplateInstantiationArgs(ClassTemplateSpec), TSK, Complain);
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
}
Remove \brief commands from doxygen comments. This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
2018-05-09 09:00:01 +08:00
/// Instantiates the definitions of all of the member
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
/// of the given class, which is an instantiation of a class template
/// or a member class of a template.
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
void
Sema::InstantiateClassMembers(SourceLocation PointOfInstantiation,
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
CXXRecordDecl *Instantiation,
const MultiLevelTemplateArgumentList &TemplateArgs,
TemplateSpecializationKind TSK) {
If we see an explicit instantiation declaration or definition of a function after we've already instantiated a definition for the function, pass it to the ASTConsumer again so that it knows the specialization kind has changed and can update the function's linkage. This only matters if we instantiate the definition of the function before we reach the end of the TU; this can happen in at least three different ways: C++11 constexpr functions, C++14 deduced return types, and functions instantiated within modules. llvm-svn: 207152
2014-04-25 06:45:46 +08:00
// FIXME: We need to notify the ASTMutationListener that we did all of these
// things, in case we have an explicit instantiation definition in a PCM, a
// module, or preamble, and the declaration is in an imported AST.
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
assert(
(TSK == TSK_ExplicitInstantiationDefinition ||
TSK == TSK_ExplicitInstantiationDeclaration ||
(TSK == TSK_ImplicitInstantiation && Instantiation->isLocalClass())) &&
"Unexpected template specialization kind!");
[C++11] Replacing DeclBase iterators decls_begin() and decls_end() with iterator_range decls(). The same is true for the noload versions of these APIs. Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203278
2014-03-08 03:56:05 +08:00
for (auto *D : Instantiation->decls()) {
An explicit instantiation definition only instantiations those class members that have a definition. Also, use CheckSpecializationInstantiationRedecl as part of this instantiation to make sure that we diagnose the various kinds of problems that can occur with explicit instantiations. llvm-svn: 85270
2009-10-28 02:42:08 +08:00
bool SuppressNew = false;
[C++11] Replacing DeclBase iterators decls_begin() and decls_end() with iterator_range decls(). The same is true for the noload versions of these APIs. Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203278
2014-03-08 03:56:05 +08:00
if (auto *Function = dyn_cast<FunctionDecl>(D)) {
[clang] Add the exclude_from_explicit_instantiation attribute Summary: This attribute allows excluding a member of a class template from being part of an explicit template instantiation of that class template. This also makes sure that code using such a member will not take for granted that an external instantiation exists in another translation unit. The attribute was discussed on cfe-dev at [1] and is primarily motivated by the removal of always_inline in libc++ to control what's part of the ABI (see links in [1]). [1]: http://lists.llvm.org/pipermail/cfe-dev/2018-August/059024.html rdar://problem/43428125 Reviewers: rsmith Subscribers: dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D51789 llvm-svn: 343790
2018-10-04 23:49:42 +08:00
if (FunctionDecl *Pattern =
Function->getInstantiatedFromMemberFunction()) {
Revert "Following up on PR48517, fix handling of template arguments that refer" Combined with 'da98651 - Revert "DR2064: decltype(E) is only a dependent', this change (5a391d3) caused verifier errors when building Chromium. See https://crbug.com/1168494#c1 for a reproducer. Additionally it reverts changes that were dependent on this one, see below. > Following up on PR48517, fix handling of template arguments that refer > to dependent declarations. > > Treat an id-expression that names a local variable in a templated > function as being instantiation-dependent. > > This addresses a language defect whereby a reference to a dependent > declaration can be formed without any construct being value-dependent. > Fixing that through value-dependence turns out to be problematic, so > instead this patch takes the approach (proposed on the core reflector) > of allowing the use of pointers or references to (but not values of) > dependent declarations inside value-dependent expressions, and instead > treating template arguments as dependent if they evaluate to a constant > involving such dependent declarations. > > This ends up affecting a bunch of OpenMP tests, due to OpenMP > imprecisely handling instantiation-dependent constructs, bailing out > early instead of processing dependent constructs to the extent possible > when handling the template. > > Previously committed as 8c1f2d15b826591cdf6bd6b468b8a7d23377b29e, and > reverted because a dependency commit was reverted. This reverts commit 5a391d38ac6c561ba908334d427f26124ed9132e. It also restores clang/test/SemaCXX/coroutines.cpp to its state before da986511fb9da1a46a0ca4dba2e49e2426036303. Revert "[c++20] P1907R1: Support for generalized non-type template arguments of scalar type." > Previously committed as 9e08e51a20d0d2b1c5724bb17e969d036fced4cd, and > reverted because a dependency commit was reverted. This incorporates the > following follow-on commits that were also reverted: > > 7e84aa1b81e72d44bcc58ffe1731bfc7abb73ce0 by Simon Pilgrim > ed13d8c66781b50ff007cb089c5905f9bb9e8af2 by me > 95c7b6cadbc9a3d4376ef44edbeb3c8bb5b8d7fc by Sam McCall > 430d5d8429473c2b10b109991d7577a3cea41140 by Dave Zarzycki This reverts commit 4b574008aef5a7235c1f894ab065fe300d26e786. Revert "[msabi] Mangle a template argument referring to array-to-pointer decay" > [msabi] Mangle a template argument referring to array-to-pointer decay > applied to an array the same as the array itself. > > This follows MS ABI, and corrects a regression from the implementation > of generalized non-type template parameters, where we "forgot" how to > mangle this case. This reverts commit 18e093faf726d15f210ab4917142beec51848258.
2021-01-20 22:25:33 +08:00
if (Function->hasAttr<ExcludeFromExplicitInstantiationAttr>())
[clang] Add the exclude_from_explicit_instantiation attribute Summary: This attribute allows excluding a member of a class template from being part of an explicit template instantiation of that class template. This also makes sure that code using such a member will not take for granted that an external instantiation exists in another translation unit. The attribute was discussed on cfe-dev at [1] and is primarily motivated by the removal of always_inline in libc++ to control what's part of the ABI (see links in [1]). [1]: http://lists.llvm.org/pipermail/cfe-dev/2018-August/059024.html rdar://problem/43428125 Reviewers: rsmith Subscribers: dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D51789 llvm-svn: 343790
2018-10-04 23:49:42 +08:00
continue;
MemberSpecializationInfo *MSInfo =
Function->getMemberSpecializationInfo();
An explicit instantiation definition only instantiations those class members that have a definition. Also, use CheckSpecializationInstantiationRedecl as part of this instantiation to make sure that we diagnose the various kinds of problems that can occur with explicit instantiations. llvm-svn: 85270
2009-10-28 02:42:08 +08:00
assert(MSInfo && "No member specialization information?");
Only complain about explicit instantiations following explicit specializations when the explicit instantiation was... explicitly written, i.e., not the product of an explicit instantiation of an enclosing class. Fixes this spurious warning when Clang builds LLVM: /Volumes/Data/dgregor/Projects/llvm/lib/CodeGen/MachineDominators.cpp:22:1: warning: explicit instantiation of 'addRoot' that occurs after an explicit specialization will be ignored (C++0x extension) [-pedantic] llvm-svn: 100900
2010-04-10 05:02:29 +08:00
if (MSInfo->getTemplateSpecializationKind()
== TSK_ExplicitSpecialization)
continue;
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
if (CheckSpecializationInstantiationRedecl(PointOfInstantiation, TSK,
Function,
An explicit instantiation definition only instantiations those class members that have a definition. Also, use CheckSpecializationInstantiationRedecl as part of this instantiation to make sure that we diagnose the various kinds of problems that can occur with explicit instantiations. llvm-svn: 85270
2009-10-28 02:42:08 +08:00
MSInfo->getTemplateSpecializationKind(),
Correctly set "explicit template instantiation" kind on inner structs of templates whose explicit instantiation is first declared and then defined. Fixes http://llvm.org/pr8207 llvm-svn: 114874
2010-09-28 05:02:09 +08:00
MSInfo->getPointOfInstantiation(),
An explicit instantiation definition only instantiations those class members that have a definition. Also, use CheckSpecializationInstantiationRedecl as part of this instantiation to make sure that we diagnose the various kinds of problems that can occur with explicit instantiations. llvm-svn: 85270
2009-10-28 02:42:08 +08:00
SuppressNew) ||
SuppressNew)
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
continue;
If we see an explicit instantiation declaration or definition of a function after we've already instantiated a definition for the function, pass it to the ASTConsumer again so that it knows the specialization kind has changed and can update the function's linkage. This only matters if we instantiate the definition of the function before we reach the end of the TU; this can happen in at least three different ways: C++11 constexpr functions, C++14 deduced return types, and functions instantiated within modules. llvm-svn: 207152
2014-04-25 06:45:46 +08:00
// C++11 [temp.explicit]p8:
// An explicit instantiation definition that names a class template
// specialization explicitly instantiates the class template
// specialization and is only an explicit instantiation definition
// of members whose definition is visible at the point of
// instantiation.
if (TSK == TSK_ExplicitInstantiationDefinition && !Pattern->isDefined())
An explicit instantiation definition only instantiations those class members that have a definition. Also, use CheckSpecializationInstantiationRedecl as part of this instantiation to make sure that we diagnose the various kinds of problems that can occur with explicit instantiations. llvm-svn: 85270
2009-10-28 02:42:08 +08:00
continue;
If we see an explicit instantiation declaration or definition of a function after we've already instantiated a definition for the function, pass it to the ASTConsumer again so that it knows the specialization kind has changed and can update the function's linkage. This only matters if we instantiate the definition of the function before we reach the end of the TU; this can happen in at least three different ways: C++11 constexpr functions, C++14 deduced return types, and functions instantiated within modules. llvm-svn: 207152
2014-04-25 06:45:46 +08:00
Function->setTemplateSpecializationKind(TSK, PointOfInstantiation);
if (Function->isDefined()) {
// Let the ASTConsumer know that this function has been explicitly
// instantiated now, and its linkage might have changed.
Consumer.HandleTopLevelDecl(DeclGroupRef(Function));
} else if (TSK == TSK_ExplicitInstantiationDefinition) {
An explicit instantiation definition only instantiations those class members that have a definition. Also, use CheckSpecializationInstantiationRedecl as part of this instantiation to make sure that we diagnose the various kinds of problems that can occur with explicit instantiations. llvm-svn: 85270
2009-10-28 02:42:08 +08:00
InstantiateFunctionDefinition(PointOfInstantiation, Function);
If we see an explicit instantiation declaration or definition of a function after we've already instantiated a definition for the function, pass it to the ASTConsumer again so that it knows the specialization kind has changed and can update the function's linkage. This only matters if we instantiate the definition of the function before we reach the end of the TU; this can happen in at least three different ways: C++11 constexpr functions, C++14 deduced return types, and functions instantiated within modules. llvm-svn: 207152
2014-04-25 06:45:46 +08:00
} else if (TSK == TSK_ImplicitInstantiation) {
PendingLocalImplicitInstantiations.push_back(
std::make_pair(Function, PointOfInstantiation));
An explicit instantiation definition only instantiations those class members that have a definition. Also, use CheckSpecializationInstantiationRedecl as part of this instantiation to make sure that we diagnose the various kinds of problems that can occur with explicit instantiations. llvm-svn: 85270
2009-10-28 02:42:08 +08:00
}
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
}
[C++11] Replacing DeclBase iterators decls_begin() and decls_end() with iterator_range decls(). The same is true for the noload versions of these APIs. Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203278
2014-03-08 03:56:05 +08:00
} else if (auto *Var = dyn_cast<VarDecl>(D)) {
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 (isa<VarTemplateSpecializationDecl>(Var))
continue;
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
if (Var->isStaticDataMember()) {
Revert "Following up on PR48517, fix handling of template arguments that refer" Combined with 'da98651 - Revert "DR2064: decltype(E) is only a dependent', this change (5a391d3) caused verifier errors when building Chromium. See https://crbug.com/1168494#c1 for a reproducer. Additionally it reverts changes that were dependent on this one, see below. > Following up on PR48517, fix handling of template arguments that refer > to dependent declarations. > > Treat an id-expression that names a local variable in a templated > function as being instantiation-dependent. > > This addresses a language defect whereby a reference to a dependent > declaration can be formed without any construct being value-dependent. > Fixing that through value-dependence turns out to be problematic, so > instead this patch takes the approach (proposed on the core reflector) > of allowing the use of pointers or references to (but not values of) > dependent declarations inside value-dependent expressions, and instead > treating template arguments as dependent if they evaluate to a constant > involving such dependent declarations. > > This ends up affecting a bunch of OpenMP tests, due to OpenMP > imprecisely handling instantiation-dependent constructs, bailing out > early instead of processing dependent constructs to the extent possible > when handling the template. > > Previously committed as 8c1f2d15b826591cdf6bd6b468b8a7d23377b29e, and > reverted because a dependency commit was reverted. This reverts commit 5a391d38ac6c561ba908334d427f26124ed9132e. It also restores clang/test/SemaCXX/coroutines.cpp to its state before da986511fb9da1a46a0ca4dba2e49e2426036303. Revert "[c++20] P1907R1: Support for generalized non-type template arguments of scalar type." > Previously committed as 9e08e51a20d0d2b1c5724bb17e969d036fced4cd, and > reverted because a dependency commit was reverted. This incorporates the > following follow-on commits that were also reverted: > > 7e84aa1b81e72d44bcc58ffe1731bfc7abb73ce0 by Simon Pilgrim > ed13d8c66781b50ff007cb089c5905f9bb9e8af2 by me > 95c7b6cadbc9a3d4376ef44edbeb3c8bb5b8d7fc by Sam McCall > 430d5d8429473c2b10b109991d7577a3cea41140 by Dave Zarzycki This reverts commit 4b574008aef5a7235c1f894ab065fe300d26e786. Revert "[msabi] Mangle a template argument referring to array-to-pointer decay" > [msabi] Mangle a template argument referring to array-to-pointer decay > applied to an array the same as the array itself. > > This follows MS ABI, and corrects a regression from the implementation > of generalized non-type template parameters, where we "forgot" how to > mangle this case. This reverts commit 18e093faf726d15f210ab4917142beec51848258.
2021-01-20 22:25:33 +08:00
if (Var->hasAttr<ExcludeFromExplicitInstantiationAttr>())
[clang] Add the exclude_from_explicit_instantiation attribute Summary: This attribute allows excluding a member of a class template from being part of an explicit template instantiation of that class template. This also makes sure that code using such a member will not take for granted that an external instantiation exists in another translation unit. The attribute was discussed on cfe-dev at [1] and is primarily motivated by the removal of always_inline in libc++ to control what's part of the ABI (see links in [1]). [1]: http://lists.llvm.org/pipermail/cfe-dev/2018-August/059024.html rdar://problem/43428125 Reviewers: rsmith Subscribers: dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D51789 llvm-svn: 343790
2018-10-04 23:49:42 +08:00
continue;
An explicit instantiation definition only instantiations those class members that have a definition. Also, use CheckSpecializationInstantiationRedecl as part of this instantiation to make sure that we diagnose the various kinds of problems that can occur with explicit instantiations. llvm-svn: 85270
2009-10-28 02:42:08 +08:00
MemberSpecializationInfo *MSInfo = Var->getMemberSpecializationInfo();
assert(MSInfo && "No member specialization information?");
Only complain about explicit instantiations following explicit specializations when the explicit instantiation was... explicitly written, i.e., not the product of an explicit instantiation of an enclosing class. Fixes this spurious warning when Clang builds LLVM: /Volumes/Data/dgregor/Projects/llvm/lib/CodeGen/MachineDominators.cpp:22:1: warning: explicit instantiation of 'addRoot' that occurs after an explicit specialization will be ignored (C++0x extension) [-pedantic] llvm-svn: 100900
2010-04-10 05:02:29 +08:00
if (MSInfo->getTemplateSpecializationKind()
== TSK_ExplicitSpecialization)
continue;
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
if (CheckSpecializationInstantiationRedecl(PointOfInstantiation, TSK,
Var,
An explicit instantiation definition only instantiations those class members that have a definition. Also, use CheckSpecializationInstantiationRedecl as part of this instantiation to make sure that we diagnose the various kinds of problems that can occur with explicit instantiations. llvm-svn: 85270
2009-10-28 02:42:08 +08:00
MSInfo->getTemplateSpecializationKind(),
Correctly set "explicit template instantiation" kind on inner structs of templates whose explicit instantiation is first declared and then defined. Fixes http://llvm.org/pr8207 llvm-svn: 114874
2010-09-28 05:02:09 +08:00
MSInfo->getPointOfInstantiation(),
An explicit instantiation definition only instantiations those class members that have a definition. Also, use CheckSpecializationInstantiationRedecl as part of this instantiation to make sure that we diagnose the various kinds of problems that can occur with explicit instantiations. llvm-svn: 85270
2009-10-28 02:42:08 +08:00
SuppressNew) ||
SuppressNew)
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
continue;
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
Revert "Following up on PR48517, fix handling of template arguments that refer" Combined with 'da98651 - Revert "DR2064: decltype(E) is only a dependent', this change (5a391d3) caused verifier errors when building Chromium. See https://crbug.com/1168494#c1 for a reproducer. Additionally it reverts changes that were dependent on this one, see below. > Following up on PR48517, fix handling of template arguments that refer > to dependent declarations. > > Treat an id-expression that names a local variable in a templated > function as being instantiation-dependent. > > This addresses a language defect whereby a reference to a dependent > declaration can be formed without any construct being value-dependent. > Fixing that through value-dependence turns out to be problematic, so > instead this patch takes the approach (proposed on the core reflector) > of allowing the use of pointers or references to (but not values of) > dependent declarations inside value-dependent expressions, and instead > treating template arguments as dependent if they evaluate to a constant > involving such dependent declarations. > > This ends up affecting a bunch of OpenMP tests, due to OpenMP > imprecisely handling instantiation-dependent constructs, bailing out > early instead of processing dependent constructs to the extent possible > when handling the template. > > Previously committed as 8c1f2d15b826591cdf6bd6b468b8a7d23377b29e, and > reverted because a dependency commit was reverted. This reverts commit 5a391d38ac6c561ba908334d427f26124ed9132e. It also restores clang/test/SemaCXX/coroutines.cpp to its state before da986511fb9da1a46a0ca4dba2e49e2426036303. Revert "[c++20] P1907R1: Support for generalized non-type template arguments of scalar type." > Previously committed as 9e08e51a20d0d2b1c5724bb17e969d036fced4cd, and > reverted because a dependency commit was reverted. This incorporates the > following follow-on commits that were also reverted: > > 7e84aa1b81e72d44bcc58ffe1731bfc7abb73ce0 by Simon Pilgrim > ed13d8c66781b50ff007cb089c5905f9bb9e8af2 by me > 95c7b6cadbc9a3d4376ef44edbeb3c8bb5b8d7fc by Sam McCall > 430d5d8429473c2b10b109991d7577a3cea41140 by Dave Zarzycki This reverts commit 4b574008aef5a7235c1f894ab065fe300d26e786. Revert "[msabi] Mangle a template argument referring to array-to-pointer decay" > [msabi] Mangle a template argument referring to array-to-pointer decay > applied to an array the same as the array itself. > > This follows MS ABI, and corrects a regression from the implementation > of generalized non-type template parameters, where we "forgot" how to > mangle this case. This reverts commit 18e093faf726d15f210ab4917142beec51848258.
2021-01-20 22:25:33 +08:00
if (TSK == TSK_ExplicitInstantiationDefinition) {
An explicit instantiation definition only instantiations those class members that have a definition. Also, use CheckSpecializationInstantiationRedecl as part of this instantiation to make sure that we diagnose the various kinds of problems that can occur with explicit instantiations. llvm-svn: 85270
2009-10-28 02:42:08 +08:00
// C++0x [temp.explicit]p8:
// An explicit instantiation definition that names a class template
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
// specialization explicitly instantiates the class template
// specialization and is only an explicit instantiation definition
// of members whose definition is visible at the point of
An explicit instantiation definition only instantiations those class members that have a definition. Also, use CheckSpecializationInstantiationRedecl as part of this instantiation to make sure that we diagnose the various kinds of problems that can occur with explicit instantiations. llvm-svn: 85270
2009-10-28 02:42:08 +08:00
// instantiation.
Implement C++17 P0386R2, inline variables. (The 'inline' specifier gives a variable weak discardable linkage and partially-ordered initialization, and is implied for constexpr static data members.) llvm-svn: 273754
2016-06-25 08:15:56 +08:00
if (!Var->getInstantiatedFromStaticDataMember()->getDefinition())
An explicit instantiation definition only instantiations those class members that have a definition. Also, use CheckSpecializationInstantiationRedecl as part of this instantiation to make sure that we diagnose the various kinds of problems that can occur with explicit instantiations. llvm-svn: 85270
2009-10-28 02:42:08 +08:00
continue;
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
An explicit instantiation definition only instantiations those class members that have a definition. Also, use CheckSpecializationInstantiationRedecl as part of this instantiation to make sure that we diagnose the various kinds of problems that can occur with explicit instantiations. llvm-svn: 85270
2009-10-28 02:42:08 +08:00
Var->setTemplateSpecializationKind(TSK, PointOfInstantiation);
Generalize "static data member instantiated" notification to cover variable templates too. While here, split the "point of instantiation changed" notification out from it; these two really are orthogonal changes. llvm-svn: 319727
2017-12-05 09:31:47 +08:00
InstantiateVariableDefinition(PointOfInstantiation, Var);
An explicit instantiation definition only instantiations those class members that have a definition. Also, use CheckSpecializationInstantiationRedecl as part of this instantiation to make sure that we diagnose the various kinds of problems that can occur with explicit instantiations. llvm-svn: 85270
2009-10-28 02:42:08 +08:00
} else {
Var->setTemplateSpecializationKind(TSK, PointOfInstantiation);
}
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
}
[C++11] Replacing DeclBase iterators decls_begin() and decls_end() with iterator_range decls(). The same is true for the noload versions of these APIs. Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203278
2014-03-08 03:56:05 +08:00
} else if (auto *Record = dyn_cast<CXXRecordDecl>(D)) {
[clang] Add the exclude_from_explicit_instantiation attribute Summary: This attribute allows excluding a member of a class template from being part of an explicit template instantiation of that class template. This also makes sure that code using such a member will not take for granted that an external instantiation exists in another translation unit. The attribute was discussed on cfe-dev at [1] and is primarily motivated by the removal of always_inline in libc++ to control what's part of the ABI (see links in [1]). [1]: http://lists.llvm.org/pipermail/cfe-dev/2018-August/059024.html rdar://problem/43428125 Reviewers: rsmith Subscribers: dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D51789 llvm-svn: 343790
2018-10-04 23:49:42 +08:00
if (Record->hasAttr<ExcludeFromExplicitInstantiationAttr>())
continue;
Make sure that we don't visit redeclarations of nested classes while instantiating class members as part of an explicit instantiation. Addresses a compilation problem in Boost.Serialization. llvm-svn: 101725
2010-04-19 02:11:38 +08:00
// Always skip the injected-class-name, along with any
// redeclarations of nested classes, since both would cause us
// to try to instantiate the members of a class twice.
Fix crash-on-valid if a lambda-expression appears lexically directly within a local class inside a template. llvm-svn: 222476
2014-11-21 06:56:34 +08:00
// Skip closure types; they'll get instantiated when we instantiate
// the corresponding lambda-expression.
if (Record->isInjectedClassName() || Record->getPreviousDecl() ||
Record->isLambda())
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
continue;
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
An explicit instantiation definition only instantiations those class members that have a definition. Also, use CheckSpecializationInstantiationRedecl as part of this instantiation to make sure that we diagnose the various kinds of problems that can occur with explicit instantiations. llvm-svn: 85270
2009-10-28 02:42:08 +08:00
MemberSpecializationInfo *MSInfo = Record->getMemberSpecializationInfo();
assert(MSInfo && "No member specialization information?");
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
Only complain about explicit instantiations following explicit specializations when the explicit instantiation was... explicitly written, i.e., not the product of an explicit instantiation of an enclosing class. Fixes this spurious warning when Clang builds LLVM: /Volumes/Data/dgregor/Projects/llvm/lib/CodeGen/MachineDominators.cpp:22:1: warning: explicit instantiation of 'addRoot' that occurs after an explicit specialization will be ignored (C++0x extension) [-pedantic] llvm-svn: 100900
2010-04-10 05:02:29 +08:00
if (MSInfo->getTemplateSpecializationKind()
== TSK_ExplicitSpecialization)
continue;
Correctly set "explicit template instantiation" kind on inner structs of templates whose explicit instantiation is first declared and then defined. Fixes http://llvm.org/pr8207 llvm-svn: 114874
2010-09-28 05:02:09 +08:00
Simplify exclusion of nested classes from extern template instantiation, NFC Summary: This simplifies three checks for MS ABI, Win Itanium, or Win GNU to just "is Windows". The question remains, however, if this is really the correct thing to do. We could, for example, only not consider inner classes to be externally available if the outer class has a dllexport annotation. However, I will leave that as future work. Reviewers: hans, mstorsjo Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D61278 llvm-svn: 359507
2019-04-30 05:32:05 +08:00
if (Context.getTargetInfo().getTriple().isOSWindows() &&
Re-commit r270748 "clang-cl: Treat dllimport explicit template instantiation definitions as declarations (PR27810, PR27811)" Also make explicit instantiation decls not apply to nested classes when targeting MSVC. That dll attributes are not inherited by inner classes might be the explanation for MSVC's behaviour here. llvm-svn: 270897
2016-05-27 03:42:56 +08:00
TSK == TSK_ExplicitInstantiationDeclaration) {
Simplify exclusion of nested classes from extern template instantiation, NFC Summary: This simplifies three checks for MS ABI, Win Itanium, or Win GNU to just "is Windows". The question remains, however, if this is really the correct thing to do. We could, for example, only not consider inner classes to be externally available if the outer class has a dllexport annotation. However, I will leave that as future work. Reviewers: hans, mstorsjo Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D61278 llvm-svn: 359507
2019-04-30 05:32:05 +08:00
// On Windows, explicit instantiation decl of the outer class doesn't
// affect the inner class. Typically extern template declarations are
// used in combination with dll import/export annotations, but those
// are not propagated from the outer class templates to inner classes.
// Therefore, do not instantiate inner classes on this platform, so
// that users don't end up with undefined symbols during linking.
Re-commit r270748 "clang-cl: Treat dllimport explicit template instantiation definitions as declarations (PR27810, PR27811)" Also make explicit instantiation decls not apply to nested classes when targeting MSVC. That dll attributes are not inherited by inner classes might be the explanation for MSVC's behaviour here. llvm-svn: 270897
2016-05-27 03:42:56 +08:00
continue;
}
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
if (CheckSpecializationInstantiationRedecl(PointOfInstantiation, TSK,
Record,
An explicit instantiation definition only instantiations those class members that have a definition. Also, use CheckSpecializationInstantiationRedecl as part of this instantiation to make sure that we diagnose the various kinds of problems that can occur with explicit instantiations. llvm-svn: 85270
2009-10-28 02:42:08 +08:00
MSInfo->getTemplateSpecializationKind(),
Correctly set "explicit template instantiation" kind on inner structs of templates whose explicit instantiation is first declared and then defined. Fixes http://llvm.org/pr8207 llvm-svn: 114874
2010-09-28 05:02:09 +08:00
MSInfo->getPointOfInstantiation(),
An explicit instantiation definition only instantiations those class members that have a definition. Also, use CheckSpecializationInstantiationRedecl as part of this instantiation to make sure that we diagnose the various kinds of problems that can occur with explicit instantiations. llvm-svn: 85270
2009-10-28 02:42:08 +08:00
SuppressNew) ||
SuppressNew)
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
continue;
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
An explicit instantiation definition only instantiations those class members that have a definition. Also, use CheckSpecializationInstantiationRedecl as part of this instantiation to make sure that we diagnose the various kinds of problems that can occur with explicit instantiations. llvm-svn: 85270
2009-10-28 02:42:08 +08:00
CXXRecordDecl *Pattern = Record->getInstantiatedFromMemberClass();
assert(Pattern && "Missing instantiated-from-template information");
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
Eliminate the ASTContext parameter from RecordDecl::getDefinition() and CXXRecordDecl::getDefinition(); it's totally unnecessary. No functionality change. llvm-svn: 95836
2010-02-11 09:04:33 +08:00
if (!Record->getDefinition()) {
if (!Pattern->getDefinition()) {
An explicit instantiation definition only instantiations those class members that have a definition. Also, use CheckSpecializationInstantiationRedecl as part of this instantiation to make sure that we diagnose the various kinds of problems that can occur with explicit instantiations. llvm-svn: 85270
2009-10-28 02:42:08 +08:00
// C++0x [temp.explicit]p8:
// An explicit instantiation definition that names a class template
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
// specialization explicitly instantiates the class template
// specialization and is only an explicit instantiation definition
// of members whose definition is visible at the point of
An explicit instantiation definition only instantiations those class members that have a definition. Also, use CheckSpecializationInstantiationRedecl as part of this instantiation to make sure that we diagnose the various kinds of problems that can occur with explicit instantiations. llvm-svn: 85270
2009-10-28 02:42:08 +08:00
// instantiation.
if (TSK == TSK_ExplicitInstantiationDeclaration) {
MSInfo->setTemplateSpecializationKind(TSK);
MSInfo->setPointOfInstantiation(PointOfInstantiation);
}
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
An explicit instantiation definition only instantiations those class members that have a definition. Also, use CheckSpecializationInstantiationRedecl as part of this instantiation to make sure that we diagnose the various kinds of problems that can occur with explicit instantiations. llvm-svn: 85270
2009-10-28 02:42:08 +08:00
continue;
}
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
An explicit instantiation definition only instantiations those class members that have a definition. Also, use CheckSpecializationInstantiationRedecl as part of this instantiation to make sure that we diagnose the various kinds of problems that can occur with explicit instantiations. llvm-svn: 85270
2009-10-28 02:42:08 +08:00
InstantiateClass(PointOfInstantiation, Record, Pattern,
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
TemplateArgs,
TSK);
Correctly set "explicit template instantiation" kind on inner structs of templates whose explicit instantiation is first declared and then defined. Fixes http://llvm.org/pr8207 llvm-svn: 114874
2010-09-28 05:02:09 +08:00
} else {
if (TSK == TSK_ExplicitInstantiationDefinition &&
Record->getTemplateSpecializationKind() ==
TSK_ExplicitInstantiationDeclaration) {
Record->setTemplateSpecializationKind(TSK);
MarkVTableUsed(PointOfInstantiation, Record, true);
}
An explicit instantiation definition only instantiations those class members that have a definition. Also, use CheckSpecializationInstantiationRedecl as part of this instantiation to make sure that we diagnose the various kinds of problems that can occur with explicit instantiations. llvm-svn: 85270
2009-10-28 02:42:08 +08:00
}
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
Eliminate the ASTContext parameter from RecordDecl::getDefinition() and CXXRecordDecl::getDefinition(); it's totally unnecessary. No functionality change. llvm-svn: 95836
2010-02-11 09:04:33 +08:00
Pattern = cast_or_null<CXXRecordDecl>(Record->getDefinition());
An explicit instantiation definition only instantiations those class members that have a definition. Also, use CheckSpecializationInstantiationRedecl as part of this instantiation to make sure that we diagnose the various kinds of problems that can occur with explicit instantiations. llvm-svn: 85270
2009-10-28 02:42:08 +08:00
if (Pattern)
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
InstantiateClassMembers(PointOfInstantiation, Pattern, TemplateArgs,
An explicit instantiation definition only instantiations those class members that have a definition. Also, use CheckSpecializationInstantiationRedecl as part of this instantiation to make sure that we diagnose the various kinds of problems that can occur with explicit instantiations. llvm-svn: 85270
2009-10-28 02:42:08 +08:00
TSK);
[C++11] Replacing DeclBase iterators decls_begin() and decls_end() with iterator_range decls(). The same is true for the noload versions of these APIs. Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203278
2014-03-08 03:56:05 +08:00
} else if (auto *Enum = dyn_cast<EnumDecl>(D)) {
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
MemberSpecializationInfo *MSInfo = Enum->getMemberSpecializationInfo();
assert(MSInfo && "No member specialization information?");
if (MSInfo->getTemplateSpecializationKind()
== TSK_ExplicitSpecialization)
continue;
if (CheckSpecializationInstantiationRedecl(
PointOfInstantiation, TSK, Enum,
MSInfo->getTemplateSpecializationKind(),
MSInfo->getPointOfInstantiation(), SuppressNew) ||
SuppressNew)
continue;
if (Enum->getDefinition())
continue;
[modules] Enforce the rules that an explicit or partial specialization must be declared before it is used. Because we don't use normal name lookup to find these, the normal code to filter out non-visible names from name lookup results does not apply. llvm-svn: 268585
2016-05-05 08:56:12 +08:00
EnumDecl *Pattern = Enum->getTemplateInstantiationPattern();
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
assert(Pattern && "Missing instantiated-from-template information");
if (TSK == TSK_ExplicitInstantiationDefinition) {
if (!Pattern->getDefinition())
continue;
InstantiateEnum(PointOfInstantiation, Enum, Pattern, TemplateArgs, TSK);
} else {
MSInfo->setTemplateSpecializationKind(TSK);
MSInfo->setPointOfInstantiation(PointOfInstantiation);
}
Handle use of default member initializers before end of outermost class Specifically, when we have this situation: struct A { template <typename T> struct B { int m1 = sizeof(A); }; B<int> m2; }; We can't parse m1's initializer eagerly because we need A to be complete. Therefore we wait until the end of A's class scope to parse it. However, we can trigger instantiation of B before the end of A, which will attempt to instantiate the field decls eagerly, and it would build a bad field decl instantiation that said it had an initializer but actually lacked one. Fixed by deferring instantiation of default member initializers until they are needed during constructor analysis. This addresses a long standing FIXME in the code. Fixes PR19195. Reviewed By: rsmith Differential Revision: http://reviews.llvm.org/D5690 llvm-svn: 222192
2014-11-18 07:36:45 +08:00
} else if (auto *Field = dyn_cast<FieldDecl>(D)) {
// No need to instantiate in-class initializers during explicit
// instantiation.
if (Field->hasInClassInitializer() && TSK == TSK_ImplicitInstantiation) {
CXXRecordDecl *ClassPattern =
Instantiation->getTemplateInstantiationPattern();
DeclContext::lookup_result Lookup =
ClassPattern->lookup(Field->getDeclName());
Make iteration over the DeclContext::lookup_result safe. The idiom: ``` DeclContext::lookup_result R = DeclContext::lookup(Name); for (auto *D : R) {...} ``` is not safe when in the loop body we trigger deserialization from an AST file. The deserialization can insert new declarations in the StoredDeclsList whose underlying type is a vector. When the vector decides to reallocate its storage the pointer we hold becomes invalid. This patch replaces a SmallVector with an singly-linked list. The current approach stores a SmallVector<NamedDecl*, 4> which is around 8 pointers. The linked list is 3, 5, or 7. We do better in terms of memory usage for small cases (and worse in terms of locality -- the linked list entries won't be near each other, but will be near their corresponding declarations, and we were going to fetch those memory pages anyway). For larger cases: the vector uses a doubling strategy for reallocation, so will generally be between half-full and full. Let's say it's 75% full on average, so there's N * 4/3 + 4 pointers' worth of space allocated currently and will be 2N pointers with the linked list. So we break even when there are N=6 entries and slightly lose in terms of memory usage after that. We suspect that's still a win on average. Thanks to @rsmith! Differential revision: https://reviews.llvm.org/D91524
2021-03-17 16:56:05 +08:00
FieldDecl *Pattern = Lookup.find_first<FieldDecl>();
assert(Pattern);
Handle use of default member initializers before end of outermost class Specifically, when we have this situation: struct A { template <typename T> struct B { int m1 = sizeof(A); }; B<int> m2; }; We can't parse m1's initializer eagerly because we need A to be complete. Therefore we wait until the end of A's class scope to parse it. However, we can trigger instantiation of B before the end of A, which will attempt to instantiate the field decls eagerly, and it would build a bad field decl instantiation that said it had an initializer but actually lacked one. Fixed by deferring instantiation of default member initializers until they are needed during constructor analysis. This addresses a long standing FIXME in the code. Fixes PR19195. Reviewed By: rsmith Differential Revision: http://reviews.llvm.org/D5690 llvm-svn: 222192
2014-11-18 07:36:45 +08:00
InstantiateInClassInitializer(PointOfInstantiation, Field, Pattern,
TemplateArgs);
}
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
}
}
}
Remove \brief commands from doxygen comments. This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
2018-05-09 09:00:01 +08:00
/// Instantiate the definitions of all of the members of the
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
/// given class template specialization, which was named as part of an
/// explicit instantiation.
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
void
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
Sema::InstantiateClassTemplateSpecializationMembers(
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
SourceLocation PointOfInstantiation,
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
ClassTemplateSpecializationDecl *ClassTemplateSpec,
TemplateSpecializationKind TSK) {
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
// C++0x [temp.explicit]p7:
// An explicit instantiation that names a class template
// specialization is an explicit instantion of the same kind
// (declaration or definition) of each of its members (not
// including members inherited from base classes) that has not
// been previously explicitly specialized in the translation unit
// containing the explicit instantiation, except as described
// below.
InstantiateClassMembers(PointOfInstantiation, ClassTemplateSpec,
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
getTemplateInstantiationArgs(ClassTemplateSpec),
TSK);
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
}
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
StmtResult
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
Sema::SubstStmt(Stmt *S, const MultiLevelTemplateArgumentList &TemplateArgs) {
Refactor the instantiation of statements into a generic tree transformation. llvm-svn: 79519
2009-08-20 15:17:43 +08:00
if (!S)
Refactoring. Remove Owned method from Sema. llvm-svn: 209812
2014-05-29 22:05:12 +08:00
return S;
Refactor the instantiation of statements into a generic tree transformation. llvm-svn: 79519
2009-08-20 15:17:43 +08:00
TemplateInstantiator Instantiator(*this, TemplateArgs,
SourceLocation(),
DeclarationName());
return Instantiator.TransformStmt(S);
}
[Concepts] Constrained partial specializations and function overloads. Added support for constraint satisfaction checking and partial ordering of constraints in constrained partial specialization and function template overloads. Re-commit after fixing another crash (added regression test). Differential Revision: https://reviews.llvm.org/D41910
2019-12-23 14:37:35 +08:00
bool Sema::SubstTemplateArguments(
ArrayRef<TemplateArgumentLoc> Args,
const MultiLevelTemplateArgumentList &TemplateArgs,
TemplateArgumentListInfo &Out) {
TemplateInstantiator Instantiator(*this, TemplateArgs,
SourceLocation(),
DeclarationName());
return Instantiator.TransformTemplateArguments(Args.begin(), Args.end(),
Out);
}
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
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
Sema::SubstExpr(Expr *E, const MultiLevelTemplateArgumentList &TemplateArgs) {
Refactor the template-instantiation logic for expressions into a generic tree transformation (also used for recanonicalization) and a small amount of template-instantiation-specific logic. llvm-svn: 78645
2009-08-11 13:31:07 +08:00
if (!E)
Refactoring. Remove Owned method from Sema. llvm-svn: 209812
2014-05-29 22:05:12 +08:00
return E;
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Refactor the template-instantiation logic for expressions into a generic tree transformation (also used for recanonicalization) and a small amount of template-instantiation-specific logic. llvm-svn: 78645
2009-08-11 13:31:07 +08:00
TemplateInstantiator Instantiator(*this, TemplateArgs,
SourceLocation(),
DeclarationName());
return Instantiator.TransformExpr(E);
}
PR13470: Ensure that copy-list-initialization isntantiates as copy-list-initialization (and doesn't add an additional copy step): Fill in the ListInitialization bit when creating a CXXConstructExpr. Use it when instantiating initializers in order to correctly handle instantiation of copy-list-initialization. Teach TreeTransform that function arguments are initializations, and so need this special treatment too. Finally, remove some hacks which were working around SubstInitializer's shortcomings. llvm-svn: 170489
2012-12-19 09:39:02 +08:00
ExprResult Sema::SubstInitializer(Expr *Init,
const MultiLevelTemplateArgumentList &TemplateArgs,
bool CXXDirectInit) {
TemplateInstantiator Instantiator(*this, TemplateArgs,
SourceLocation(),
DeclarationName());
return Instantiator.TransformInitializer(Init, CXXDirectInit);
}
[Sema] ArrayRef-ize SubstExprs. NFC llvm-svn: 256401
2015-12-25 07:58:29 +08:00
bool Sema::SubstExprs(ArrayRef<Expr *> Exprs, bool IsCall,
When instantiating the arguments to an initializer, use the TreeTransform version of TransformExprs() rather than explicit loop, so that we expand pack expansions properly. Test cast coming soon... llvm-svn: 123014
2011-01-08 03:35:17 +08:00
const MultiLevelTemplateArgumentList &TemplateArgs,
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<Expr *> &Outputs) {
[Sema] ArrayRef-ize SubstExprs. NFC llvm-svn: 256401
2015-12-25 07:58:29 +08:00
if (Exprs.empty())
When instantiating the arguments to an initializer, use the TreeTransform version of TransformExprs() rather than explicit loop, so that we expand pack expansions properly. Test cast coming soon... llvm-svn: 123014
2011-01-08 03:35:17 +08:00
return false;
PR13470: Ensure that copy-list-initialization isntantiates as copy-list-initialization (and doesn't add an additional copy step): Fill in the ListInitialization bit when creating a CXXConstructExpr. Use it when instantiating initializers in order to correctly handle instantiation of copy-list-initialization. Teach TreeTransform that function arguments are initializations, and so need this special treatment too. Finally, remove some hacks which were working around SubstInitializer's shortcomings. llvm-svn: 170489
2012-12-19 09:39:02 +08:00
When instantiating the arguments to an initializer, use the TreeTransform version of TransformExprs() rather than explicit loop, so that we expand pack expansions properly. Test cast coming soon... llvm-svn: 123014
2011-01-08 03:35:17 +08:00
TemplateInstantiator Instantiator(*this, TemplateArgs,
SourceLocation(),
DeclarationName());
[Sema] ArrayRef-ize SubstExprs. NFC llvm-svn: 256401
2015-12-25 07:58:29 +08:00
return Instantiator.TransformExprs(Exprs.data(), Exprs.size(),
IsCall, Outputs);
When instantiating the arguments to an initializer, use the TreeTransform version of TransformExprs() rather than explicit loop, so that we expand pack expansions properly. Test cast coming soon... llvm-svn: 123014
2011-01-08 03:35:17 +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
Sema::SubstNestedNameSpecifierLoc(NestedNameSpecifierLoc NNS,
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
const MultiLevelTemplateArgumentList &TemplateArgs) {
Use NestedNameSpecifierLoc within out-of-line variables, function, and tag definitions. Also, add support for template instantiation of NestedNameSpecifierLocs. llvm-svn: 126470
2011-02-25 10:25:35 +08:00
if (!NNS)
return NestedNameSpecifierLoc();
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +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
TemplateInstantiator Instantiator(*this, TemplateArgs, NNS.getBeginLoc(),
DeclarationName());
return Instantiator.TransformNestedNameSpecifierLoc(NNS);
}
Remove \brief commands from doxygen comments. This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
2018-05-09 09:00:01 +08:00
/// Do template substitution on declaration name info.
Added locations and type source info for DeclarationName. llvm-svn: 110860
2010-08-12 06:01:17 +08:00
DeclarationNameInfo
Sema::SubstDeclarationNameInfo(const DeclarationNameInfo &NameInfo,
const MultiLevelTemplateArgumentList &TemplateArgs) {
TemplateInstantiator Instantiator(*this, TemplateArgs, NameInfo.getLoc(),
NameInfo.getName());
return Instantiator.TransformDeclarationNameInfo(NameInfo);
}
Implement template instantiation for template names, including both template template parameters and dependent template names. For example, the oft-mentioned typename MetaFun::template apply<T1, T2>::type can now be instantiated, with the appropriate name lookup for "apply". llvm-svn: 68128
2009-04-01 02:38:02 +08:00
TemplateName
Kill off the TreeTransform::TransformTemplateName overload that has poor source-location information. llvm-svn: 126852
2011-03-03 02:46:51 +08:00
Sema::SubstTemplateName(NestedNameSpecifierLoc QualifierLoc,
TemplateName Name, SourceLocation Loc,
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) {
Implement transformation of template names within the generic tree transform, then use the result for template instantiation. The generic transformation fixes a few issues: - It copes better with template template parameters and member templates (when they're implemented). - The logic used to replace template template parameters with their arguments is now centralized in TransformDecl, so that it will apply for other declaration-instantiation steps. - The error-recovery strategy is normalized now, so that any error results in a NULL TemplateName. llvm-svn: 78292
2009-08-06 14:41:21 +08:00
TemplateInstantiator Instantiator(*this, TemplateArgs, Loc,
DeclarationName());
Kill off the TreeTransform::TransformTemplateName overload that has poor source-location information. llvm-svn: 126852
2011-03-03 02:46:51 +08:00
CXXScopeSpec SS;
SS.Adopt(QualifierLoc);
return Instantiator.TransformTemplateName(SS, Name, Loc);
Implement template instantiation for template names, including both template template parameters and dependent template names. For example, the oft-mentioned typename MetaFun::template apply<T1, T2>::type can now be instantiated, with the appropriate name lookup for "apply". llvm-svn: 68128
2009-04-01 02:38:02 +08:00
}
Separate TemplateArgument instantiation logic into its own function. No functionality change. llvm-svn: 73176
2009-06-11 08:06:24 +08:00
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
bool Sema::Subst(const TemplateArgumentLoc *Args, unsigned NumArgs,
TemplateArgumentListInfo &Result,
Track source information for template arguments and template specialization types. Preserve it through template instantiation. Preserve it through PCH, although TSTs themselves aren't serializable, so that's pretty much meaningless. llvm-svn: 85500
2009-10-29 16:12:44 +08:00
const MultiLevelTemplateArgumentList &TemplateArgs) {
Move the template instantiation logic for template arguments into the general tree transformation. Also, implement template instantiation for parameter packs. In addition, introduce logic to enter the appropriate context for subexpressions that are not potentially evaluated. llvm-svn: 78114
2009-08-05 06:27:00 +08:00
TemplateInstantiator Instantiator(*this, TemplateArgs, SourceLocation(),
DeclarationName());
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
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
return Instantiator.TransformTemplateArguments(Args, NumArgs, Result);
Separate TemplateArgument instantiation logic into its own function. No functionality change. llvm-svn: 73176
2009-06-11 08:06:24 +08:00
}
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
PR22117: Fix a case where we would get confused about which function parameter we're instantiating, if there's a ParmVarDecl within a FunctionDecl context that is not a parameter of that function. Add some asserts to catch this kind of issue more generally, and fix another bug exposed by those asserts where we were missing a local instantiation scope around substitution of explicitly-specified template arguments. llvm-svn: 225490
2015-01-09 09:19:56 +08:00
static const Decl *getCanonicalParmVarDecl(const Decl *D) {
Fix template instantiation of attributes. More specifically, fix the case where an attribute is attached to a forward declaration of a template function, and refers to parameters of that declaration, but is then inherited by the definition of that function. When the definition is instantiated, the parameter references need to be remapped. llvm-svn: 164710
2012-09-27 01:57:31 +08:00
// When storing ParmVarDecls in the local instantiation scope, we always
// want to use the ParmVarDecl from the canonical function declaration,
// since the map is then valid for any redeclaration or definition of that
// function.
if (const ParmVarDecl *PV = dyn_cast<ParmVarDecl>(D)) {
if (const FunctionDecl *FD = dyn_cast<FunctionDecl>(PV->getDeclContext())) {
unsigned i = PV->getFunctionScopeIndex();
PR22117: Fix a case where we would get confused about which function parameter we're instantiating, if there's a ParmVarDecl within a FunctionDecl context that is not a parameter of that function. Add some asserts to catch this kind of issue more generally, and fix another bug exposed by those asserts where we were missing a local instantiation scope around substitution of explicitly-specified template arguments. llvm-svn: 225490
2015-01-09 09:19:56 +08:00
// This parameter might be from a freestanding function type within the
// function and isn't necessarily referring to one of FD's parameters.
Check i < FD->getNumParams() before querying Summary: As was already stated in a previous comment, the parameter isn't necessarily referring to one of the DeclContext's parameter. We should check the index is within the range to avoid out-of-boundary access. Reviewers: gribozavr, rsmith, lebedev.ri Reviewed By: gribozavr, rsmith Subscribers: lebedev.ri, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D60055 Patch by Violet. llvm-svn: 358134
2019-04-11 04:25:07 +08:00
if (i < FD->getNumParams() && FD->getParamDecl(i) == PV)
PR22117: Fix a case where we would get confused about which function parameter we're instantiating, if there's a ParmVarDecl within a FunctionDecl context that is not a parameter of that function. Add some asserts to catch this kind of issue more generally, and fix another bug exposed by those asserts where we were missing a local instantiation scope around substitution of explicitly-specified template arguments. llvm-svn: 225490
2015-01-09 09:19:56 +08:00
return FD->getCanonicalDecl()->getParamDecl(i);
Fix template instantiation of attributes. More specifically, fix the case where an attribute is attached to a forward declaration of a template function, and refers to parameters of that declaration, but is then inherited by the definition of that function. When the definition is instantiated, the parameter references need to be remapped. llvm-svn: 164710
2012-09-27 01:57:31 +08:00
}
}
return D;
}
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
llvm::PointerUnion<Decl *, LocalInstantiationScope::DeclArgumentPack *> *
LocalInstantiationScope::findInstantiationOf(const Decl *D) {
Fix template instantiation of attributes. More specifically, fix the case where an attribute is attached to a forward declaration of a template function, and refers to parameters of that declaration, but is then inherited by the definition of that function. When the definition is instantiated, the parameter references need to be remapped. llvm-svn: 164710
2012-09-27 01:57:31 +08:00
D = getCanonicalParmVarDecl(D);
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
for (LocalInstantiationScope *Current = this; Current;
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
Current = Current->Outer) {
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
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
// Check if we found something within this scope.
When searching for the instantiation of a locally-scoped tag declaration, also look for an instantiation of its previous declarations. Fixes PR8801. llvm-svn: 122361
2010-12-22 05:22:51 +08:00
const Decl *CheckD = D;
do {
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
LocalDeclsMap::iterator Found = Current->LocalDecls.find(CheckD);
When searching for the instantiation of a locally-scoped tag declaration, also look for an instantiation of its previous declarations. Fixes PR8801. llvm-svn: 122361
2010-12-22 05:22:51 +08:00
if (Found != Current->LocalDecls.end())
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
return &Found->second;
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
When searching for the instantiation of a locally-scoped tag declaration, also look for an instantiation of its previous declarations. Fixes PR8801. llvm-svn: 122361
2010-12-22 05:22:51 +08:00
// If this is a tag declaration, it's possible that we need to look for
// a previous declaration.
if (const TagDecl *Tag = dyn_cast<TagDecl>(CheckD))
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
CheckD = Tag->getPreviousDecl();
When searching for the instantiation of a locally-scoped tag declaration, also look for an instantiation of its previous declarations. Fixes PR8801. llvm-svn: 122361
2010-12-22 05:22:51 +08:00
else
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
CheckD = nullptr;
When searching for the instantiation of a locally-scoped tag declaration, also look for an instantiation of its previous declarations. Fixes PR8801. llvm-svn: 122361
2010-12-22 05:22:51 +08:00
} while (CheckD);
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
// If we aren't combined with our outer scope, we're done.
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
if (!Current->CombineWithOuterScope)
break;
}
Step #2/N of __label__ support: keep pushing LabelDecl forward, making them be template instantiated in a more normal way and make them handle attributes like other decls. This fixes the used/unused label handling stuff, making it use the same infrastructure as other decls. llvm-svn: 125771
2011-02-18 04:34:02 +08:00
Fix to PR12262 - assertion when substituting explicit template arguments does not substitute a sizeof-pack expression. The solution is proposed by Richard Smith. Differential Revision: http://llvm-reviews.chandlerc.com/D869 llvm-svn: 186306
2013-07-15 14:14:07 +08:00
// If we're performing a partial substitution during template argument
// deduction, we may not have values for template parameters yet.
if (isa<NonTypeTemplateParmDecl>(D) || isa<TemplateTypeParmDecl>(D) ||
isa<TemplateTemplateParmDecl>(D))
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
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
Limit set of types instantiated in FindInstantiatedDecl. Starting from r236426 FindInstantiatedDecl may instantiate types that are referenced before definition. This change limit the set of types that can be instantiated by this function. llvm-svn: 237434
2015-05-15 18:10:28 +08:00
// Local types referenced prior to definition may require instantiation.
if (const CXXRecordDecl *RD = dyn_cast<CXXRecordDecl>(D))
if (RD->isLocalClass())
return nullptr;
// Enumeration types referenced prior to definition may appear as a result of
// error recovery.
if (isa<EnumDecl>(D))
Instantiate incomplete class used in template method. If a class is absent from instantiation and is incomplete, instantiate it as an incomplete class thus avoiding compiler crash. This change fixes PR18653. Differential Revision: http://reviews.llvm.org/D8281 llvm-svn: 236426
2015-05-05 00:44:39 +08:00
return nullptr;
(PR46111) Properly handle elaborated types in an implicit deduction guide As reported in PR46111, implicit instantiation of a deduction guide causes us to have an elaborated type as the parameter, rather than the dependent type. After review and feedback from @rsmith, this patch solves this problem by wrapping the value in an uninstantiated typedef/type-alias that is instantiated when required later. Differential Revision: https://reviews.llvm.org/D80743
2020-05-29 01:25:53 +08:00
// Materialized typedefs/type alias for implicit deduction guides may require
// instantiation.
if (isa<TypedefNameDecl>(D) &&
isa<CXXDeductionGuideDecl>(D->getDeclContext()))
return nullptr;
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 either have a sema bug, or we have a
// forward reference to a label declaration. Return null to indicate that
// we have an uninstantiated label.
assert(isa<LabelDecl>(D) && "declaration not instantiated in this scope");
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
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
}
Move more stuff out of Sema.h. llvm-svn: 112026
2010-08-25 13:32:35 +08:00
void LocalInstantiationScope::InstantiatedLocal(const Decl *D, Decl *Inst) {
Fix template instantiation of attributes. More specifically, fix the case where an attribute is attached to a forward declaration of a template function, and refers to parameters of that declaration, but is then inherited by the definition of that function. When the definition is instantiated, the parameter references need to be remapped. llvm-svn: 164710
2012-09-27 01:57:31 +08:00
D = getCanonicalParmVarDecl(D);
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
llvm::PointerUnion<Decl *, DeclArgumentPack *> &Stored = LocalDecls[D];
PR22117: Fix a case where we would get confused about which function parameter we're instantiating, if there's a ParmVarDecl within a FunctionDecl context that is not a parameter of that function. Add some asserts to catch this kind of issue more generally, and fix another bug exposed by those asserts where we were missing a local instantiation scope around substitution of explicitly-specified template arguments. llvm-svn: 225490
2015-01-09 09:19:56 +08:00
if (Stored.isNull()) {
#ifndef NDEBUG
// It should not be present in any surrounding scope either.
LocalInstantiationScope *Current = this;
while (Current->CombineWithOuterScope && Current->Outer) {
Current = Current->Outer;
assert(Current->LocalDecls.find(D) == Current->LocalDecls.end() &&
"Instantiated local in inner and outer scopes");
}
#endif
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
Stored = Inst;
PR22117: Fix a case where we would get confused about which function parameter we're instantiating, if there's a ParmVarDecl within a FunctionDecl context that is not a parameter of that function. Add some asserts to catch this kind of issue more generally, and fix another bug exposed by those asserts where we were missing a local instantiation scope around substitution of explicitly-specified template arguments. llvm-svn: 225490
2015-01-09 09:19:56 +08:00
} else if (DeclArgumentPack *Pack = Stored.dyn_cast<DeclArgumentPack *>()) {
[c++20] P0780R2: Support pack-expansion of init-captures. This permits an init-capture to introduce a new pack: template<typename ...T> auto x = [...a = T()] { /* a is a pack */ }; To support this, the mechanism for allowing ParmVarDecls to be packs has been extended to support arbitrary local VarDecls. llvm-svn: 361300
2019-05-22 04:10:50 +08:00
Pack->push_back(cast<VarDecl>(Inst));
PR22117: Fix a case where we would get confused about which function parameter we're instantiating, if there's a ParmVarDecl within a FunctionDecl context that is not a parameter of that function. Add some asserts to catch this kind of issue more generally, and fix another bug exposed by those asserts where we were missing a local instantiation scope around substitution of explicitly-specified template arguments. llvm-svn: 225490
2015-01-09 09:19:56 +08:00
} else {
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
assert(Stored.get<Decl *>() == Inst && "Already instantiated this local");
PR22117: Fix a case where we would get confused about which function parameter we're instantiating, if there's a ParmVarDecl within a FunctionDecl context that is not a parameter of that function. Add some asserts to catch this kind of issue more generally, and fix another bug exposed by those asserts where we were missing a local instantiation scope around substitution of explicitly-specified template arguments. llvm-svn: 225490
2015-01-09 09:19:56 +08:00
}
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 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
Fix FunctionParmPackExpr::Create() to take a ParmVarDecl* array. FunctionParmPackExpr actually stores an array of ParmVarDecl* (and accessors return that). But, the FunctionParmPackExpr::Create() constructor accepted an array of Decl *s instead. It was easy for this mismatch to occur without any obvious sign of something wrong, since both the store and the access used independent 'reinterpet_cast<XX>(this+1)' calls. llvm-svn: 248905
2015-09-30 22:04:23 +08:00
void LocalInstantiationScope::InstantiatedLocalPackArg(const Decl *D,
[c++20] P0780R2: Support pack-expansion of init-captures. This permits an init-capture to introduce a new pack: template<typename ...T> auto x = [...a = T()] { /* a is a pack */ }; To support this, the mechanism for allowing ParmVarDecls to be packs has been extended to support arbitrary local VarDecls. llvm-svn: 361300
2019-05-22 04:10:50 +08:00
VarDecl *Inst) {
Fix template instantiation of attributes. More specifically, fix the case where an attribute is attached to a forward declaration of a template function, and refers to parameters of that declaration, but is then inherited by the definition of that function. When the definition is instantiated, the parameter references need to be remapped. llvm-svn: 164710
2012-09-27 01:57:31 +08:00
D = getCanonicalParmVarDecl(D);
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
DeclArgumentPack *Pack = LocalDecls[D].get<DeclArgumentPack *>();
Pack->push_back(Inst);
}
void LocalInstantiationScope::MakeInstantiatedLocalArgPack(const Decl *D) {
PR22117: Fix a case where we would get confused about which function parameter we're instantiating, if there's a ParmVarDecl within a FunctionDecl context that is not a parameter of that function. Add some asserts to catch this kind of issue more generally, and fix another bug exposed by those asserts where we were missing a local instantiation scope around substitution of explicitly-specified template arguments. llvm-svn: 225490
2015-01-09 09:19:56 +08:00
#ifndef NDEBUG
// This should be the first time we've been told about this decl.
for (LocalInstantiationScope *Current = this;
Current && Current->CombineWithOuterScope; Current = Current->Outer)
assert(Current->LocalDecls.find(D) == Current->LocalDecls.end() &&
"Creating local pack after instantiation of local");
#endif
Fix template instantiation of attributes. More specifically, fix the case where an attribute is attached to a forward declaration of a template function, and refers to parameters of that declaration, but is then inherited by the definition of that function. When the definition is instantiated, the parameter references need to be remapped. llvm-svn: 164710
2012-09-27 01:57:31 +08:00
D = getCanonicalParmVarDecl(D);
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
llvm::PointerUnion<Decl *, DeclArgumentPack *> &Stored = LocalDecls[D];
DeclArgumentPack *Pack = new DeclArgumentPack;
Stored = Pack;
ArgumentPacks.push_back(Pack);
}
PR23029 / C++ DR2233: Allow expanded parameter packs to follow parameters with default arguments. Directly follow the wording by relaxing the AST invariant that all parameters after one with a default arguemnt also have default arguments, and removing the diagnostic on missing default arguments on a pack-expanded parameter following a parameter with a default argument. Testing also revealed that we need to special-case explicit specializations of templates with a pack following a parameter with a default argument, as such explicit specializations are otherwise impossible to write. The standard wording doesn't address this case; a issue has been filed. This exposed a bug where we would briefly consider a parameter to have no default argument while we parse a delay-parsed default argument for that parameter, which is also fixed. Partially incorporates a patch by Raul Tambre.
2020-06-03 01:42:36 +08:00
bool LocalInstantiationScope::isLocalPackExpansion(const Decl *D) {
for (DeclArgumentPack *Pack : ArgumentPacks)
if (std::find(Pack->begin(), Pack->end(), D) != Pack->end())
return true;
return false;
}
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
void LocalInstantiationScope::SetPartiallySubstitutedPack(NamedDecl *Pack,
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
const TemplateArgument *ExplicitArgs,
unsigned NumExplicitArgs) {
assert((!PartiallySubstitutedPack || PartiallySubstitutedPack == Pack) &&
"Already have a partially-substituted pack");
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
assert((!PartiallySubstitutedPack
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
|| NumArgsInPartiallySubstitutedPack == NumExplicitArgs) &&
"Wrong number of arguments in partially-substituted pack");
PartiallySubstitutedPack = Pack;
ArgsInPartiallySubstitutedPack = ExplicitArgs;
NumArgsInPartiallySubstitutedPack = NumExplicitArgs;
}
NamedDecl *LocalInstantiationScope::getPartiallySubstitutedPack(
const TemplateArgument **ExplicitArgs,
unsigned *NumExplicitArgs) const {
if (ExplicitArgs)
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
*ExplicitArgs = nullptr;
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
if (NumExplicitArgs)
*NumExplicitArgs = 0;
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
for (const LocalInstantiationScope *Current = this; Current;
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
Current = Current->Outer) {
if (Current->PartiallySubstitutedPack) {
if (ExplicitArgs)
*ExplicitArgs = Current->ArgsInPartiallySubstitutedPack;
if (NumExplicitArgs)
*NumExplicitArgs = Current->NumArgsInPartiallySubstitutedPack;
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
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
return Current->PartiallySubstitutedPack;
}
if (!Current->CombineWithOuterScope)
break;
}
[C++11] Use 'nullptr'. Sema edition. llvm-svn: 209613
2014-05-26 14:22:03 +08:00
return nullptr;
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
}