summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [c++1z] P0195R2: Support pack-expansion of using-declarations.Richard Smith2016-12-201-59/+134
| | | | | | | | | | | | | | This change introduces UsingPackDecl as a marker for the set of UsingDecls produced by pack expansion of a single (unresolved) using declaration. This is not strictly necessary (we just need to be able to map from the original using declaration to its expansions somehow), but it's useful to maintain the invariant that each declaration reference instantiates to refer to one declaration. This is a re-commit of r290080 (reverted in r290092) with a fix for a use-after-lifetime bug. llvm-svn: 290203
* Revert "[c++1z] P0195R2: Support pack-expansion of using-declarations."Daniel Jasper2016-12-191-134/+59
| | | | | | | This reverts commit r290080 as it leads to many Clang crashes, e.g.: http://lab.llvm.org:8011/builders/clang-cmake-aarch64-quick/builds/1814 llvm-svn: 290092
* [c++1z] P0195R2: Support pack-expansion of using-declarations.Richard Smith2016-12-191-59/+134
| | | | | | | | | | | This change introduces UsingPackDecl as a marker for the set of UsingDecls produced by pack expansion of a single (unresolved) using declaration. This is not strictly necessary (we just need to be able to map from the original using declaration to its expansions somehow), but it's useful to maintain the invariant that each declaration reference instantiates to refer to one declaration. llvm-svn: 290080
* Fix some interactions between C++11 and C++14 features and using-declarations:Richard Smith2016-12-181-23/+27
| | | | | | | | | | | * a dependent non-type using-declaration within a function template can be valid, as it can refer to an enumerator, so don't reject it in the template definition * we can partially substitute into a dependent using-declaration if it appears within a (local class in a) generic lambda within a function template, which means an UnresolvedUsing*Decl doesn't necessarily instantiate to a UsingDecl. llvm-svn: 290071
* [Sema] Set range end of constructors and destructors in template instantiationsMalcolm Parsons2016-11-281-0/+2
| | | | | | | | | | | | | | | | | | Summary: clang-tidy checks frequently use source ranges of functions. The source range of constructors and destructors in template instantiations is currently a single token. The factory method for constructors and destructors does not allow the end source location to be specified. Set end location manually after creating instantiation. Reviewers: aaron.ballman, rsmith, arphaman Subscribers: arphaman, cfe-commits Differential Revision: https://reviews.llvm.org/D26849 llvm-svn: 288025
* [Sema] Fix a bug in enable_if condition instantiation.George Burgess IV2016-11-171-3/+2
| | | | | | | | | | | During template instantiation, we currently fall back to just calling Sema::SubstExpr for enable_if attributes that aren't value-dependent or type-dependent. Since Sema::SubstExpr strips off any implicit casts we've added to an expression, it's possible that this behavior will leave us with an enable_if condition that's just a DeclRefExpr. Conditions like that deeply confuse Sema::CheckEnableIf. llvm-svn: 287187
* Fix PR28366: Handle variables from enclosing local scopes more gracefully ↵Faisal Vali2016-11-131-1/+1
| | | | | | | | | | | | | | | | | | during constant expression evaluation. Only look for a variable's value in the constant expression evaluation activation frame, if the variable was indeed declared in that frame, otherwise it might be a constant expression and be usable within a nested local scope or emit an error. void f(char c) { struct X { static constexpr char f() { return c; // error gracefully here as opposed to crashing. } }; int I = X::f(); } llvm-svn: 286748
* Reinstate r284008 reverted in r284081, with two fixes:Richard Smith2016-10-141-22/+18
| | | | | | | | | | | | | | | | | | | 1) Merge and demote variable definitions when we find a redefinition in MergeVarDecls, not only when we find one in AddInitializerToDecl (we only reach the second case if it's the addition of the initializer itself that converts an existing declaration into a definition). 2) When rebuilding a redeclaration chain for a variable, if we merge two definitions together, mark the definitions as merged so the retained definition is made visible whenever the demoted definition would have been. Original commit message (from r283882): [modules] PR28752: Do not instantiate variable declarations which are not visible. Original patch by Vassil Vassilev! Changes listed above are mine. llvm-svn: 284284
* Revert r284008. This is us to fail to instantiate static data members in someRichard Smith2016-10-121-18/+22
| | | | | | cases. I'm working on reducing a testcase. llvm-svn: 284081
* Reinstate r283887 and r283882.Vassil Vassilev2016-10-121-22/+18
| | | | | | | | | | | Original message: "[modules] PR28752: Do not instantiate variable declarations which are not visible. https://reviews.llvm.org/D24508 Patch developed in collaboration with Richard Smith!" llvm-svn: 284008
* Revert r283887 and r283882, until the issue is understood and fixed.Vassil Vassilev2016-10-111-18/+22
| | | | llvm-svn: 283890
* [modules] PR28752: Do not instantiate variable declarations which are not ↵Vassil Vassilev2016-10-111-22/+18
| | | | | | | | | | visible. https://reviews.llvm.org/D24508 Patch developed in collaboration with Richard Smith! llvm-svn: 283882
* [Sema] Use unique_ptr instead of raw pointers in the late-parsed templates map.Justin Lebar2016-10-101-3/+4
| | | | | | | | | | | | | | | Summary: This is possible now that MapVector supports move-only values. Depends on D25404. Reviewers: timshen Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D25405 llvm-svn: 283766
* Simplify. NFC.Vassil Vassilev2016-09-131-3/+3
| | | | llvm-svn: 281315
* PR12298 et al: don't recursively instantiate a template specialization fromRichard Smith2016-08-311-9/+26
| | | | | | | | | | | | | | | 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
* Fix member call on null pointer, found by sanitizer buildbot.Richard Smith2016-08-231-2/+4
| | | | llvm-svn: 279571
* Fix regression introduced by r279164: only pass definitions as the PatternDefRichard Smith2016-08-231-45/+29
| | | | | | | | | | | | | | | | | | | | | | | | | to DiagnoseUninstantiableTemplate, teach hasVisibleDefinition to correctly determine whether a function definition is visible, and mark both the function and the template as visible when merging function template definitions to provide hasVisibleDefinition with the relevant information. The change to always pass the right declaration as the PatternDef to DiagnoseUninstantiableTemplate also caused those checks to happen before other diagnostics in InstantiateFunctionDefinition, giving worse diagnostics for the same situations, so I sunk the relevant diagnostics into DiagnoseUninstantiableTemplate. Those parts of this patch are based on changes in reviews.llvm.org/D23492 by Vassil Vassilev. This reinstates r279486, reverted in r279500, with a fix to DiagnoseUninstantiableTemplate to only mark uninstantiable explicit instantiation declarations as invalid if we actually diagnosed them. (When we trigger an explicit instantiation of a class member from an explicit instantiation declaration for the class, it's OK if there is no corresponding definition and we certainly don't want to mark the member invalid in that case.) This previously caused a build failure during bootstrap. llvm-svn: 279557
* Revert r279486 "Fix regression introduced by r279164"Chandler Carruth2016-08-231-29/+45
| | | | | | | Build bots seem unhappy and as Richard was leaving he asked me to revert this for him. Doing so. llvm-svn: 279500
* Fix regression introduced by r279164: only pass definitions as the PatternDefRichard Smith2016-08-221-45/+29
| | | | | | | | | | | | | | | | to DiagnoseUninstantiableTemplate, teach hasVisibleDefinition to correctly determine whether a function definition is visible, and mark both the function and the template as visible when merging function template definitions to provide hasVisibleDefinition with the relevant information. The change to always pass the right declaration as the PatternDef to DiagnoseUninstantiableTemplate also caused those checks to happen before other diagnostics in InstantiateFunctionDefinition, giving worse diagnostics for the same situations, so I sunk the relevant diagnostics into DiagnoseUninstantiableTemplate. Those parts of this patch are based on changes in reviews.llvm.org/D23492 by Vassil Vassilev. llvm-svn: 279486
* PR28794: Don't try to instantiate function templates which are not visible.Vassil Vassilev2016-08-181-11/+21
| | | | | | Reviewed by Richard Smith. llvm-svn: 279164
* P0217R3: template instantiation support for decomposition declarations.Richard Smith2016-08-121-8/+30
| | | | llvm-svn: 278458
* Remove unused and undesirable reference from BindingDecl to DecompositionDecl.Richard Smith2016-08-121-7/+1
| | | | llvm-svn: 278448
* P0217R3: Constant expression evaluation for decomposition declarations.Richard Smith2016-08-121-1/+7
| | | | llvm-svn: 278447
* Reapply r276069 with workaround for MSVC 2013Hubert Tong2016-07-301-1/+5
| | | | llvm-svn: 277286
* P0217R3: Parsing support and framework for AST representation of C++1zRichard Smith2016-07-221-0/+10
| | | | | | | | | | | decomposition declarations. There are a couple of things in the wording that seem strange here: decomposition declarations are permitted at namespace scope (which we partially support here) and they are permitted as the declaration in a template (which we reject). llvm-svn: 276492
* Revert r276069: MSVC bots not happyHubert Tong2016-07-201-5/+1
| | | | llvm-svn: 276074
* Concepts: Create space for requires-clause in TemplateParameterList; NFCHubert Tong2016-07-201-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Space for storing the //constraint-expression// of the //requires-clause// associated with a `TemplateParameterList` is arranged by taking a bit out of the `NumParams` field for the purpose of determining whether there is a //requires-clause// or not, and by adding to the trailing objects tied to the `TemplateParameterList`. An accessor is provided. An appropriate argument is supplied to `TemplateParameterList::Create` at the various call sites. Serialization changes will addressed as the Concepts implementation becomes more solid. Drive-by fix: This change also replaces the custom `FixedSizeTemplateParameterListStorage` implementation with one that follows the interface provided by `llvm::TrailingObjects`. Reviewers: aaron.ballman, faisalv, rsmith Subscribers: cfe-commits, nwilson Differential Revision: https://reviews.llvm.org/D19322 llvm-svn: 276069
* [AST] Keep track of the left brace source location of a tag decl.Argyrios Kyrtzidis2016-07-151-3/+1
| | | | | | This is useful for source modification tools. There will be a follow-up commit using it. llvm-svn: 275590
* [AST] Use ArrayRef in more interfacesDavid Majnemer2016-07-071-4/+3
| | | | | | | | | ArrayRef is a little better than passing around a pointer/length pair. No functional change is intended. llvm-svn: 274732
* [AST] Use ArrayRef in more interfacesDavid Majnemer2016-07-061-10/+5
| | | | | | | | ArrayRef is a little better than passing around a pointer/length pair. No functional change is intended. llvm-svn: 274601
* [AST] Use ArrayRef in more interfacesDavid Majnemer2016-07-031-12/+6
| | | | | | | | ArrayRef is a little better than passing around a pointer/length pair. No functional change is intended. llvm-svn: 274475
* P0136R1, DR1573, DR1645, DR1715, DR1736, DR1903, DR1941, DR1959, DR1991:Richard Smith2016-06-281-36/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Replace inheriting constructors implementation with new approach, voted into C++ last year as a DR against C++11. Instead of synthesizing a set of derived class constructors for each inherited base class constructor, we make the constructors of the base class visible to constructor lookup in the derived class, using the normal rules for using-declarations. For constructors, UsingShadowDecl now has a ConstructorUsingShadowDecl derived class that tracks the requisite additional information. We create shadow constructors (not found by name lookup) in the derived class to model the actual initialization, and have a new expression node, CXXInheritedCtorInitExpr, to model the initialization of a base class from such a constructor. (This initialization is special because it performs real perfect forwarding of arguments.) In cases where argument forwarding is not possible (for inalloca calls, variadic calls, and calls with callee parameter cleanup), the shadow inheriting constructor is not emitted and instead we directly emit the initialization code into the caller of the inherited constructor. Note that this new model is not perfectly compatible with the old model in some corner cases. In particular: * if B inherits a private constructor from A, and C uses that constructor to construct a B, then we previously required that A befriends B and B befriends C, but the new rules require A to befriend C directly, and * if a derived class has its own constructors (and so its implicit default constructor is suppressed), it may still inherit a default constructor from a base class llvm-svn: 274049
* Implement C++17 P0386R2, inline variables. (The 'inline' specifier gives aRichard Smith2016-06-251-8/+21
| | | | | | | variable weak discardable linkage and partially-ordered initialization, and is implied for constexpr static data members.) llvm-svn: 273754
* Use more ArrayRefsDavid Majnemer2016-06-241-4/+4
| | | | | | No functional change is intended, just a small refactoring. llvm-svn: 273647
* Produce better pretty stack traces from crashes in template instantiation: addRichard Smith2016-05-261-2/+6
| | | | | | | | 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
* [modules] Enforce the rules that an explicit or partial specialization must beRichard Smith2016-05-051-0/+8
| | | | | | | | 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
* [Sema] Fix a crash that occurs when a variable template is initializedAkira Hatanaka2016-04-281-3/+8
| | | | | | | | | | | | | | | with a generic lambda. This patch fixes Sema::InstantiateVariableInitializer to switch to the context of the variable before instantiating its initializer, which is necessary to set the correct type for VarTemplateSpecializationDecl. This is the first part of the patch that was reviewed here: http://reviews.llvm.org/D19175 rdar://problem/23440346 llvm-svn: 267956
* Warn if function or variable cannot be implicitly instantiatedSerge Pavlov2016-04-191-4/+25
| | | | | | | | | | | | With this patch compiler emits warning if it tries to make implicit instantiation of a template but cannot find the template definition. The warning can be suppressed by explicit instantiation declaration or by command line options -Wundefined-var-template and -Wundefined-func-template. The implementation follows the discussion of http://reviews.llvm.org/D12326. Differential Revision: http://reviews.llvm.org/D16396 llvm-svn: 266719
* [OPENMP 4.0] Support for 'linear' clause in 'declare simd' directive.Alexey Bataev2016-04-121-5/+22
| | | | | | | | | | The linear clause declares one or more list items to be private to a SIMD lane and to have a linear relationship with respect to the iteration space of a loop. 'linear' '(' <linear-list> [ ':' <linear-step> ] ')' When a linear-step expression is specified in a linear clause it must be either a constant integer expression or an integer-typed parameter that is specified in a uniform clause on the directive. The special this pointer can be used as if was one of the arguments to the function in any of the linear, aligned, or uniform clauses. llvm-svn: 266056
* [OPENMP 4.0] Support for 'aligned' clause in 'declare simd' directive.Alexey Bataev2016-04-121-4/+16
| | | | | | | | | The aligned clause declares that the object to which each list item points is aligned to the number of bytes expressed in the optional parameter of the aligned clause. 'aligned' '(' <argument-list> [ ':' <alignment> ] ')' The optional parameter of the aligned clause, alignment, must be a constant positive integer expression. If no optional parameter is specified, implementation-defined default alignments for SIMD instructions on the target platforms are assumed. The special this pointer can be used as if was one of the arguments to the function in any of the linear, aligned, or uniform clauses. llvm-svn: 266052
* [OPENMP 4.0] Support for 'uniform' clause in 'declare simd' directive.Alexey Bataev2016-04-121-4/+31
| | | | | | | | | OpenMP 4.0 defines clause 'uniform' in 'declare simd' directive: 'uniform' '(' <argument-list> ')' The uniform clause declares one or more arguments to have an invariant value for all concurrent invocations of the function in the execution of a single SIMD loop. The special this pointer can be used as if was one of the arguments to the function in any of the linear, aligned, or uniform clauses. llvm-svn: 266041
* [OPENMP 4.0] Parsing/sema analysis for 'simdlen' clause in 'declare simd'Alexey Bataev2016-04-071-0/+21
| | | | | | | | | | | | construct. OpenMP 4.0 defines '#pragma omp declare simd' construct that may have associated 'simdlen' clause with constant positive expression as an argument: simdlen(<const_expr>) Patch adds parsin and semantic analysis for simdlen clause. llvm-svn: 265668
* Semantic analysis for the swiftcall calling convention.John McCall2016-03-031-0/+6
| | | | | | | I've tried to keep the infrastructure behind parameter ABI treatments fairly general. llvm-svn: 262587
* [OPENMP 4.0] Initial support for 'omp declare reduction' construct.Alexey Bataev2016-03-031-0/+75
| | | | | | | | | | | | | | | | | Add parsing, sema analysis and serialization/deserialization for 'declare reduction' construct. User-defined reductions are defined as #pragma omp declare reduction( reduction-identifier : typename-list : combiner ) [initializer ( initializer-expr )] These custom reductions may be used in 'reduction' clauses of OpenMP constructs. The combiner specifies how partial results can be combined into a single value. The combiner can use the special variable identifiers omp_in and omp_out that are of the type of the variables being reduced with this reduction-identifier. Each of them will denote one of the values to be combined before executing the combiner. It is assumed that the special omp_out identifier will refer to the storage that holds the resulting combined value after executing the combiner. As the initializer-expr value of a user-defined reduction is not known a priori the initializer-clause can be used to specify one. Then the contents of the initializer-clause will be used as the initializer for private copies of reduction list items where the omp_priv identifier will refer to the storage to be initialized. The special identifier omp_orig can also appear in the initializer-clause and it will refer to the storage of the original variable to be reduced. Differential Revision: http://reviews.llvm.org/D11182 llvm-svn: 262582
* Improve some infrastructure for extended parameter infos andJohn McCall2016-03-031-0/+8
| | | | | | | fix a bug with the instantiation of ns_consumed parameter attributes in ARC. llvm-svn: 262551
* Serialize `#pragma detect_mismatch`.Nico Weber2016-03-021-0/+5
| | | | | | | This is like r262493, but for pragma detect_mismatch instead of pragma comment. The two pragmas have similar behavior, so use the same approach for both. llvm-svn: 262506
* Serialize `#pragma comment`.Nico Weber2016-03-021-0/+5
| | | | | | | | | | | | | | `#pragma comment` was handled by Sema calling a function on ASTConsumer, and CodeGen then implementing this function and writing things to its output. Instead, introduce a PragmaCommentDecl AST node and hang one off the TranslationUnitDecl for every `#pragma comment` line, and then use the regular serialization machinery. (Since PragmaCommentDecl has codegen relevance, it's eagerly deserialized.) http://reviews.llvm.org/D17799 llvm-svn: 262493
* Fix the template instantiation of ExtParameterInfos; tests to follow.John McCall2016-03-011-2/+3
| | | | llvm-svn: 262289
* Fix assertion failure on MaybeODRUseExprs.Manman Ren2016-02-241-0/+2
| | | | | | | | | | | | | | | | | | In VisitNonTypeTemplateParamDecl, before SubstExpr with the default argument, we should create a ConstantEvaluated ExpressionEvaluationContext. Without this, it is possible to use a PotentiallyEvaluated ExpressionEvaluationContext; and MaybeODRUseExprs will not be cleared when popping the context, causing assertion failure. This is similar to how we handle the context before SubstExpr with the default argument, in SubstDefaultTemplateArgument. Part of PR13986. rdar://24480205 Differential Revision: http://reviews.llvm.org/D17576 llvm-svn: 261803
* [OPENMP] Rename OMPCapturedFieldDecl to OMPCapturedExprDecl, NFC.Alexey Bataev2016-02-111-2/+2
| | | | | | | | OMPCapturedExprDecl allows caopturing not only of fielddecls, but also other expressions. It also allows to simplify codegen for several clauses. llvm-svn: 260492
OpenPOWER on IntegriCloud