summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Fixed instantiated operators source range.Abramo Bagnara2012-10-041-1/+1
| | | | llvm-svn: 165258
* Don't produce diagnostics for missing ctor-initializers during templateRichard Smith2012-09-251-1/+1
| | | | | | instantiations if we encountered errors parsing some of the initializers. llvm-svn: 164578
* Per C++11 [class.friend]p3, the 'friend' keyword must appear first in aRichard Smith2012-09-201-1/+1
| | | | | | non-function friend declaration. Patch by Josh Magee! llvm-svn: 164273
* Actually rebuild function types properly when adjusting the functionDouglas Gregor2012-09-131-4/+13
| | | | | | type of an instantiation. llvm-svn: 163848
* When we substitute into the type of a function based on theDouglas Gregor2012-09-131-2/+17
| | | | | | | | TypeSourceInfo, we may have lost some adjustments made to the type of that function due to declaration merging. Adjust the resulting type correspondingly. Fixes PR12948 / <rdar://problem/11552434>. llvm-svn: 163845
* PR13811: Add a FunctionParmPackExpr node to handle references to functionRichard Smith2012-09-121-1/+2
| | | | | | | parameter packs where the reference is not being expanded but the pack has been. Previously, Clang would segfault in such cases. llvm-svn: 163672
* PR9023: A template template parameter whose template parameter list contains anRichard Smith2012-09-071-7/+101
| | | | | | | | | | | | | unexpanded parameter pack is a pack expansion. Thus, as with a non-type template parameter which is a pack expansion, it needs to be expanded early into a fixed list of template parameters. Since the expanded list of template parameters is not itself a parameter pack, it is permitted to appear before the end of the template parameter list, so also remove that restriction (for both template template parameter pack expansions and non-type template parameter pack expansions). llvm-svn: 163369
* Do not add using directives to a function decl context when instantiating.Abramo Bagnara2012-09-051-1/+6
| | | | llvm-svn: 163208
* Remove ASTOwningVector, it doesn't own anything and provides no value over ↵Benjamin Kramer2012-08-231-1/+1
| | | | | | SmallVector. llvm-svn: 162492
* 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
* Check access to friend declarations. There's a number of differentJohn McCall2012-08-101-14/+34
| | | | | | | | | | | | | | 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/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* PR12917: Remove incorrect assumption that lambda mangling information cannotRichard Smith2012-07-221-2/+2
| | | | | | | | | | change once it's been assigned. It can change in two ways: 1) In a template instantiation, the context declaration should be the instantiated declaration, not the declaration in the template. 2) If a lambda appears in the pattern of a variadic pack expansion, the mangling number will depend on the pack length. llvm-svn: 160614
* PR13386: When matching up parameters between a function template declarationRichard Smith2012-07-181-24/+22
| | | | | | | | | | | and a function template instantiation, if there's a parameter pack in the declaration and one at the same place in the instantiation, don't assume that the pack wasn't expanded -- it may have expanded to nothing. Instead, go ahead and check whether the parameter pack was expandable. We can do this as a side-effect of the work we'd need to do anyway, to find how many parameters were produced. llvm-svn: 160416
* Fix rejects-valid: explicit specialization of redeclared deleted function ↵David Blaikie2012-07-161-1/+1
| | | | | | | | template. Review by Richard Smith. llvm-svn: 160306
* Stop instantiating a class if we hit a static_assert failure. Also, if theRichard Smith2012-07-111-5/+4
| | | | | | | static_assert fails when parsing the template, don't diagnose it again on every instantiation. llvm-svn: 160088
* PR9793: Treat substitution as an instantiation step for the purpose of theRichard Smith2012-07-081-1/+0
| | | | | | | | -ftemplate-depth limit. There are various ways to get an infinite (or merely huge) stack of substitutions with no intervening instantiations. This is also consistent with gcc's behavior. llvm-svn: 159907
* Make explicit specializations at class scope workNico Weber2012-06-251-2/+11
| | | | | | | for non-type template parameters in microsoft mode. PR12709. llvm-svn: 159147
* Reapplying the changes from r158717 as they were rolled back to avoid merge ↵Aaron Ballman2012-06-191-2/+4
| | | | | | conflicts from a separate problematic patch. llvm-svn: 158750
* Revert r158700 and dependent patches r158716, r158717, and r158731.Jakob Stoklund Olesen2012-06-191-4/+2
| | | | | | | | The original r158700 caused crashes in the gcc test suite, g++.abi/vtable3a.C among others. It also caused failures in the libc++ test suite. llvm-svn: 158749
* Improves parsing and semantic analysis for MS __declspec attributes. This ↵Aaron Ballman2012-06-191-2/+4
| | | | | | includes support for the align (which fixes PR12631). llvm-svn: 158717
* Documentation cleanup: fixing a typo from my previous 'fix'.James Dennett2012-06-171-1/+1
| | | | llvm-svn: 158617
* Documentation cleanup:James Dennett2012-06-151-2/+2
| | | | | | | | | * Escaped "::" and "<" as needed in Doxygen comments; * Marked up code examples with \code...\endcode; * Documented a \param that is current, instead of a few that aren't; * Fixed up some \file and \brief comments. llvm-svn: 158562
* Still more Doxygen documentation fixes:James Dennett2012-06-141-2/+2
| | | | | | | | * Escape #, < and @ symbols where Doxygen would try to interpret them; * Fix several function param documentation where names had got out of sync; * Delete param documentation referring to parameters that no longer exist. llvm-svn: 158472
* PR13064: Store whether an in-class initializer uses direct or copyRichard Smith2012-06-101-1/+1
| | | | | | | initialization, and use that information to produce the right kind of initialization during template instantiation. llvm-svn: 158288
* Revert Decl's iterators back to pointer value_type rather than reference ↵David Blaikie2012-06-061-2/+2
| | | | | | | | | | | | | | value_type In addition, I've made the pointer and reference typedef 'void' rather than T* just so they can't get misused. I would've omitted them entirely but std::distance likes them to be there even if it doesn't use them. This rolls back r155808 and r155869. Review by Doug Gregor incorporating feedback from Chandler Carruth. llvm-svn: 158104
* Correct the starting location for instantiations of field declarations whichRichard Smith2012-05-231-1/+1
| | | | | | | | | | | | | start with a cv-qualifier. DeclaratorDecl::getTypeSpecStartLoc() does not produce the location of the first type-specifier (the cv-qualifier) in this case, because we don't track source locations for cv-qualifiers. No test here: I've not found a way to test this with a lit-style test, and introducing a gtest test for this seems unwarranted. Suggestions welcome! Patch by Daniel Jasper! llvm-svn: 157311
* Fix our handling of visibility in explicit template instantiations.Rafael Espindola2012-05-151-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | * Don't copy the visibility attribute during instantiations. We have to be able to distinguish struct HIDDEN foo {}; template<class T> DEFAULT void bar() {} template DEFAULT void bar<foo>(); from struct HIDDEN foo {}; template<class T> DEFAULT void bar() {} template void bar<foo>(); * If an instantiation has an attribute, it takes precedence over an attribute in the template. * With instantiation attributes handled with the above logic, we can now select the minimum visibility when looking at template arguments. llvm-svn: 156821
* Move Sema::VerifyIntegerConstantExpression() andDouglas Gregor2012-05-041-3/+4
| | | | | | | | Sema::ConvertToIntegralOrEnumerationType() from PartialDiagnostics to abstract "diagnoser" classes. Not much of a win here, but we're -several PartialDiagnostics. llvm-svn: 156217
* Remove the ref/value inconsistency in filter_decl_iterator.David Blaikie2012-04-301-2/+2
| | | | | | | | | | | | | filter_decl_iterator had a weird mismatch where both op* and op-> returned T* making it difficult to generalize this filtering behavior into a reusable library of any kind. This change errs on the side of value, making op-> return T* and op* return T&. (reviewed by Richard Smith) llvm-svn: 155808
* PR 12586: Fix assert while running libc++ testsuite: deal with exceptionRichard Smith2012-04-191-17/+14
| | | | | | | | | specifications on member function templates of class templates and other such nested beasties. Store the function template from which we are to instantiate an exception specification rather than trying to deduce it. Plus some additional test cases. llvm-svn: 155076
* PR12569: Instantiate exception specifications of explicit instantiationsRichard Smith2012-04-171-1/+10
| | | | | | and explicit specializations of function templates appropriately. llvm-svn: 154956
* Implement DR1330 in C++11 mode, to support libstdc++4.7 which uses it.Richard Smith2012-04-171-151/+211
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-1/+26
| | | | | | | | | | | | | | | | | | | | | | | 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
* If something already instantiated is reinstantiated as an explicit definition,Nick Lewycky2012-04-041-1/+6
| | | | | | | | | keep the latter. No test. This was noticed when poking around something else with GDB. I'm not able to figure out a testcase that would break due to this bug. Sorry. llvm-svn: 153992
* Basic semantic analysis support for inheriting constructor declarations inRichard Smith2012-04-021-0/+6
| | | | | | dependent contexts. llvm-svn: 153858
* When we form a new function/class template specialization, we firstDouglas Gregor2012-03-281-5/+5
| | | | | | | | | | | search for the specialization (in a folding set) and, if not found form a *Decl that is then inserted into that folding set. In rare cases, the folding set may be reallocated between the search and the insertion, causing a crash. No test case, because triggering rehashing consistently in a small test case is not feasible. Fixes <rdar://problem/11115071>. llvm-svn: 153575
* Add a special-case diagnostic for one of the more obnoxious special cases ofRichard Smith2012-03-261-0/+14
| | | | | | | | | | | | | | | unscoped enumeration members: an enumerator name which is visible in the out-of-class definition of a member of a templated class might not actually exist in the instantiation of that class, if the enumeration is also lexically defined outside the class definition and is explicitly specialized. Depending on the result of a CWG discussion, we may have a different resolution for a class of problems in this area, but this fixes the immediate issue of a crash-on-invalid / accepts-invalid (depending on +Asserts). Thanks to Johannes Schaub for digging into the standard wording to find how this case is currently specified to behave. llvm-svn: 153461
* Handle instantiations of redeclarations of forward-declared enumerations withinRichard Smith2012-03-261-3/+15
| | | | | | | templated functions. Build a redeclaration chain, and only instantiate the definition of the enum when visiting the defining declaration. llvm-svn: 153427
* Delay checking of dependent underlying types for redeclarations of memberRichard Smith2012-03-261-5/+16
| | | | | | enumerations in templates until the template is instantiated. llvm-svn: 153426
* Support for definitions of member enumerations of class templates outside theRichard Smith2012-03-231-1/+4
| | | | | | | 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-20/+34
| | | | | | | | 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
* PR11850 + duplicates: don't assume that a function parameter pack expansion isRichard Smith2012-03-131-11/+14
| | | | | | at the end of the parameter list. llvm-svn: 152618
* Fix PR10447: lazily building name lookup tables for DeclContexts was broken.Richard Smith2012-03-131-2/+2
| | | | | | | | | | | | | | | | | | | | | | | The deferred lookup table building step couldn't accurately tell which Decls should be included in the lookup table, and consequently built different tables in some cases. Fix this by removing lazy building of DeclContext name lookup tables. In practice, the laziness was frequently not worthwhile in C++, because we performed lookup into most DeclContexts. In C, it had a bit more value, since there is no qualified lookup. In the place of lazy lookup table building, we simply don't build lookup tables for function DeclContexts at all. Such name lookup tables are not useful, since they don't capture the scoping information required to correctly perform name lookup in a function scope. The resulting performance delta is within the noise on my testing, but appears to be a very slight win for C++ and a very slight loss for C. The C performance can probably be recovered (if it is a measurable problem) by avoiding building the lookup table for the translation unit. llvm-svn: 152608
* Unify naming of LangOptions variable/get function across the Clang stack ↵David Blaikie2012-03-111-7/+7
| | | | | | | | | | (Lex to AST). The member variable is always "LangOpts" and the member function is always "getLangOpts". Reviewed by Chris Lattner llvm-svn: 152536
* Replace MarkVarRequired with a more genericRafael Espindola2012-03-081-4/+3
| | | | | | HandleCXXStaticMemberVarInstantiation. Suggested by Argyrios. llvm-svn: 152320
* Fix a small difference in sema and codegen views of what needs to be output.Rafael Espindola2012-03-051-4/+8
| | | | | | | | | | | | In the included testcase, soma thinks that we already have a definition after we see the out of line decl. Codegen puts it in a deferred list, to be output if a use is seen. This would break when we saw an explicit template instantiation definition, since codegen would not be notified. This patch adds a method to the consumer interface so that soma can notify codegen that this decl is now required. llvm-svn: 152024
* Lambda closure types are always considered to be like "local" classes,Douglas Gregor2012-02-161-3/+6
| | | | | | | | | even if they are not within a function scope. Teach template instantiation to treat them as such, and make sure that we have a local instantiation scope when instantiating default arguments and static data members. llvm-svn: 150725
* Minor fix to template instantiation, which properly instantiatesDeLesley Hutchins2012-02-161-1/+1
| | | | | | dependent attributes on static members of templatized classes. llvm-svn: 150704
* Update constexpr implementation to match CWG's chosen approach for core issuesRichard Smith2012-02-131-11/+4
| | | | | | | | | | | | | | | | | | | | 1358, 1360, 1452 and 1453. - Instantiations of constexpr functions are always constexpr. This removes the need for separate declaration/definition checking, which is now gone. - This makes it possible for a constexpr function to be virtual, if they are only dependently virtual. Virtual calls to such functions are not constant expressions. - Likewise, it's now possible for a literal type to have virtual base classes. A constexpr constructor for such a type cannot actually produce a constant expression, though, so add a special-case diagnostic for a constructor call to such a type rather than trying to evaluate it. - Classes with trivial default constructors (for which value initialization can produce a fully-initialized value) are considered literal types. - Classes with volatile members are not literal types. - constexpr constructors can be members of non-literal types. We do not yet use static initialization for global objects constructed in this way. llvm-svn: 150359
OpenPOWER on IntegriCloud