summaryrefslogtreecommitdiffstats
path: root/clang/test/CXX/temp/temp.decls
Commit message (Collapse)AuthorAgeFilesLines
...
* Include the unexpanded packs in the initializer expression when checking aNick Lewycky2013-06-131-0/+11
| | | | | | pack expanded constructor initializer list. Fixes PR16303! llvm-svn: 183878
* The 'constexpr implies const' rule for non-static member functions is gone inRichard Smith2013-04-211-5/+5
| | | | | | | | | C++1y, so stop adding the 'const' there. Provide a compatibility warning for code relying on this in C++11, with a fix-it hint. Update our lazily-written tests to add the const, except for those ones which were testing our implementation of this rule. llvm-svn: 179969
* Refactor to call ActOnFinishFullExpr on every full expression. TeachRichard Smith2013-01-142-0/+18
| | | | | | | | ActOnFinishFullExpr that some of its checks only apply to discarded-value expressions. This adds missing checks for unexpanded variadic template parameter packs to a handful of constructs. llvm-svn: 172485
* Prior to adding the new "expected-no-diagnostics" directive to ↵Andy Gibbs2012-10-1918-0/+18
| | | | | | VerifyDiagnosticConsumer, make the necessary adjustment to 580 test-cases which will henceforth require this new directive. llvm-svn: 166280
* Fix a small FIXME involving template partial ordering andEli Friedman2012-09-191-0/+15
| | | | | | member function templates with an rvalue ref qualifier. llvm-svn: 164267
* Fix function template partial ordering rules for static vs. non-staticEli Friedman2012-09-192-0/+24
| | | | | | functions. llvm-svn: 164263
* PR13811: Add a FunctionParmPackExpr node to handle references to functionRichard Smith2012-09-121-0/+24
| | | | | | | parameter packs where the reference is not being expanded but the pack has been. Previously, Clang would segfault in such cases. llvm-svn: 163672
* 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
* PR13386: When matching up parameters between a function template declarationRichard Smith2012-07-181-0/+43
| | | | | | | | | | | 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
* Implement the last part of C++ [class.mem]p2, delaying the parsing ofDouglas Gregor2012-04-161-1/+1
| | | | | | | | | exception specifications on member functions until after the closing '}' for the containing class. This allows, for example, a member function to throw an instance of its own class. Fixes PR12564 and a fairly embarassing oversight in our C++98/03 support. llvm-svn: 154844
* Support for definitions of member enumerations of class templates outside theRichard Smith2012-03-231-0/+152
| | | | | | | class template's definition, and for explicit specializations of such enum members. llvm-svn: 153304
* PR11850 + duplicates: don't assume that a function parameter pack expansion isRichard Smith2012-03-131-0/+46
| | | | | | at the end of the parameter list. llvm-svn: 152618
* Improve diagnostics a bit for bad member initializers, and fix an obscure ↵Eli Friedman2012-02-221-0/+10
| | | | | | bug involving packs. Fixes PR12049. llvm-svn: 151130
* Represent C++ direct initializers as ParenListExprs before semantic analysisSebastian Redl2012-02-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* When a pack expansion occurs in the template argument list of an aliasDouglas Gregor2012-02-031-0/+7
| | | | | | | | template without a corresponding parameter pack, don't immediately substitute the alias template. This is under discussion in the C++ committee, and may become ill-formed, but for now we match GCC. llvm-svn: 149697
* Implement support for a pack expansion into a fixed-lengthDouglas Gregor2012-02-031-0/+120
| | | | | | | | | template. Such pack expansions can easily fail at template instantiation time, if the expanded parameter packs are of the wrong length. Fixes <rdar://problem/10040867>, PR9021, and the example that came up today at Going Native. llvm-svn: 149685
* Tweak the fix to PR8977: an empty expression-list represents value ↵Eli Friedman2012-01-051-1/+2
| | | | | | initialization, not default initialization. Fixes PR11712. llvm-svn: 147620
* Remove a non-gcc-compatible extension that would apply attributes on ↵Eli Friedman2011-12-171-2/+1
| | | | | | declarations without a declarator to structs. Add a warning for ignored attributes. Patch by Michael Han. llvm-svn: 146796
* Fix grammar for C++11 alignment specifiers, and add a few FIXMEs.Peter Collingbourne2011-10-231-1/+2
| | | | llvm-svn: 142760
* Diagnose unexpanded parameter packs in member initialisers (includingPeter Collingbourne2011-10-231-0/+6
| | | | | | in-class member initialisers). llvm-svn: 142758
* Update all tests other than Driver/std.cpp to use -std=c++11 rather thanRichard Smith2011-10-1321-21/+21
| | | | | | -std=c++0x. Patch by Ahmed Charles! llvm-svn: 141900
* When we determine that a function template specialization produced asDouglas Gregor2011-10-121-2/+3
| | | | | | | | | | | | | | | part of template argument deduction is ill-formed, we mark it as invalid and treat it as a deduction failure. If we happen to find that specialization again, treat it as a deduction failure rather than silently building a call to the declaration. Fixes PR11117, a marvelous bug where deduction failed after creating an invalid specialization, causing overload resolution to pick a different candidate. Then we performed a similar overload resolution later, and happily picked the invalid specialization to call... resulting in a silent link failure. llvm-svn: 141809
* When substituting into a sizeof parameter pack expression in a contextDouglas Gregor2011-10-101-0/+15
| | | | | | | where we can't expand (i.e., multi-level substitution), be sure to substitute the pack with its level-reduced pack. Fixes PR10230. llvm-svn: 141568
* A friend template specialization is also dependent if any of itsDouglas Gregor2011-10-091-0/+24
| | | | | | template arguments are dependent. Fixes PR10913. llvm-svn: 141515
* Declare and define implicit move constructor and assignment operator.Sebastian Redl2011-08-301-0/+1
| | | | | | | | | This makes the code duplication of implicit special member handling even worse, but the cleanup will have to come later. For now, this works. Follow-up with tests for explicit defaulting and enabling the __has_feature flag to come. llvm-svn: 138821
* Diagnose unexpanded parameter packs in return statements. ThisDouglas Gregor2011-05-201-0/+7
| | | | | | | manifested in a crash with blocks in PR9953, but it was a ticking time bomb for normal functions, too. Fixes PR9953. llvm-svn: 131731
* Slight tweak to alias template error handling: don't guess that a ↵Richard Smith2011-05-051-2/+1
| | | | | | template-id in an alias declaration was meant to be a specialization. Use a generic, but more accurate, diagnostic. llvm-svn: 130961
* Implement support for C++0x alias templates.Richard Smith2011-05-054-0/+74
| | | | llvm-svn: 130953
* When parsing a template friend declaration we dropped the templateChandler Carruth2011-05-031-1/+1
| | | | | | | | | | | | | | | | | | | | parameters on the floor in certain cases: class X { template <typename T> friend typename A<T>::Foo; }; This was parsed as a *non* template friend declaration some how, and received an ExtWarn. Fixing the parser to actually provide the template parameters to the freestanding declaration parse triggers the code which specifically looks for such constructs and hard errors on them. Along the way, this prevents us from trying to instantiate constructs like the above inside of a outer template. This is important as loosing the template parameters means we don't have a well formed declaration and template instantiation will be unable to rebuild the AST. That fixes a crash in the GCC test suite. llvm-svn: 130772
* Add support for C++0x's range-based for loops, as specified by the C++11 ↵Richard Smith2011-04-141-0/+4
| | | | | | draft standard (N3291). llvm-svn: 129541
* Semantic checking for exception specifications should be triggered byJohn McCall2011-03-021-1/+1
| | | | | | whether C++ exceptions are enabled, not exceptions in general. PR9358. llvm-svn: 126820
* When we're substituting into a parameter-type-list nested inside the patternDouglas Gregor2011-03-021-0/+18
| | | | | | | | 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
* Add -fcxx-exceptions to all tests that use C++ exceptions.Anders Carlsson2011-02-281-1/+1
| | | | llvm-svn: 126599
* Pass -fexceptions to all tests that use try/catch/throw.Anders Carlsson2011-02-191-1/+1
| | | | llvm-svn: 126037
* When printing a qualified type, look through a substituted templateDouglas Gregor2011-02-171-1/+1
| | | | | | | | | | parameter type to see what's behind it, so that we don't end up printing silly things like "float const *" when "const float *" would make more sense. Also, replace the pile of "isa" tests with a simple switch enumerating all of the cases, making a few more obvious cases use prefix qualifiers. llvm-svn: 125729
* A member function template cannot be virtual.Anders Carlsson2011-01-221-0/+6
| | | | llvm-svn: 124031
* Implement basic support for the use of variadic templates and blocksDouglas Gregor2011-01-191-0/+39
| | | | | | | | | | | | | | | | | together. In particular: - Handle the use of captured parameter pack names within blocks (BlockDeclRefExpr understands parameter packs now) - Handle the declaration and expansion of parameter packs within a block's parameter list, e.g., ^(Args ...args) { ... }) - Handle instantiation of blocks where the return type was not explicitly specified. (unrelated, but necessary for my tests). Together, these fixes should make blocks and variadic templates work reasonably well together. Note that BlockDeclRefExpr is still broken w.r.t. its computation of type and value dependence, which will still cause problems for blocks in templates. llvm-svn: 123849
* Implement support for non-type template parameter packs whose type isDouglas Gregor2011-01-191-2/+42
| | | | | | | | | | | | | | | | | | | | | a pack expansion, e.g., the parameter pack Values in: template<typename ...Types> struct Outer { template<Types ...Values> struct Inner; }; This new implementation approach introduces the notion of an "expanded" non-type template parameter pack, for which we have already expanded the types of the parameter pack (to, say, "int*, float*", for Outer<int*, float*>) but have not yet expanded the values. Aside from creating these expanded non-type template parameter packs, this patch updates template argument checking and non-type template parameter pack instantiation to make use of the appropriate types in the parameter pack. llvm-svn: 123845
* Tweak the partial ordering rules for function templates to prefer aDouglas Gregor2011-01-161-5/+3
| | | | | | | | non-variadic function template over a variadic one. This matches GCC and the intent of the C++0x wording, in a way that I think is likely to be acceptable to the committee. llvm-svn: 123581
* Introduce a new kind of TemplateName that captures a substitutedDouglas Gregor2011-01-151-0/+26
| | | | | | | | | | | | | | | template template parameter pack that cannot be fully expanded because its enclosing pack expansion could not be expanded. This form of TemplateName plays the same role as SubstTemplateTypeParmPackType and SubstNonTypeTemplateParmPackExpr do for template type parameter packs and non-type template parameter packs, respectively. We should now handle these multi-level pack expansion substitutions anywhere. The largest remaining gap in our variadic-templates support is that we cannot cope with non-type template parameter packs whose type is a pack expansion. llvm-svn: 123521
* Introduce a new expression kind, SubstNonTypeTemplateParmPackExpr,Douglas Gregor2011-01-151-0/+23
| | | | | | | | | that captures the substitution of a non-type template argument pack for a non-type template parameter pack within a pack expansion that cannot be fully expanded. This follows the approach taken by SubstTemplateTypeParmPackType. llvm-svn: 123506
* Teach template template argument pack expansions to keep track of theDouglas Gregor2011-01-141-0/+38
| | | | | | | number of expansions, when we know it, and propagate that information through Sema. llvm-svn: 123493
* Handle substitutions into function parameter packs whose patternsDouglas Gregor2011-01-141-0/+22
| | | | | | contain multiple parameter packs at different levels. llvm-svn: 123488
* Teach PackExpansionExpr to keep track of the number of pack expansionsDouglas Gregor2011-01-141-0/+29
| | | | | | it will expand to, if known. Propagate this information throughout Sema. llvm-svn: 123470
* When we're instantiating a direct variable initializer that has a packDouglas Gregor2011-01-141-0/+9
| | | | | | | | expansion in it, we may end up instantiating to an empty expression-list. In this case, the variable is uninitialized; tweak the instantiation logic to handle this case. Fixes PR8977. llvm-svn: 123449
* Keep track of the number of expansions to be produced from a type packDouglas Gregor2011-01-141-3/+10
| | | | | | | | | | | | | | | | | | | | | | | expansion, when it is known due to the substitution of an out parameter pack. This allows us to properly handle substitution into pack expansions that involve multiple parameter packs at different template parameter levels, even when this substitution happens one level at a time (as with partial specializations of member class templates and the signatures of member function templates). Note that the diagnostic we provide when there is an arity mismatch between an outer parameter pack and an inner parameter pack in this case isn't as clear as the normal diagnostic for an arity mismatch. However, this doesn't matter because these cases are very, very rare and (even then) only typically occur in a SFINAE context. The other kinds of pack expansions (expression, template, etc.) still need to support optional tracking of the number of expansions, and we need the moral equivalent of SubstTemplateTypeParmPackType for substituted argument packs of template template and non-type template parameters. llvm-svn: 123448
* Start implementing support for substitution into pack expansions thatDouglas Gregor2011-01-141-0/+20
| | | | | | | | | | | | | | | | | involve template parameter packs at multiple template levels that occur within the signatures members of class templates (and partial specializations thereof). This is a work-in-progress that is deficient in several ways, notably: - It only works for template type parameter packs, but we need to also support non-type template parameter packs and template template parameter packs. - It doesn't keep track of the lengths of the substituted argument packs in the expansion, so it can't properly diagnose length mismatches. However, this is a concrete step in the right direction. llvm-svn: 123425
* Only apply the parameter pack matching of C++0x [temp.arg.template]p3Douglas Gregor2011-01-131-0/+16
| | | | | | | | | when we're actually matching a template template argument to a template template parameter. Otherwise, use strict matching. Fixes <rdar://problem/8859985> clang++: variadics and out-of-line definitions. llvm-svn: 123385
* Allow us to transform pack expansion expressions.Douglas Gregor2011-01-131-0/+16
| | | | llvm-svn: 123349
* Implement C++0x [temp.arg.template]p3, which allows slightly fuzzyDouglas Gregor2011-01-131-0/+17
| | | | | | | | matching of variadic template template parameters to template arguments. This paragraph was the subject of ISO C++ committee document N2555: Extending Variadic Template Template Parameters. llvm-svn: 123348
OpenPOWER on IntegriCloud