summaryrefslogtreecommitdiffstats
path: root/clang/test/CXX/temp
Commit message (Collapse)AuthorAgeFilesLines
...
* Diagnose the various invalid decl-specifiers on nontype template parameters.Faisal Vali2017-12-221-3/+28
| | | | | | | | | | | | | The standard correctly forbids various decl-specifiers that dont make sense on non-type template parameters - such as the extern in: template<extern int> struct X; This patch implements those restrictions (in a fashion similar to the corresponding checks on function parameters within ActOnParamDeclarator). Credit goes to miyuki (Mikhail Maltsev) for drawing attention to this issue, authoring the initial versions of this patch, and supporting the effort to re-engineer it slightly. Thank you! For details of how this patch evolved please see: https://reviews.llvm.org/D40705 llvm-svn: 321339
* Do not look through pack expansions when looking for unexpanded parameter packs.Richard Smith2017-08-151-0/+98
| | | | | | | Fixes a selection of rejects-valids when pack-expanding a lambda that itself contains a pack expansion. llvm-svn: 310972
* When determining the target function of an explicit instantiation, makeJohn McCall2017-06-071-0/+13
| | | | | | | | | | sure that non-template functions don't end up in the candidate set. Fixes PR14211. Patch by Don Hinton! llvm-svn: 304951
* [c++1z] Support deducing B in noexcept(B).Richard Smith2017-06-071-4/+5
| | | | | | | | This is not required by the standard (yet), but there seems to be reasonable support for this being a defect according to CWG discussion, and libstdc++ 7.1 relies on it working. llvm-svn: 304946
* [c++1z] Add some more tests for class template argument deduction, addRichard Smith2017-02-141-0/+17
| | | | | | feature-test macro, and mark feature as done on status page. llvm-svn: 295011
* [c++1z] Synthesize implicit deduction guides from constructors on demand. RankRichard Smith2017-02-141-3/+33
| | | | | | | | | | | | | | | | | | | such guides below explicit ones, and ensure that references to the class's template parameters are not treated as forwarding references. We make a few tweaks to the wording in the current standard: 1) The constructor parameter list is copied faithfully to the deduction guide, without losing default arguments or a varargs ellipsis (which the standard wording loses by omission). 2) If the class template declares no constructors, we add a T() -> T<...> guide (which will only ever work if T has default arguments for all non-pack template parameters). 3) If the class template declares nothing that looks like a copy or move constructor, we add a T(T<...>) -> T<...> guide. #2 and #3 follow from the "pretend we had a class type with these constructors" philosophy for deduction guides. llvm-svn: 295007
* [c++1z] Enforce restriction that deduction guide is declared in the same ↵Richard Smith2017-02-101-10/+10
| | | | | | scope as its template. llvm-svn: 294778
* [c++1z] Disallow deduction guides with deduced types that don't ↵Richard Smith2017-02-101-5/+3
| | | | | | syntactically match the template being deduced. llvm-svn: 294773
* Disallow explicit instantiation and explicit specialization for deduction ↵Richard Smith2017-02-091-0/+20
| | | | | | guides. llvm-svn: 294641
* [c++1z] P0091R3: Basic support for deducing class template arguments via ↵Richard Smith2017-02-091-1/+2
| | | | | | deduction-guides. llvm-svn: 294613
* Diagnose an attempt to give a deduction-guide a function body.Richard Smith2017-02-081-5/+5
| | | | llvm-svn: 294397
* Fix constructor declarator detection for the case when the name is followed byRichard Smith2017-02-081-1/+1
| | | | | | an attribute-specifier-seq. (Also fixes the same problem for deduction-guides.) llvm-svn: 294396
* P0091R3: Improved syntactic checking of deduction-guides.Richard Smith2017-02-081-10/+25
| | | | llvm-svn: 294395
* P0091R3: Implement basic parsing support for C++17 deduction-guides.Richard Smith2017-02-073-0/+161
| | | | | | | | | | | We model deduction-guides as functions with a new kind of name that identifies the template whose deduction they guide; the bulk of this patch is adding the new name kind. This gives us a clean way to attach an extensible list of guides to a class template in a way that doesn't require any special handling in AST files etc (and we're going to need these functions we come to performing deduction). llvm-svn: 294266
* Repoint 'missing typename' diagnostic to the location where 'typename' ↵Richard Smith2017-02-011-1/+2
| | | | | | should be added. llvm-svn: 293817
* Fix hole in our enforcement of rule requiring 'typename' prior to a dependentRichard Smith2017-02-012-1/+38
| | | | | | | | | | | name. If the dependent name happened to end in a template-id (X<T>::Y<U>), we would fail to notice that the 'typename' keyword is missing when resolving it to a type. It turns out that GCC has a similar bug. If this shows up in much real code, we can easily downgrade this to an ExtWarn. llvm-svn: 293815
* PR9551: Implement DR1004 (http://wg21.link/cwg1004).Richard Smith2017-01-181-7/+50
| | | | | | | | This rule permits the injected-class-name of a class template to be used as both a template type argument and a template template argument, with no extra syntax required to disambiguate. llvm-svn: 292426
* Give more accurate descriptions of what kind of template we found in ↵Richard Smith2017-01-141-1/+1
| | | | | | | | | diagnostics. We were previouly assuming that every type template was a class template, which is not true any more. llvm-svn: 291988
* Implement DR1388 (wg21.link/cwg1388).Richard Smith2017-01-091-5/+8
| | | | | | | | | | | | This issue clarifies how deduction proceeds past a non-trailing function parameter pack. Essentially, the pack itself is skipped and consumes no arguments (except for those implied by an explicitly-specified template arguments), and nothing is deduced from it. As a small fix to the standard's rule, we do not allow subsequent deduction to change the length of the function parameter pack (by preventing extension of the explicitly-specified pack if present, and otherwise deducing all contained packs to empty packs). llvm-svn: 291425
* PR23135: Don't instantiate constexpr functions referenced in unevaluated ↵Richard Smith2017-01-071-5/+5
| | | | | | | | | | | | | | | | | | | | | operands where possible. This implements something like the current direction of DR1581: we use a narrow syntactic check to determine the set of places where a constant expression could be evaluated, and only instantiate a constexpr function or variable if it's referenced in one of those contexts, or is odr-used. It's not yet clear whether this is the right set of syntactic locations; we currently consider all contexts within templates that would result in odr-uses after instantiation, and contexts within list-initialization (narrowing conversions take another victim...), as requiring instantiation. We could in principle restrict the former cases more (only const integral / reference variable initializers, and contexts in which a constant expression is required, perhaps). However, this is sufficient to allow us to accept libstdc++ code, which relies on GCC's behavior (which appears to be somewhat similar to this approach). llvm-svn: 291318
* DR1315: a non-type template argument in a partial specialization is permittedRichard Smith2016-12-283-12/+16
| | | | | | | | | | to make reference to template parameters. This is only a partial implementation; we retain the restriction that the argument must not be type-dependent, since it's unclear how that would work given the existence of other language rules requiring an exact type match in this context, even for type-dependent cases (a question has been raised on the core reflector). llvm-svn: 290647
* DR1495: A partial specialization is ill-formed if it is not (strictly) moreRichard Smith2016-12-271-2/+2
| | | | | | | | specialized than the primary template. (Put another way, if we imagine there were a partial specialization matching the primary template, we should never select it if some other partial specialization also matches.) llvm-svn: 290593
* When producing a name of a partial specialization in a diagnostic, use theRichard Smith2016-12-241-4/+4
| | | | | | | template arguments as written rather than the canonical template arguments, so we print more user-friendly names for template parameters. llvm-svn: 290483
* When merging two deduced non-type template arguments for the same parameter,Richard Smith2016-12-231-1/+4
| | | | | | | | | | | | | | | | | | | fail the merge if the arguments have different types (except if one of them was deduced from an array bound, in which case take the type from the other). This is correct because (except in the array bound case) the type of the template argument in each deduction must match the type of the parameter, so at least one of the two deduced arguments must have a mismatched type. This is necessary because we would otherwise lose the type information for the discarded template argument in the merge, and fail to diagnose the mismatch. In order to power this, we now properly retain the type of a deduced non-type template argument deduced from a declaration, rather than giving it the type of the template parameter; we'll convert it to the template parameter type when checking the deduced arguments. llvm-svn: 290399
* Make '-disable-llvm-optzns' an alias for '-disable-llvm-passes'.Chandler Carruth2016-12-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Much to my surprise, '-disable-llvm-optzns' which I thought was the magical flag I wanted to get at the raw LLVM IR coming out of Clang deosn't do that. It still runs some passes over the IR. I don't want that, I really want the *raw* IR coming out of Clang and I strongly suspect everyone else using it is in the same camp. There is actually a flag that does what I want that I didn't know about called '-disable-llvm-passes'. I suspect many others don't know about it either. It both does what I want and is much simpler. This removes the confusing version and makes that spelling of the flag an alias for '-disable-llvm-passes'. I've also moved everything in Clang to use the 'passes' spelling as it seems both more accurate (*all* LLVM passes are disabled, not just optimizations) and much easier to remember and spell correctly. This is part of simplifying how Clang drives LLVM to make it cleaner to wire up to the new pass manager. Differential Revision: https://reviews.llvm.org/D28047 llvm-svn: 290392
* Improve error message when referencing a non-tag type with a tagReid Kleckner2016-12-092-2/+2
| | | | | | | | | | | | | | | | | | | | Other compilers accept invalid code here that we reject, and we need a better error message to try to convince users that the code is really incorrect. Consider: class Foo { typedef MyIterHelper<Foo> iterator; friend class iterator; }; Previously our wording was "elaborated type refers to a typedef". "elaborated type" isn't widely known terminology, so the new diagnostic says "typedef 'iterator' cannot be referenced with class specifier". Reviewers: rsmith Differential Revision: https://reviews.llvm.org/D25216 llvm-svn: 289259
* [c++1z] P0012R1: Implement a few remaining pieces: downgrade diagnostic forRichard Smith2016-10-222-5/+33
| | | | | | | | | | | | | | mismatched dynamic exception specifications in expressions from an error to a warning, since this is no longer ill-formed in C++1z. Allow reference binding of a reference-to-non-noexcept function to a noexcept function lvalue. As defect resolutions, also allow a conditional between noexcept and non-noexcept function lvalues to produce a non-noexcept function lvalue (rather than decaying to a function pointer), and allow function template argument deduction to deduce a reference to non-noexcept function when binding to a noexcept function type. llvm-svn: 284905
* P0012R1: Make exception specifications be part of the type system. ThisRichard Smith2016-10-162-1/+69
| | | | | | | implements the bulk of the change (modifying the type system to include exception specifications), but not all the details just yet. llvm-svn: 284337
* Extend this test and make it a bit clearer which cases Clang is getting wrong.Richard Smith2016-10-161-14/+34
| | | | llvm-svn: 284331
* Fix all tests under test/CXX (and test/Analysis) to pass if clang's defaultRichard Smith2016-08-313-36/+92
| | | | | | C++ language standard is not C++98. llvm-svn: 280309
* DR259: Demote the pedantic error for an explicit instantiation after anRichard Smith2016-08-312-17/+18
| | | | | | | | | explicit specialization to a warning for C++98 mode (this is a defect report resolution, so per our informal policy it should apply in C++98), and turn the warning on by default for C++11 and later. In all cases where it fires, the right thing to do is to remove the pointless explicit instantiation. llvm-svn: 280308
* Push alias-declarations and alias-template declarations into scope even ifRichard Smith2016-07-151-1/+1
| | | | | | | | they're redeclarations. This is necessary in order for name lookup to correctly find the most recent declaration of the name (which affects default template argument lookup and cross-module merging, among other things). llvm-svn: 275612
* [Sema] Fix a bug where pack expansion was not expanded in type aliasErik Pilkington2016-07-051-0/+32
| | | | | | | | | | The problem is that the parameter pack in a function type type alias is not reexpanded after being transformed. Also remove an incorrect comment in a similar function. Fixes PR26017. Differential Revision: http://reviews.llvm.org/D21030 llvm-svn: 274566
* [Sema] Disallow ambigious base classes in template argument deductionErik Pilkington2016-06-281-0/+13
| | | | | | | | Fixes PR28195. Differential revision: http://reviews.llvm.org/D21653 llvm-svn: 274077
* Implement C++17 P0386R2, inline variables. (The 'inline' specifier gives aRichard Smith2016-06-251-0/+10
| | | | | | | variable weak discardable linkage and partially-ordered initialization, and is implied for constexpr static data members.) llvm-svn: 273754
* Fix recognition of shadowed template parameterSerge Pavlov2016-06-101-5/+16
| | | | | | | | | | | | | | | | | | | | | | | Crash reported in PR28023 is caused by the fact that non-type template parameters are found by tag name lookup. In the code provided in that PR: template<int V> struct A { struct B { template <int> friend struct V; }; }; the template parameter V is found when lookup for redeclarations of 'struct V' is made. Latter on the error about shadowing of 'V' is emitted but the semantic context of 'struct V' is already determined wrong: 'struct A' instead of translation unit. The fix moves the check for shadowing toward the beginning of the method and thus prevents from wrong context calculations. This change fixes PR28023. llvm-svn: 272366
* [Parser] Clear the TemplateParamScope bit of the current scope's flagAkira Hatanaka2016-04-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | if we are parsing a template specialization. This commit makes changes to clear the TemplateParamScope bit and set the TemplateParamParent field of the current scope to null if a template specialization is being parsed. Before this commit, Sema::ActOnStartOfLambdaDefinition would check whether the parent template scope had any decls to determine whether or not a template specialization was being parsed. This wasn't correct since it couldn't distinguish between a real template specialization and a template defintion with an unnamed template parameter (only template parameters with names are added to the scope's decl list). To fix the bug, this commit changes the code to check the pointer to the parent template scope rather than the decl list. rdar://problem/23440346 Differential Revision: http://reviews.llvm.org/D19175 llvm-svn: 267975
* When deducing template parameters from base classes of an argument type, don'tRichard Smith2016-04-251-0/+14
| | | | | | | preserve any deduced types from a failed deduction to a subsequent attempt at deduction. Patch by Erik Pilkington! llvm-svn: 267444
* Warn if function or variable cannot be implicitly instantiatedSerge Pavlov2016-04-191-0/+1
| | | | | | | | | | | | With this patch compiler emits warning if it tries to make implicit instantiation of a template but cannot find the template definition. The warning can be suppressed by explicit instantiation declaration or by command line options -Wundefined-var-template and -Wundefined-func-template. The implementation follows the discussion of http://reviews.llvm.org/D12326. Differential Revision: http://reviews.llvm.org/D16396 llvm-svn: 266719
* Lit C++11 Compatibility Patch #8Charles Li2016-04-144-33/+205
| | | | | | 24 tests have been updated for C++11 compatibility. llvm-svn: 266387
* Lit C++11 Compatibility Patch #7Charles Li2016-04-134-22/+94
| | | | | | | 13 tests have been updated for C++11 compatibility. Differential Revision: http://reviews.llvm.org/D19068 llvm-svn: 266239
* Diagnose template alias declarations in local classes.Richard Smith2016-04-061-1/+3
| | | | | | Patch by Erik Pilkington! llvm-svn: 265571
* Ensure that we substitute into the declaration of a template parameter packRichard Smith2016-02-031-0/+22
| | | | | | | (that is not a pack expansion) during template argument deduction, even if we deduced that the pack would be empty. llvm-svn: 259688
* PR26048, PR26050: put non-type template parameters and indirect field declsRichard Smith2016-01-061-1/+66
| | | | | | | | into IDNS_Tag in C++, because they conflict with redeclarations of tags. (This doesn't affect elaborated-type-specifier lookup, which looks for IDNS_Type in C++). llvm-svn: 256985
* Improve diagnostic for the case where a function template candidate is rejectedRichard Smith2015-12-312-2/+2
| | | | | | | | by overload resolution because deduction succeeds, but the substituted parameter type for some parameter (with deduced type) doesn't exactly match the corresponding adjusted argument type. llvm-svn: 256657
* PR25731: namespace alias declarations can appear at block scope; ensure that weRichard Smith2015-12-031-1/+6
| | | | | | | | | do scope-based lookup when looking for redeclarations of them. Add some related missing checks for the scope-based redeclaration lookup: properly filter the list of found declarations to match the scope, and diagnose shadowing of a template parameter name. llvm-svn: 254663
* [NFC] Change the evaluation context of a non-type default template argument ↵Faisal Vali2015-11-181-0/+14
| | | | | | | | | | | | | | | | from Unevaluated to ConstantEvaluated. This patch emits a more appropriate (but still noisy) diagnostic stream when a lambda-expression is encountered within a non-type default argument. For e.g. template<int N = ([] { return 5; }())> int f(); As opposed to complaining that a lambda expression is not allowed in an unevaluated operand, the patch complains about the lambda being forbidden in a constant expression context (which will be allowed in C++17 now that they have been accepted by EWG, unless of course CWG or national bodies (that have so far shown no signs of concern) rise in protest) As I start submitting patches for constexpr lambdas (http://wg21.link/P0170R0) under C++1z (OK'd by Richard Smith at Kona), this will be one less change to make. Thanks! llvm-svn: 253431
* [Lit Test] Updated 34 Lit tests to be C++11 compatible.Charles Li2015-11-174-0/+21
| | | | | | | Added expected diagnostics new to C++11. Expanded RUN line to: default, C++98/03 and C++11. llvm-svn: 253371
* Avoid duplicated diagnostic when lookup for a nested-name-specifier fails ↵Richard Smith2015-11-121-2/+1
| | | | | | due to ambiguity. llvm-svn: 252967
* [Lit Test] Updated 26 Lit tests to be C++11 compatible.Charles Li2015-11-111-3/+16
| | | | | | | Expected diagnostics have been expanded to vary by C++ dialect. RUN line has also been expanded to: default, C++98/03 and C++11. llvm-svn: 252785
OpenPOWER on IntegriCloud