summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaTemplateInstantiate.cpp
Commit message (Collapse)AuthorAgeFilesLines
* PR22117: Fix a case where we would get confused about which function parameterRichard Smith2015-01-091-7/+26
| | | | | | | | | | 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
* Fix crash-on-valid if a lambda-expression appears lexically directly within aRichard Smith2014-11-201-1/+4
| | | | | | local class inside a template. llvm-svn: 222476
* Handle use of default member initializers before end of outermost classReid Kleckner2014-11-171-31/+91
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Instantiate exception specifications when instantiating function types (otherRichard Smith2014-11-121-16/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert r219977, "Re-commit r217995 and follow-up patches (r217997, r218011, ↵NAKAMURA Takumi2014-10-171-46/+16
| | | | | | | | | | | | | r218053). These were" It broke some builders. I guess it'd be reproducible with --vg. Failing Tests (3): Clang :: CXX/except/except.spec/p1.cpp Clang :: SemaTemplate/instantiate-exception-spec-cxx11.cpp Clang :: SemaTemplate/instantiate-exception-spec.cpp llvm-svn: 220038
* Re-commit r217995 and follow-up patches (r217997, r218011, r218053). These wereRichard Smith2014-10-161-16/+46
| | | | | | | | | | | | | | | reverted in r218058 because they triggered a rejects-valid bug in MSVC. Original commit message from r217995: 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. llvm-svn: 219977
* Allow constant expressions in pragma loop hints.Tyler Nowicki2014-10-121-0/+20
| | | | | | | | 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
* Revert r217995 and follow-ups:Hans Wennborg2014-09-181-43/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Skip parens when detecting whether we're instantiating a function declaration.Richard Smith2014-09-181-2/+2
| | | | llvm-svn: 217997
* Instantiate exception specifications when instantiating function types (otherRichard Smith2014-09-171-16/+42
| | | | | | | | | | 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. llvm-svn: 217995
* Wrap to 80 columns. No behavior change.Nico Weber2014-07-281-3/+3
| | | | llvm-svn: 214059
* Make a small crash preventing change.Fariborz Jahanian2014-07-031-2/+2
| | | | llvm-svn: 212291
* 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
OpenPOWER on IntegriCloud