summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaTemplateInstantiate.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix PR12378: provide conversion warnings on default args of function templatesDavid Blaikie2012-04-301-2/+7
| | | | | | | | | | | | | Apparently we weren't checking default arguments when they were instantiated. This adds the check, fixes the lack of instantiation caching (which seems like it was mostly implemented but just missed the last step), and avoids implementing non-dependent default args (for non-dependent parameter types) as uninstantiated default arguments (so that we don't warn once for every instantiation when it's not instantiation dependent). Reviewed by Richard Smith. llvm-svn: 155838
* PR12647: An alias template instantiation which occurs in a SFINAE context isRichard Smith2012-04-261-1/+6
| | | | | | itself a SFINAE context. llvm-svn: 155621
* Implement DR1330 in C++11 mode, to support libstdc++4.7 which uses it.Richard Smith2012-04-171-0/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We have a new flavor of exception specification, EST_Uninstantiated. A function type with this exception specification carries a pointer to a FunctionDecl, and the exception specification for that FunctionDecl is instantiated (if needed) and used in the place of the function type's exception specification. When a function template declaration with a non-trivial exception specification is instantiated, the specialization's exception specification is set to this new 'uninstantiated' kind rather than being instantiated immediately. Expr::CanThrow has migrated onto Sema, so it can instantiate exception specs on-demand. Also, any odr-use of a function triggers the instantiation of its exception specification (the exception specification could be needed by IRGen). In passing, fix two places where a DeclRefExpr was created but the corresponding function was not actually marked odr-used. We used to get away with this, but don't any more. Also fix a bug where instantiating an exception specification which refers to function parameters resulted in a crash. We still have the same bug in default arguments, which I'll be looking into next. This, plus a tiny patch to fix libstdc++'s common_type, is enough for clang to parse (and, in very limited testing, support) all of libstdc++4.7's standard headers. llvm-svn: 154886
* Implement C++11 [expr.prim.general]p3, which permits the use of 'this'Douglas Gregor2012-04-161-18/+51
| | | | | | | | | | | | | | | | | | | | | | | in the declaration of a non-static member function after the (optional) cv-qualifier-seq, which in practice means in the exception specification and late-specified return type. The new scheme here used to manage 'this' outside of a member function scope is more general than the Scope-based mechanism previously used for non-static data member initializers and late-parsesd attributes, because it can also handle the cv-qualifiers on the member function. Note, however, that a separate pass is required for static member functions to determine whether 'this' was used, because we might not know that we have a static function until after declaration matching. Finally, this introduces name mangling for 'this' and for the implicit 'this', which is intended to match GCC's mangling. Independent verification for the new mangling test case would be appreciated. Fixes PR10036 and PR12450. llvm-svn: 154799
* Implement support for null non-type template arguments for non-typeDouglas Gregor2012-04-061-9/+15
| | | | | | | template parameters of pointer, pointer-to-member, or nullptr_t type in C++11. Fixes PR9700 / <rdar://problem/11193097>. llvm-svn: 154219
* When defining a forward-declared enum, don't try to attach the definition toRichard Smith2012-03-231-1/+2
| | | | | | | a previous declaration if the redeclaration is invalid. That way lies madness. Fixes a crash-on-invalid reported by Abramo. llvm-svn: 153349
* Support for definitions of member enumerations of class templates outside theRichard Smith2012-03-231-1/+14
| | | | | | | class template's definition, and for explicit specializations of such enum members. llvm-svn: 153304
* Instantiating a class template should not instantiate the definition of anyRichard Smith2012-03-141-31/+140
| | | | | | | | scoped enumeration members. Later uses of an enumeration temploid as a nested name specifier should cause its instantiation. Plus some groundwork for explicit specialization of member enumerations of class templates. llvm-svn: 152750
* Unify naming of LangOptions variable/get function across the Clang stack ↵David Blaikie2012-03-111-3/+3
| | | | | | | | | | (Lex to AST). The member variable is always "LangOpts" and the member function is always "getLangOpts". Reviewed by Chris Lattner llvm-svn: 152536
* Introduce support for template instantiation of lambdaDouglas Gregor2012-02-131-0/+8
| | | | | | | | | | | | | | | | | | expressions. This is mostly a simple refact, splitting the main "start a lambda expression" function into smaller chunks that are driven either from the parser (Sema::ActOnLambdaExpr) or during AST transformation (TreeTransform::TransformLambdaExpr). A few minor interesting points: - Added new entry points for TreeTransform, so that we can explicitly establish the link between the lambda closure type in the template and the lambda closure type in the instantiation. - Added a bit into LambdaExpr specifying whether it had an explicit result type or not. We should have had this anyway. This code is 'lightly' tested. llvm-svn: 150417
* Represent C++ direct initializers as ParenListExprs before semantic analysisSebastian Redl2012-02-111-6/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | instead of having a special-purpose function. - ActOnCXXDirectInitializer, which was mostly duplication of AddInitializerToDecl (leading e.g. to PR10620, which Eli fixed a few days ago), is dropped completely. - MultiInitializer, which was an ugly hack I added, is dropped again. - We now have the infrastructure in place to distinguish between int x = {1}; int x({1}); int x{1}; -- VarDecl now has getInitStyle(), which indicates which of the above was used. -- CXXConstructExpr now has a flag to indicate that it represents list- initialization, although this is not yet used. - InstantiateInitializer was renamed to SubstInitializer and simplified. - ActOnParenOrParenListExpr has been replaced by ActOnParenListExpr, which always produces a ParenListExpr. Placed that so far failed to convert that back to a ParenExpr containing comma operators have been fixed. I'm pretty sure I could have made a crashing test case before this. The end result is a (I hope) considerably cleaner design of initializers. More importantly, the fact that I can now distinguish between the various initialization kinds means that I can get the tricky generalized initializer test cases Johannes Schaub supplied to work. (This is not yet done.) This commit passed self-host, with the resulting compiler passing the tests. I hope it doesn't break more complicated code. It's a pretty big change, but one that I feel is necessary. llvm-svn: 150318
* For class template implicit instantiation, also update its location to pointArgyrios Kyrtzidis2012-02-111-0/+1
| | | | | | | | | | | | | | | | | | to the pattern template that it came from, otherwise we had this situation: template <typename T1, typename T2> struct S { }; template <typename T> struct S<T, int> { }; void f() { S<int, int> s; // location of declaration "S<int, int>" was of "S<T1, T2>" not "S<T, int>" } llvm-svn: 150290
* Move instantiateTemplateAttribute into the sema namespace, make helpers static.Benjamin Kramer2012-02-061-2/+6
| | | | llvm-svn: 149864
* When we're substituting into a function parameter pack and expect toDouglas Gregor2012-01-251-8/+18
| | | | | | | get a function parameter pack (but don't due to weird substitutions), complain. Fixes the last bit of PR11848. llvm-svn: 148960
* Fix PR11848: decree that an alias template contains an unexpanded parameter packRichard Smith2012-01-251-1/+1
| | | | | | | | | | | | | iff its substitution contains an unexpanded parameter pack. This has the effect that we now reject declarations such as this (which we used to crash when expanding): template<typename T> using Int = int; template<typename ...Ts> void f(Int<Ts> ...ints); The standard is inconsistent on how this case should be treated. llvm-svn: 148905
* Delayed template instantiation of late-parsed attributes.DeLesley Hutchins2012-01-201-0/+23
| | | | llvm-svn: 148595
* Remove unreachable code in Clang. (replace with llvm_unreachable where ↵David Blaikie2012-01-171-2/+2
| | | | | | appropriate or when GCC requires it) llvm-svn: 148292
* De-virtualize getPreviousDecl() and getMostRecentDecl() when we knowDouglas Gregor2012-01-141-2/+2
| | | | | | | | | | | | we have a redeclarable type, and only use the new virtual versions (getPreviousDeclImpl() and getMostRecentDeclImpl()) when we don't have that type information. This keeps us from penalizing users with strict type information (and is the moral equivalent of a "final" method). Plus, settle on the names getPreviousDecl() and getMostRecentDecl() throughout. llvm-svn: 148187
* Fix a crash on invalid, http://llvm.org/pr11599Nico Weber2011-12-201-2/+10
| | | | llvm-svn: 146988
* Fixed implicit instantiations source range.Abramo Bagnara2011-11-181-1/+3
| | | | llvm-svn: 144977
* Fixed source range for template implicit instantiations.Abramo Bagnara2011-10-031-0/+3
| | | | llvm-svn: 141018
* Only print _Bool as 'bool' when 'bool' is defined as an object-likeDouglas Gregor2011-09-271-2/+2
| | | | | | macro whose only replacement token is '_Bool'. llvm-svn: 140656
* When 'bool' is not a built-in type but is defined as a macro, printDouglas Gregor2011-09-271-2/+2
| | | | | | | 'bool' rather than '_Bool' within types, to make things a bit more readable. Fixes <rdar://problem/10063263>. llvm-svn: 140650
* ArrayRef-ifying the fields passed to Sema::ActOnFieldsDavid Blaikie2011-09-221-3/+2
| | | | llvm-svn: 140293
* ArrayRef-ifying the UnexpandedParameterPacks passed to ↵David Blaikie2011-09-221-4/+2
| | | | | | Sema::CheckParameterPacksForExpansion llvm-svn: 140290
* Implement function template specialization at class scope extension in ↵Francois Pichet2011-08-141-2/+3
| | | | | | | | | | | | | | | | | Microsoft mode. A new AST node is introduced: ClassScopeFunctionSpecialization. This node holds a FunctionDecl that is not yet specialized; then during the class template instantiation the ClassScopeFunctionSpecialization will spawn the actual function specialization. Example: template <class T> class A { public: template <class U> void f(U p) { } template <> void f(int p) { } // <== class scope specialization }; This extension is necessary to parse MSVC standard C++ headers, MFC and ATL code. BTW, with this feature in, clang can parse (-fsyntax-only) all the MSVC 2010 standard header files without any error. llvm-svn: 137573
* remove unneeded llvm:: namespace qualifiers on some core types now that ↵Chris Lattner2011-07-231-16/+15
| | | | | | | | LLVM.h imports them into the clang namespace. llvm-svn: 135852
* Replace r134583's fix for PR10290 with one which also works for ↵Richard Smith2011-07-201-26/+8
| | | | | | non-value-dependent cases. llvm-svn: 135543
* Create a new expression node, SubstNonTypeTemplateParmExpr,John McCall2011-07-151-56/+53
| | | | | | | | to represent a fully-substituted non-type template parameter. This should improve source fidelity, as well as being generically useful for diagnostics and such. llvm-svn: 135243
* In an in-class initialization, defer checks for value-dependent initializationNick Lewycky2011-07-071-3/+5
| | | | | | expressions. llvm-svn: 134583
* Introduce the notion of instantiation dependence into Clang's AST. ADouglas Gregor2011-07-011-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | type/expression/template argument/etc. is instantiation-dependent if it somehow involves a template parameter, even if it doesn't meet the requirements for the more common kinds of dependence (dependent type, type-dependent expression, value-dependent expression). When we see an instantiation-dependent type, we know we always need to perform substitution into that instantiation-dependent type. This keeps us from short-circuiting evaluation in places where we shouldn't, and lets us properly implement C++0x [temp.type]p2. In theory, this would also allow us to properly mangle instantiation-dependent-but-not-dependent decltype types per the Itanium C++ ABI, but we aren't quite there because we still mangle based on the canonical type in cases like, e.g., template<unsigned> struct A { }; template<typename T> void f(A<sizeof(sizeof(decltype(T() + T())))>) { } template void f<int>(A<sizeof(sizeof(int))>); and therefore get the wrong answer. llvm-svn: 134225
* Preserve that a TemplateName was arrived at by substitutingJohn McCall2011-06-301-2/+3
| | | | | | | | | | | for a template template parameter. Uses to follow. I've also made the uniquing of SubstTemplateTemplateParmPacks use a ContextualFoldingSet as a minor space efficiency. llvm-svn: 134137
* When performing substitution of default template template parametersDouglas Gregor2011-06-151-2/+14
| | | | | | | | | | before the template parameters have acquired a proper context (e.g., because the enclosing context has yet to be built), provide empty parameter lists for all outer template parameter scopes to inhibit any substitution for those template parameters. Fixes PR9643 / <rdar://problem/9251019>. llvm-svn: 133055
* Implement support for C++11 in-class initialization of non-static data members.Richard Smith2011-06-111-2/+46
| | | | llvm-svn: 132878
* Made changes to how 'struct'/'class' mismatches are handled in ↵Richard Trieu2011-06-101-1/+2
| | | | | | | | | | | | | | | | | -Wmismatched-tags. - Removed fix-it hints from template instaniations since changes to the templates are rarely helpful. - Changed the caret in template instaniations from the class/struct name to the class/struct keyword, matching the other warnings. - Do not offer fix-it hints when multiple declarations disagree. Warnings are still given. - Once a definition is found, offer a fix-it hint to all previous declarations with wrong tag. - Declarations that disagree with a previous definition will get a fix-it hint to change the declaration. llvm-svn: 132831
* Add an assertion to tell us when we're going off the deep end tryingDouglas Gregor2011-05-221-2/+6
| | | | | | | | to determine outer template arguments lists for template parameters. This is actually the problem behind PR9643, which I have yet to figure out how to fix. llvm-svn: 131822
* When determining whether we need to instantiate a function type,Douglas Gregor2011-05-091-0/+6
| | | | | | | also consider whether any of the parameter types (as written, prior to decay) are dependent. Fixes PR9880 and <rdar://problem/9408413>. llvm-svn: 131099
* Modify some deleted function methods to better reflect reality:Alexis Hunt2011-05-061-2/+2
| | | | | | | | | | | | | | | | | | | | - New isDefined() function checks for deletedness - isThisDeclarationADefinition checks for deletedness - New doesThisDeclarationHaveABody() does what isThisDeclarationADefinition() used to do - The IsDeleted bit is not propagated across redeclarations - isDeleted() now checks the canoncial declaration - New isDeletedAsWritten() does what it says on the tin. - isUserProvided() now correct (thanks Richard!) This fixes the bug that we weren't catching void foo() = delete; void foo() {} as being a redefinition. llvm-svn: 131013
* Implement support for C++0x alias templates.Richard Smith2011-05-051-4/+8
| | | | llvm-svn: 130953
* Store a parameter index and function prototype depth in everyJohn McCall2011-05-011-1/+7
| | | | | | | | | | parameter node and use this to correctly mangle parameter references in function template signatures. A follow-up patch will improve the storage usage of these fields; here I've just done the lazy thing. llvm-svn: 130669
* Re-applies the patch first applied way back in r106099, withChandler Carruth2011-05-011-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | accompanying fixes to make it work today. The core of this patch is to provide a link from a TemplateTypeParmType back to the TemplateTypeParmDecl node which declared it. This in turn provides much more precise information about the type, where it came from, and how it functions for AST consumers. To make the patch work almost a year after its first attempt, it needed serialization support, and it now retains the old getName() interface. Finally, it requires us to not attempt to instantiate the type in an unsupported friend decl -- specifically those coming from template friend decls but which refer to a specific type through a dependent name. A cleaner representation of the last item would be to build FriendTemplateDecl nodes for these, storing their template parameters etc, and to perform proper instantation of them like any other template declaration. They can still be flagged as unsupported for the purpose of access checking, etc. This passed an asserts-enabled bootstrap for me, and the reduced test case mentioned in the original review thread no longer causes issues, likely fixed at somewhere amidst the 24k revisions that have elapsed. llvm-svn: 130628
* Diagnose attempts to implicitly instantiate a template before it isJohn McCall2011-04-271-2/+11
| | | | | | fully defined. Somehow this escaped notice for a very long time. llvm-svn: 130298
* Fixed source range for all DeclaratorDecl's.Abramo Bagnara2011-03-081-7/+10
| | | | llvm-svn: 127225
* When substituting in for a template name, do not produce a qualifiedDouglas Gregor2011-03-051-0/+7
| | | | | | | | | | | template name as the result of substitution. The qualifier is handled separately by the tree transformer, so we would end up in an inconsistent state. This is actually the last bit of PR9016, and possibly also fixes PR8965. It takes Boost.Icl from "epic fail" down to a single failure. llvm-svn: 127108
* When determining template instantiation arguments within a functionDouglas Gregor2011-03-051-0/+6
| | | | | | | | | | | template (not a specialization!), use the "injected" function template arguments, which correspond to the template parameters of the function template. This is required when substituting into the default template parameters of template template parameters within a function template. Fixes PR9016. llvm-svn: 127092
* Kill off TreeTransform::TransformNestedNameSpecifier() in favor of theDouglas Gregor2011-03-021-10/+0
| | | | | | | | source-location-preserving TreeTransform::TranformNestedNameSpecifierLoc(). No functionality change: the victim had no callers (that themselves had callers) anyway. llvm-svn: 126853
* Kill off the TreeTransform::TransformTemplateName overload that hasDouglas Gregor2011-03-021-60/+5
| | | | | | poor source-location information. llvm-svn: 126852
* Start migrating TreeTransform's TransformTemplateName over to versionDouglas Gregor2011-03-021-0/+62
| | | | | | | that preserve source-location information. This commit adds more redundancy than it removes; WIP. llvm-svn: 126849
* When we're substituting into a parameter-type-list nested inside the patternDouglas Gregor2011-03-021-5/+11
| | | | | | | | of an expansion, and we have a paramameter that is not a parameter pack, don't suppress substitution of parameter packs within this context. llvm-svn: 126819
* Reinstate the introduction of source-location information forDouglas Gregor2011-03-011-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | nested-name-speciciers within elaborated type names, e.g., enum clang::NestedNameSpecifier::SpecifierKind Fixes in this iteration include: (1) Compute the type-source range properly for a dependent template specialization type that starts with "template template-id ::", as in a member access expression dep->template f<T>::f() This is a latent bug I triggered with this change (because now we're checking the computed source ranges for dependent template specialization types). But the real problem was... (2) Make sure to set the qualifier range on a dependent template specialization type appropriately. This will go away once we push nested-name-specifier locations into dependent template specialization types, but it was the source of the valgrind errors on the buildbots. llvm-svn: 126765
OpenPOWER on IntegriCloud