summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaTemplateInstantiate.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Refactoring. Remove Owned method from Sema.Nikola Smiljanic2014-05-291-10/+8
| | | | llvm-svn: 209812
* Refactoring. Remove release and take methods from ActionResult. Rename ↵Nikola Smiljanic2014-05-291-2/+2
| | | | | | takeAs to getAs. llvm-svn: 209800
* Consolidate some note diagnosticsAlp Toker2014-05-281-1/+1
| | | | | | | | | These note diags have the same message and can be unified further but for now let's just bring them together. Incidental change: Display a source range in the final attr diagnostic. llvm-svn: 209728
* [C++11] Use 'nullptr'. Sema edition.Craig Topper2014-05-261-39/+40
| | | | llvm-svn: 209613
* If we see an explicit instantiation declaration or definition of a functionRichard Smith2014-04-241-19/+21
| | | | | | | | | | | | | 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
* Teach getTemplateInstantiationPattern to deal with generic lambdas.Faisal Vali2014-04-031-2/+0
| | | | | | | | | | | | | No functionality change. When determining the pattern for instantiating a generic lambda call operator specialization - we must not go drilling down for the 'prototype' (i.e. as written) pattern - rather we must use our partially transformed pattern (whose DeclRefExprs are wired correctly to any enclosing lambda's decls that should be mapped correctly in a local instantiation scope) that is the templated pattern of the specialization's primary template (even though the primary template might be instantiated from a 'prototype' member-template). Previously, the drilling down was haltted by marking the instantiated-from primary template as a member-specialization (incorrectly). This prompted Richard to remark (http://llvm-reviews.chandlerc.com/D1784?id=4687#inline-10272) "It's a bit nasty to (essentially) set this bit incorrectly. Can you put the check into getTemplateInstantiationPattern instead?" In my reckless youth, I chose to ignore that comment. With the passage of time, I have come to learn the value of bowing to the will of the angry Gods ;) llvm-svn: 205543
* Refactor InstantiatingTemplate constructorsStephan Tolksdorf2014-03-131-163/+61
| | | | | | | | | | | 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
* [C++11] Replacing CXXRecordDecl iterators bases_begin() and bases_end() with ↵Aaron Ballman2014-03-131-23/+21
| | | | | | iterator_range bases(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203803
* When a type's definition is instantiated, the definition becomes visible, evenRichard Smith2014-03-101-2/+13
| | | | | | | | | 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
* [C++11] Replacing DeclBase iterators decls_begin() and decls_end() with ↵Aaron Ballman2014-03-071-14/+10
| | | | | | 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
* Normalize line endingsDavid Majnemer2014-03-021-1/+1
| | | | | | | Some files had CRLF line terminators, some only had a mixture of CRLF and LF. Switch to LF. llvm-svn: 202659
* [C++11] Replace llvm::tie with std::tie.Benjamin Kramer2014-03-021-2/+2
| | | | llvm-svn: 202639
* Update FunctionTypeLoc and related names to match r199686Alp Toker2014-01-211-2/+2
| | | | llvm-svn: 199699
* PR18477: Create a function scope representing the constructor call whenRichard Smith2014-01-171-8/+6
| | | | | | | | handling C++11 default initializers. Without this, other parts of Sema (such as lambda capture) would think the default initializer is part of the surrounding function scope. llvm-svn: 199453
* Clean up variable template handling a bit, and correct the behavior of nameRichard Smith2014-01-161-2/+12
| | | | | | lookup when declaring a variable template specialization. llvm-svn: 199438
* Fix init-captures for generic lambdas.Faisal Vali2013-12-051-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For an init capture, process the initialization expression right away. For lambda init-captures such as the following: const int x = 10; auto L = [i = x+1](int a) { return [j = x+2, &k = x](char b) { }; }; keep in mind that each lambda init-capture has to have: - its initialization expression executed in the context of the enclosing/parent decl-context. - but the variable itself has to be 'injected' into the decl-context of its lambda's call-operator (which has not yet been created). Each init-expression is a full-expression that has to get Sema-analyzed (for capturing etc.) before its lambda's call-operator's decl-context, scope & scopeinfo are pushed on their respective stacks. Thus if any variable is odr-used in the init-capture it will correctly get captured in the enclosing lambda, if one exists. The init-variables above are created later once the lambdascope and call-operators decl-context is pushed onto its respective stack. Since the lambda init-capture's initializer expression occurs in the context of the enclosing function or lambda, therefore we can not wait till a lambda scope has been pushed on before deciding whether the variable needs to be captured. We also need to process all lvalue-to-rvalue conversions and discarded-value conversions, so that we can avoid capturing certain constant variables. For e.g., void test() { const int x = 10; auto L = [&z = x](char a) { <-- don't capture by the current lambda return [y = x](int i) { <-- don't capture by enclosing lambda return y; } }; If x was not const, the second use would require 'L' to capture, and that would be an error. Make sure TranformLambdaExpr is also aware of this. Patch approved by Richard (Thanks!!) http://llvm-reviews.chandlerc.com/D2092 llvm-svn: 196454
* Sema: Instantiate local class and their members appropriatelyDavid Majnemer2013-11-271-0/+8
| | | | | | | | | | | 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
* Remove a whole lot of unused variablesAlp Toker2013-11-271-2/+1
| | | | | | | There are about 30 removed in this patch, generated by a new FixIt I haven't got round to submitting yet. llvm-svn: 195814
* And Again: Teach TreeTransform how to transform nested generic lambdas.Faisal Vali2013-10-231-6/+35
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert r193223 and r193216.Rafael Espindola2013-10-231-35/+6
| | | | | | | | | | They were causing CodeGenCXX/mangle-exprs.cpp to fail. Revert "Remove the circular reference to LambdaExpr in CXXRecordDecl." Revert "Again: Teach TreeTransform and family how to transform generic lambdas nested within templates and themselves." llvm-svn: 193226
* Again: Teach TreeTransform and family how to transform generic Faisal Vali2013-10-231-6/+35
| | | | | | | | | | | | | | | | | | | | | lambdas nested within templates and themselves. 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. 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: 193216
* Make InstantiatingTemplate depth checks clearerAlp Toker2013-10-081-2/+2
| | | | | | | | | | 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
* Revert "Teach TreeTransform and family how to transform generic lambdas ↵Rafael Espindola2013-10-041-55/+6
| | | | | | | | within templates and nested within themselves." This reverts commit r191879. It caused llvm.org/pr17476. llvm-svn: 191955
* Teach TreeTransform and family how to transform generic lambdas within ↵Faisal Vali2013-10-031-6/+55
| | | | | | | | | | | | | | | | | templates and nested within themselves. This does not yet include capturing (that is next). Please see test file for examples. This patch was LGTM'd by Doug: http://llvm-reviews.chandlerc.com/D1784 http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130930/090048.html When I first committed this patch - a bunch of buildbots were unable to compile the code that VS2010 seemed to compile. Seems like there was a dependency on Sema/Template.h which VS did not seem to need, but I have now added for the other compilers. It still compiles on Visual Studio 2010 - lets hope the buildbots remain quiet (please!) llvm-svn: 191879
* Revert changes from the nested lambdas commit till i figure out Faisal Vali2013-10-031-55/+6
| | | | | | why the buildbots are failing. llvm-svn: 191876
* Teach TreeTransform and family how to transform generic lambdas within ↵Faisal Vali2013-10-031-6/+55
| | | | | | | | | | | | | | templates and nested within themselves. This does not yet include capturing (that is next). Please see test file for examples. This patch was LGTM'd by Doug: http://llvm-reviews.chandlerc.com/D1784 llvm-svn: 191875
* Variable templates: handle instantiation of static data member templatesRichard Smith2013-09-271-0/+3
| | | | | | appropriately, especially when they appear within class templates. llvm-svn: 191548
* If a partial specialization of a member template is declared within a classRichard Smith2013-09-261-3/+15
| | | | | | | | | 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
* Handle PredefinedExpr with templates and lambdasWei Pan2013-09-161-19/+1
| | | | | | | | | | | Summary: - lambdas, blocks or captured statements in templates were not handled which causes codegen crashes. Differential Revision: http://llvm-reviews.chandlerc.com/D1628 llvm-svn: 190784
* Refactor for clarity and simplicity.Larisse Voufo2013-08-221-6/+4
| | | | llvm-svn: 188974
* Bug fix: note diagnosis on expression narrowing should say "variable ↵Larisse Voufo2013-08-141-1/+3
| | | | | | template" instead of "static data member" when appropriate llvm-svn: 188409
* Omit llvm:: before ArrayRef, as we have using llvm::ArrayRef in ↵Robert Wilhelm2013-08-091-3/+2
| | | | | | include/clang/Basic/LLVM.h. llvm-svn: 188089
* Started implementing variable templates. Top level declarations should be ↵Larisse Voufo2013-08-061-1/+41
| | | | | | 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
* Fix declaring class template methods with an attributed typedefReid Kleckner2013-07-311-0/+3
| | | | | | | | | | | | | | 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
* When we perform dependent name lookup during template instantiation, it's notRichard Smith2013-07-251-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* FIXME fix: improving diagnostics for template arguments deduction of class ↵Larisse Voufo2013-07-191-3/+6
| | | | | | | | templates and explicit specializations This patch essentially removes all the FIXMEs following calls to DeduceTemplateArguments() that want to keep track of deduction failure info. llvm-svn: 186730
* Revert "Use function overloading instead of template specialization for ↵Larisse Voufo2013-07-191-6/+3
| | | | | | | | diagnosis of bad template argument deductions." This reverts commit a730f548325756d050d4caaa28fcbffdae8dfe95. llvm-svn: 186729
* Use function overloading instead of template specialization for diagnosis of ↵Larisse Voufo2013-07-191-3/+6
| | | | | | bad template argument deductions. llvm-svn: 186727
* Fix for template substitution with packs.Eli Friedman2013-07-191-38/+27
| | | | | | | | | | 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
* Fix to PR12262 - assertion when substituting explicit template argumentsSerge Pavlov2013-07-151-0/+6
| | | | | | | | 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
* Use SmallVectorImpl instead of SmallVector for iterators and references to ↵Craig Topper2013-07-041-9/+9
| | | | | | avoid specifying the vector size unnecessarily. llvm-svn: 185610
* Propagate the invalid bit from bases to derived template classes.Matt Beaumont-Gay2013-06-211-0/+4
| | | | | | Fixes PR16292. llvm-svn: 184581
* PR16243: Use CXXThisOverride during template instantiation, and fix up theRichard Smith2013-06-071-0/+8
| | | | | | | | 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
* A little ArrayRef'ization.Richard Smith2013-05-171-7/+6
| | | | llvm-svn: 182074
* Add support for __wchar_t in -fms-extensions mode.Hans Wennborg2013-05-101-1/+1
| | | | | | | | | | | | | | | | | MSVC provides __wchar_t. This is the same as the built-in wchar_t type from C++, but it is also available with -fno-wchar and in C. The commit changes ASTContext to have two different types for this: - WCharTy is the built-in type used for wchar_t in C++ and __wchar_t. - WideCharTy is the type of a wide character literal. In C++ this is the same as WCharTy, and in C it is an integer type compatible with the type in <stddef.h>. This fixes PR15815. llvm-svn: 181587
* Sema: Give a typically small DenseMap some inline capacity.Benjamin Kramer2013-04-121-4/+3
| | | | | | Also reflow code a bit, no change in functionality. llvm-svn: 179382
* Add 178663 back.Rafael Espindola2013-04-031-2/+1
| | | | | | | | | | | 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
* Revert 178663.Rafael Espindola2013-04-031-1/+2
| | | | | | | | | | Looks like it broke http://lab.llvm.org:8011/builders/clang-x86_64-darwin10-gdb Revert "Don't compute a patched/semantic storage class." This reverts commit 8f187f62cb0487d31bc4afdfcd47e11fe9a51d05. llvm-svn: 178681
* Don't compute a patched/semantic storage class.Rafael Espindola2013-04-031-2/+1
| | | | | | | | | | | For variables and functions clang used to store two storage classes. The one "as written" in the code and a patched one, which, for example, propagates static to the following decls. This apparently is from the days clang lacked linkage computation. It is now redundant and this patch removes it. llvm-svn: 178663
* Sema: Preserve attributes on parameters in instantiated function templates.Jordan Rose2013-03-081-1/+3
| | | | | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud