summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* -Wunused-func-template: do not warn on non-template function declarations thatRichard Smith2017-01-281-1/+6
| | | | | | | were nonetheless instantiated (particularly, non-template friends declared within class templates). llvm-svn: 293358
* PR31469: Don't add friend template class decls to redecl chain in dependent ↵Vassil Vassilev2017-01-121-2/+4
| | | | | | | | | | | | | | | | | contexts. Fixes a crash in modules where the template class decl becomes the most recent decl in the redeclaration chain and forcing the template instantiator try to instantiate the friend declaration, rather than the template definition. In practice, A::list<int> produces a TemplateSpecializationType A::__1::list<int, allocator<type-parameter-0-0> >' failing to replace to subsitute the default argument to allocator<int>. Kudos Richard Smith (D28399). llvm-svn: 291753
* Remove redundant passing around of a "ContainsAutoType" flag.Richard Smith2017-01-121-4/+3
| | | | | | | | | | | | This flag serves no purpose other than to prevent us walking through a type to check whether it contains an 'auto' specifier; this duplication of information is error-prone, does not appear to provide any performance benefit, and will become less practical once we support C++1z deduced class template types and eventually constrained types from the Concepts TS. No functionality change intended. llvm-svn: 291737
* Add the diagnose_if attribute to clang.George Burgess IV2017-01-091-19/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `diagnose_if` can be used to have clang emit either warnings or errors for function calls that meet user-specified conditions. For example: ``` constexpr int foo(int a) __attribute__((diagnose_if(a > 10, "configurations with a > 10 are " "expensive.", "warning"))); int f1 = foo(9); int f2 = foo(10); // warning: configuration with a > 10 are expensive. int f3 = foo(f2); ``` It currently only emits diagnostics in cases where the condition is guaranteed to always be true. So, the following code will emit no warnings: ``` constexpr int bar(int a) { foo(a); return 0; } constexpr int i = bar(10); ``` We hope to support optionally emitting diagnostics for cases like that (and emitting runtime checks) in the future. Release notes will appear shortly. :) Differential Revision: https://reviews.llvm.org/D27424 llvm-svn: 291418
* Fix buildbots.Richard Smith2017-01-071-1/+1
| | | | llvm-svn: 291360
* Consistently use a ConstantEvaluated context for expressions in attributes,Richard Smith2017-01-071-1/+2
| | | | | | except for those with the "attributes are unevaluated contexts" flag. llvm-svn: 291358
* [MS] Instantiate default args during instantiation of exported default ctorsReid Kleckner2017-01-051-4/+31
| | | | | | | | | | | | | | | | | | | | Summary: Replace some old code that probably pre-dated the change to delay emission of dllexported code until after the closing brace of the outermost record type. Only uninstantiated default argument expressions need to be handled now. It is enough to instantiate default argument expressions when instantiating dllexported default ctors. This also fixes some double-diagnostic issues in this area. Fixes PR31500 Reviewers: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D28274 llvm-svn: 291045
* Only instantiate members of nested classes in local classes once, rather ↵Richard Smith2017-01-041-2/+5
| | | | | | than once per enclosing class. llvm-svn: 291034
* Mark 'auto' as dependent when instantiating the type of a non-type templateRichard Smith2016-12-281-13/+13
| | | | | | | parameter. Fixes failed deduction for 'auto' non-type template parameters nested within templates. llvm-svn: 290660
* DR1315: a non-type template argument in a partial specialization is permittedRichard Smith2016-12-281-0/+18
| | | | | | | | | | to make reference to template parameters. This is only a partial implementation; we retain the restriction that the argument must not be type-dependent, since it's unclear how that would work given the existence of other language rules requiring an exact type match in this context, even for type-dependent cases (a question has been raised on the core reflector). llvm-svn: 290647
* [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
OpenPOWER on IntegriCloud