summaryrefslogtreecommitdiffstats
path: root/clang/test/SemaTemplate
Commit message (Collapse)AuthorAgeFilesLines
* Don't try to check implicit conversion sequences for an object argument ifRichard Smith2017-01-101-3/+14
| | | | | | | there is no object argument, when early checking of implicit conversion sequences for a function template fails. llvm-svn: 291597
* Fix conversion index / argument index mismatch when diagnosing overload ↵Richard Smith2017-01-101-0/+6
| | | | | | resolution failure. llvm-svn: 291596
* Check that template template arguments match template template parametersRichard Smith2017-01-092-6/+29
| | | | | | | | | | | | | | | properly even when a non-type template parameter has a dependent type. Previously, if a non-type template parameter was dependent, but not dependent on an outer level of template parameter, we would not match the type of the parameter. Under [temp.arg.template], we are supposed to check that the types are equivalent, which means checking for syntactic equivalence in the dependent case. This also fixes some accepts-invalids when passing templates with auto-typed non-type template parameters as template template arguments. llvm-svn: 291512
* Implement C++ DR1391 (wg21.link/cwg1391)Richard Smith2017-01-092-2/+10
| | | | | | | | | | | | | | Check for implicit conversion sequences for non-dependent function template parameters between deduction and substitution. The idea is to accept as many cases as possible, on the basis that substitution failure outside the immediate context is much more common during substitution than during implicit conversion sequence formation. This re-commits r290808, reverted in r290811 and r291412, with a couple of fixes for handling of explicitly-specified non-trailing template argument packs. llvm-svn: 291427
* Implement DR1388 (wg21.link/cwg1388).Richard Smith2017-01-091-3/+21
| | | | | | | | | | | | 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
* Revert r291410 and r291411.Richard Smith2017-01-091-6/+2
| | | | | | The test-suite bots are still failing even after r291410's fix. llvm-svn: 291412
* Implement C++ DR1391 (wg21.link/cwg1391)Richard Smith2017-01-091-2/+6
| | | | | | | | | | | | | Check for implicit conversion sequences for non-dependent function template parameters between deduction and substitution. The idea is to accept as many cases as possible, on the basis that substitution failure outside the immediate context is much more common during substitution than during implicit conversion sequence formation. This re-commits r290808, reverted in r290811, with a fix for handling of explicitly-specified template argument packs. llvm-svn: 291410
* PR31514: Add recursive self-instantiation check during template argumentRichard Smith2017-01-082-1/+11
| | | | | | | | | | | deduction in partial ordering. This prevents us from crashing due to attempting to instantiate the same class template specialization definition multiple times. (Debug builds also appear to sometimes hit the stack limit before hitting the instantiation depth limit in this case.) llvm-svn: 291407
* PR20090: Add (passing) test from this bug; it's been fixed for a while.Richard Smith2017-01-071-0/+7
| | | | llvm-svn: 291319
* PR23135: Don't instantiate constexpr functions referenced in unevaluated ↵Richard Smith2017-01-073-22/+67
| | | | | | | | | | | | | | | | | | | | | 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
* If an explicitly-specified pack might have been extended by template argumentRichard Smith2017-01-051-0/+14
| | | | | | deduction, don't forget to check the argument is valid. llvm-svn: 291170
* Per [temp.deduct.call], do not deduce an array bound of 0 from an empty ↵Richard Smith2017-01-051-0/+14
| | | | | | initializer list. llvm-svn: 291075
* Fix assertion failure on deduction failure due to too short template ↵Richard Smith2017-01-051-0/+7
| | | | | | | | | | | | argument list. We were previously incorrectly using TDK_TooFewArguments to report a template argument list that's too short, but it actually means that the number of arguments in a top-level function call was insufficient. When diagnosing the problem, SemaOverload would (rightly) assert that the failure kind didn't make any sense. llvm-svn: 291064
* Only instantiate members of nested classes in local classes once, rather ↵Richard Smith2017-01-041-0/+11
| | | | | | than once per enclosing class. llvm-svn: 291034
* Remove accidentally-added lines in r290923 test, and add another testcase.Richard Smith2017-01-041-2/+9
| | | | llvm-svn: 290926
* Fix template argument deduction when only some of a parameter pack is a ↵Richard Smith2017-01-041-0/+38
| | | | | | | | | | | | | | | | | non-deduced context. When a parameter pack has multiple corresponding arguments, and some subset of them are overloaded functions, it's possible that some subset of the parameters are non-deduced contexts. In such a case, keep deducing from the remainder of the arguments, and resolve the incomplete pack against whatever other deductions we've performed for the pack. GCC, MSVC, and ICC give three different bad behaviors for this case; what we do now (and what we did before) don't exactly match any of them, sadly :( I'm getting a core issue opened to specify more precisely how this should be handled. llvm-svn: 290923
* Add testcase for the regression introduced in r290808.Richard Smith2017-01-021-0/+14
| | | | llvm-svn: 290843
* [c++17] Implement P0522R0 as written. This allows a template template argumentRichard Smith2016-12-312-1/+105
| | | | | | | | | | | | | | | | | | | to be specified for a template template parameter whenever the parameter is at least as specialized as the argument (when there's an obvious and correct mapping from uses of the parameter to uses of the argument). For example, a template with more parameters can be passed to a template template parameter with fewer, if those trailing parameters have default arguments. This is disabled by default, despite being a DR resolution, as it's fairly broken in its current state: there are no partial ordering rules to cope with template template parameters that have different parameter lists, meaning that code that attempts to decompose template-ids based on arity can hit unavoidable ambiguity issues. The diagnostics produced on a non-matching argument are also pretty bad right now, but I aim to improve them in a subsequent commit. llvm-svn: 290792
* Remove bogus assertion and add testcase that triggers it.Richard Smith2016-12-301-0/+17
| | | | llvm-svn: 290743
* Mark 'auto' as dependent when instantiating the type of a non-type templateRichard Smith2016-12-281-0/+21
| | | | | | | parameter. Fixes failed deduction for 'auto' non-type template parameters nested within templates. llvm-svn: 290660
* DR1315: a non-type template argument in a partial specialization is permittedRichard Smith2016-12-284-11/+41
| | | | | | | | | | 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-272-10/+39
| | | | | | | | 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
* Add reference/non-reference mismatch test.Richard Smith2016-12-271-1/+6
| | | | llvm-svn: 290587
* Work around a standard defect: template argument deduction for non-typeRichard Smith2016-12-272-0/+31
| | | | | | | | | template parameters of reference type basically doesn't work, because we're always deducing from an argument expression of non-reference type, so the type of the deduced expression never matches. Instead, compare the type of an expression naming the parameter to the type of the argument. llvm-svn: 290586
* Check and build conversion sequences for non-type template arguments inRichard Smith2016-12-272-1/+10
| | | | | | | dependent contexts when processing the template in C++11 and C++14, just like we do in C++98 and C++1z. This allows us to diagnose invalid templates earlier. llvm-svn: 290567
* Fix assertion failure when deducing an auto-typed argument against a ↵Richard Smith2016-12-251-0/+17
| | | | | | different-width int. llvm-svn: 290522
* Fix some subtle wrong partial ordering bugs particularly with C++1z auto-typedRichard Smith2016-12-252-3/+32
| | | | | | | | | | | | | | | | | | non-type template parameters. During partial ordering, when checking the substituted deduced template arguments match the original, check the types of non-type template arguments match even if they're dependent. The only way we get dependent types here is if they really represent types of the other template (which are supposed to be modeled as being substituted for unique, non-dependent types). In order to make this work for auto-typed non-type template arguments, we need to be able to perform auto deduction even when the initializer and (potentially) the auto type are dependent, support for which is the bulk of this patch. (Note that this requires the ability to deduce only a single level of a multi-level dependent type.) llvm-svn: 290511
* Fix crash if substitution fails during deduction of variable template ↵Richard Smith2016-12-241-6/+3
| | | | | | partial specialization arguments. llvm-svn: 290484
* When producing a name of a partial specialization in a diagnostic, use theRichard Smith2016-12-243-2/+17
| | | | | | | 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/+64
| | | | | | | | | | | | | | | | | | | 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
* Perform type-checking for a converted constant expression in a templateRichard Smith2016-12-211-2/+2
| | | | | | | | | | | argument even if the expression is value-dependent (we need to suppress the final portion of the narrowing check, but the rest of the checking can still be done eagerly). This affects template template argument validity and partial ordering under p0522r0. llvm-svn: 290276
* [c++1z] P0195R2: Support pack-expansion of using-declarations.Richard Smith2016-12-201-0/+230
| | | | | | | | | | | | | | This change introduces UsingPackDecl as a marker for the set of UsingDecls produced by pack expansion of a single (unresolved) using declaration. This is not strictly necessary (we just need to be able to map from the original using declaration to its expansions somehow), but it's useful to maintain the invariant that each declaration reference instantiates to refer to one declaration. This is a re-commit of r290080 (reverted in r290092) with a fix for a use-after-lifetime bug. llvm-svn: 290203
* Revert "[c++1z] P0195R2: Support pack-expansion of using-declarations."Daniel Jasper2016-12-191-230/+0
| | | | | | | This reverts commit r290080 as it leads to many Clang crashes, e.g.: http://lab.llvm.org:8011/builders/clang-cmake-aarch64-quick/builds/1814 llvm-svn: 290092
* [c++1z] P0195R2: Support pack-expansion of using-declarations.Richard Smith2016-12-191-0/+230
| | | | | | | | | | | This change introduces UsingPackDecl as a marker for the set of UsingDecls produced by pack expansion of a single (unresolved) using declaration. This is not strictly necessary (we just need to be able to map from the original using declaration to its expansions somehow), but it's useful to maintain the invariant that each declaration reference instantiates to refer to one declaration. llvm-svn: 290080
* Remove the temporary fix to the RUN line that was committed in r289924.Akira Hatanaka2016-12-161-5/+21
| | | | | | | Also, dump the AST and run FileCheck to make sure the expected nodes are created in the AST. llvm-svn: 289986
* attempt to fix bots after r289914/r289919Nico Weber2016-12-161-1/+5
| | | | llvm-svn: 289924
* Remove "-disable-llvm-optzns -verify" from the RUN line.Akira Hatanaka2016-12-161-1/+1
| | | | llvm-svn: 289919
* [Sema] Fix handling of enumerators used as default arguments of lambdaAkira Hatanaka2016-12-161-0/+35
| | | | | | | | | | | | | | | | | expressions in a function or class template. This patch makes the following changes: - Create a DependentScopeDeclRefExpr for the default argument instead of a CXXDependentScopeMemberExpr. - Pass CombineWithOuterScope=true so that the outer scope in which the enum is declared is searched for the instantiation of the enum. This is the first part of https://reviews.llvm.org/D23096. Fixes PR28795 rdar://problem/27535319 llvm-svn: 289914
* Improve error message when referencing a non-tag type with a tagReid Kleckner2016-12-091-1/+1
| | | | | | | | | | | | | | | | | | | | 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
* Make output of -ast-print a valid C++ code.Serge Pavlov2016-11-101-3/+3
| | | | | | | | | | | | | | | | | | Output generated by option -ast-print looks like C/C++ code, and it really is for plain C. For C++ the produced output was not valid C++ code, but the differences were small. With this change the output is fixed and can be compiled. Tests are changed so that output produced by -ast-print is compiled again with the same flags and both outputs are compared. Option -ast-print is extensively used in clang tests but it itself was tested poorly, existing tests only checked that compiler did not crash. There are unit tests in file DeclPrinterTest.cpp, but they test only terse output mode. Differential Revision: https://reviews.llvm.org/D26452 llvm-svn: 286439
* Add a note that points to the linkage specifier for the C++ linkage errorsAlex Lorenz2016-11-021-3/+3
| | | | | | | | | | | | This commit improves the "must have C++ linkage" error diagnostics that are emitted for C++ declarations like templates and literal operators by adding an additional note that points to the appropriate extern "C" linkage specifier. rdar://19021120 Differential Revision: https://reviews.llvm.org/D26189 llvm-svn: 285823
* Fix crash if StmtProfile finds a type-dependent member access for which we haveRichard Smith2016-10-241-0/+9
| | | | | | | | | | | resolved the -> to a call to a specific operator-> function. The particular test case added here is actually being mishandled: the implicit member access should not be type-dependent (because it's accessing a non-type-dependent member of the current instantiation), but calls to a type-dependent operator-> that is a member of the current instantiation would be liable to hit the same codepath. llvm-svn: 284999
* Add optimization to sizeof...(X) handling: if none of parameter pack X'sRichard Smith2016-10-191-0/+17
| | | | | | | | | | | | | | | | | | | | | corresponding arguments are unexpanded pack expansions, we can compute the result without substituting them. This significantly improves the memory usage and performance of make_integer_sequence implementations that do this kind of thing: using result = integer_sequence<T, Ns ..., sizeof...(Ns) + Ns ...>; ... but note that such an implementation will still perform O(sizeof...(Ns)^2) work while building the second pack expansion (we just have a somewhat lower constant now). In principle we could get this down to linear time by caching whether the number of expansions of a pack is constant, or checking whether we're within an alias template before scanning the pack for pack expansions (since that's the only case in which we do substitutions within a dependent context at the moment), but this patch doesn't attempt that. llvm-svn: 284653
* DR1330: instantiate exception-specifications when "needed". We previously didRichard Smith2016-10-181-11/+7
| | | | | | | | | | | | | | | | | | | | not instantiate exception specifications of functions if they were only used in unevaluated contexts (other than 'noexcept' expressions). In C++17 onwards, this becomes essential since the exception specification is now part of the function's type. Note that this means that constructs like the following no longer work: struct A { static T f() noexcept(...); decltype(f()) *p; }; ... because the decltype expression now needs the exception specification of 'f', which has not yet been parsed. llvm-svn: 284549
* P0127R2: Support type deduction for types of non-type template parameters inRichard Smith2016-09-282-0/+114
| | | | | | | | C++1z. Patch by James Touton! Some bugfixes and rebasing by me. llvm-svn: 282651
* Fix bug where template argument deduction of a non-type template parameter usedRichard Smith2016-09-282-2/+10
| | | | | | | | | as a template argument in a template-id, from a null non-type template argument, failed. Extracted from a patch by James Touton! llvm-svn: 282641
* [Sema] Don't diagnose an array type mismatch when the new or previousAkira Hatanaka2016-09-011-0/+33
| | | | | | | | | | | | declaration has a dependent type. This fixes a bug where clang errors out on a valid code. rdar://problem/28051467 Differential Revision: https://reviews.llvm.org/D24110 llvm-svn: 280330
* DR259: Demote the pedantic error for an explicit instantiation after anRichard Smith2016-08-311-1/+1
| | | | | | | | | 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
* PR12298 et al: don't recursively instantiate a template specialization fromRichard Smith2016-08-313-22/+105
| | | | | | | | | | | | | | | within the instantiation of that same specialization. This could previously happen for eagerly-instantiated function templates, variable templates, exception specifications, default arguments, and a handful of other cases. We still have an issue here for default template arguments that recursively make use of themselves and likewise for substitution into the type of a non-type template parameter, but in those cases we're producing a different entity each time, so they should instead be caught by the instantiation depth limit. However, currently we will typically run out of stack before we reach it. :( llvm-svn: 280190
* Disable clang/test/SemaTemplate/instantiation-depth-default.cpp temporarily ↵NAKAMURA Takumi2016-08-301-0/+3
| | | | | | for targeting mingw32. It crashes. Investigating. llvm-svn: 280104
OpenPOWER on IntegriCloud