summaryrefslogtreecommitdiffstats
path: root/clang/test/SemaTemplate
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* Disable test under asan: it uses a lot of stack, and asan increases theRichard Smith2016-08-241-4/+9
| | | | | | | | per-frame stack usage enough to cause it to hit our stack limit. This is not ideal; we should find a better way of dealing with this, such as increasing our stack allocation when built with ASan. llvm-svn: 279668
* Add test missed from r278983.Richard Smith2016-08-171-0/+9
| | | | llvm-svn: 278984
* P0217R3: template instantiation support for decomposition declarations.Richard Smith2016-08-121-0/+33
| | | | llvm-svn: 278458
* Push alias-declarations and alias-template declarations into scope even ifRichard Smith2016-07-151-0/+6
| | | | | | | | 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
* Revert accidential "[MSVC] Late parsing of in-class defined member functions ↵Alexey Bataev2016-06-151-1/+0
| | | | | | | | in template" This reverts commit 0253605771b8bd9d414aba74fe2742c730d6fd1a. llvm-svn: 272776
* [MSVC] Late parsing of in-class defined member functions in templateAlexey Bataev2016-06-151-0/+1
| | | | | | | | | | | | | | | | | | | classes. MSVC actively uses unqualified lookup in dependent bases, lookup at the instantiation point (non-dependent names may be resolved on things declared later) etc. and all this stuff is the main cause of incompatibility between clang and MSVC. Clang tries to emulate MSVC behavior but it may fail in many cases. clang could store lexed tokens for member functions definitions within ClassTemplateDecl for later parsing during template instantiation. It will allow resolving many possible issues with lookup in dependent base classes and removing many already existing MSVC-specific hacks/workarounds from the clang code. llvm-svn: 272774
* [-fms-extensions] Don't crash on explicit class-scope specializations & ↵David Majnemer2016-06-101-0/+9
| | | | | | | | | | | | | | default arguments The code had a typo it was doing: Param->setUninstantiatedDefaultArg(Param->getUninstantiatedDefaultArg()); This is a no-op but may assert, we wanted to do: Param->setUninstantiatedDefaultArg(OldParam->getUninstantiatedDefaultArg()); This fixes PR28082. llvm-svn: 272425
* [MSVC] Fix stack overflow in unqualified type lookup logic, by WillAlexey Bataev2016-05-311-0/+29
| | | | | | | | | | Wilson. An unqualified lookup for in base classes may cause stack overflow if the base class is a specialization of current class. Patch by Will Wilson. llvm-svn: 271251
* Re-commit r270748 "clang-cl: Treat dllimport explicit template instantiation ↵Hans Wennborg2016-05-261-2/+11
| | | | | | | | | | definitions as declarations (PR27810, PR27811)" Also make explicit instantiation decls not apply to nested classes when targeting MSVC. That dll attributes are not inherited by inner classes might be the explanation for MSVC's behaviour here. llvm-svn: 270897
* [ms] Allow more unqualified lookup of types in dependent base classesReid Kleckner2016-05-242-1/+40
| | | | | | | | | | | | | | | | | | | Summary: In dependent contexts where we know a type name is required, such as a new expression, we can recover by forming a DependentNameType. This generalizes our existing compatibility hack for default arguments for template type parameters. Works towards parsing atlctrlw.h, which is PR26748. Reviewers: avt77, rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D20500 llvm-svn: 270615
* Fix PR27601 by reverting [r267453] - Refactor traversal of bases in ↵Faisal Vali2016-05-191-0/+47
| | | | | | | | | | | | deduction of template parameters from base This reversal is being done with r267453's author's (i.e. Richard Smith's) permission. This fixes https://llvm.org/bugs/show_bug.cgi?id=27601 Also, per Richard's request the examples from the bug report have been added to our test suite. llvm-svn: 270016
* Warn if function or variable cannot be implicitly instantiatedSerge Pavlov2016-04-191-0/+139
| | | | | | | | | | | | 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
OpenPOWER on IntegriCloud