summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaTemplateInstantiate.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* Streamify getNameForDiagnostic and remove the string versions of ↵Benjamin Kramer2013-02-221-6/+10
| | | | | | PrintTemplateArgumentList. llvm-svn: 175894
* Use None rather than Optional<T>() where possible.David Blaikie2013-02-211-2/+2
| | | | llvm-svn: 175705
* Include llvm::Optional in clang/Basic/LLVM.hDavid Blaikie2013-02-201-9/+9
| | | | | | Post-commit CR feedback from Jordan Rose regarding r175594. llvm-svn: 175679
* Replace TypeLoc llvm::cast support to be well-defined.David Blaikie2013-02-181-8/+7
| | | | | | | | | | | | | | 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
* Remove useless 'llvm::' qualifier from names like StringRef and others that areDmitri Gribenko2013-01-121-1/+1
| | | | | | brought into 'clang' namespace by clang/Basic/LLVM.h llvm-svn: 172323
* PR13470: Ensure that copy-list-initialization isntantiates asRichard Smith2012-12-191-1/+10
| | | | | | | | | | | | 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
* Add a FIXME.Richard Smith2012-12-081-0/+1
| | | | llvm-svn: 169664
* Sort all of Clang's files under 'lib', and fix up the broken headersChandler Carruth2012-12-041-5/+5
| | | | | | | | | | | | | 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
* Store this Decl* as a Decl* instead of a uintptr_t. No functionality change.Nick Lewycky2012-11-161-21/+19
| | | | llvm-svn: 168145
* Fix template instantiation of attributes. More specifically, fix the caseDeLesley Hutchins2012-09-261-0/+20
| | | | | | | | | 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
* Fix the AST representation for non-type template arguments to encodeEli Friedman2012-09-261-3/+4
| | | | | | | | | | | | 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
* Remove Context argument from TemplateDeductionInfo constructor. It was no ↵Craig Topper2012-09-191-1/+1
| | | | | | longer needed after the unused Context member was removed in r164104. llvm-svn: 164196
* Fix a couple of Doxygen issues pointed out by -Wdocumentation.Dmitri Gribenko2012-09-121-1/+1
| | | | llvm-svn: 163722
* PR13811: Add a FunctionParmPackExpr node to handle references to functionRichard Smith2012-09-121-1/+92
| | | | | | | parameter packs where the reference is not being expanded but the pack has been. Previously, Clang would segfault in such cases. llvm-svn: 163672
* Rip out remnants of move semantic emulation and smart pointers in Sema.Benjamin Kramer2012-08-231-1/+1
| | | | | | | These were nops for quite a while and only lead to confusion. ASTMultiPtr now behaves like a proper dumb array reference. llvm-svn: 162475
* Don't form a null reference when checking for validity of an anonymousRichard Smith2012-08-171-2/+1
| | | | | | | 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
* Check access to friend declarations. There's a number of differentJohn McCall2012-08-101-0/+3
| | | | | | | | | | | | | | 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
* Final piece of core issue 1330: delay computing the exception specification ofRichard Smith2012-07-271-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* PR12057: Allow variadic template pack expansions to cross lambda boundaries.Richard Smith2012-07-251-0/+13
| | | | | | | | | | 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
* PR13365: Fix code which was trying to treat an array of DeducedTemplateArgumentRichard Smith2012-07-161-56/+46
| | | | | | | | as an array of its base class TemplateArgument. Switch the const TemplateArgument* parameters of InstantiatingTemplate's constructors to ArrayRef<TemplateArgument> to prevent this from happening again in the future. llvm-svn: 160245
* Stop instantiating a class if we hit a static_assert failure. Also, if theRichard Smith2012-07-111-1/+8
| | | | | | | static_assert fails when parsing the template, don't diagnose it again on every instantiation. llvm-svn: 160088
* PR13136:Richard Smith2012-07-091-2/+10
| | | | | | | | | | | | | | | * 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
OpenPOWER on IntegriCloud