summaryrefslogtreecommitdiffstats
path: root/clang/test/SemaTemplate
Commit message (Collapse)AuthorAgeFilesLines
...
* Properly handle instantiation-dependent array bounds.Richard Smith2019-10-041-2/+1
| | | | | | | | | We previously failed to treat an array with an instantiation-dependent but not value-dependent bound as being an instantiation-dependent type. We now track the array bound expression as part of a constant array type if it's an instantiation-dependent expression. llvm-svn: 373685
* Check for qualified function types after substituting into the operandRichard Smith2019-10-031-0/+9
| | | | | | | | | | of 'typeid'. This is a rare place where it's valid for a function type to be substituted but not valid for a qualified function type to be substituted, so needs a special check. llvm-svn: 373648
* PR43547: substitute into the type of a non-type template parameter ifRichard Smith2019-10-031-0/+12
| | | | | | | | it's instantiation-dependent, even if it's not dependent. There might be a SFINAE check in the parameter type. llvm-svn: 373643
* Always rebuild a DeclRefExpr if its FoundDecl would change.Richard Smith2019-09-261-0/+16
| | | | | | Fixes a regression introduced by r369999. llvm-svn: 373022
* Push lambda scope earlier when transforming lambda expressionNicholas Allegra2019-09-171-0/+15
| | | | | | Differential Revision: https://reviews.llvm.org/D66067 llvm-svn: 372058
* Fixes an assertion while instantiating a template with an incomplete ↵Aaron Ballman2019-09-071-0/+60
| | | | | | | | | | typo-corrected type. Fixes PR35682. When a template in instantiated with an incomplete typo corrected type an assertion can trigger if the -ferror-limit is used to reduce the number of errors. Patch by Mark de Wever. llvm-svn: 371320
* Disable stack exhaustion test on NetBSD, where either the detection orRichard Smith2019-09-031-0/+5
| | | | | | recovery mechanism does not appear to work. llvm-svn: 370801
* [c++20] Disallow template argument deduction from a braced-init-listRichard Smith2019-08-311-0/+7
| | | | | | | | | | | | containing designators. The C++20 wording doesn't actually say what happens in this case, but treating this as a non-deduced context seems like the most natural behavior. (We might want to consider deducing through array designators as an extension in the future, but will need to be careful to deduce the array bound properly if we do so. That's not permitted herein.) llvm-svn: 370555
* [c++20] Implement semantic restrictions for C++20 designatedRichard Smith2019-08-302-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | initializers. This has some interesting interactions with our existing extensions to support C99 designated initializers as an extension in C++. Those are resolved as follows: * We continue to permit the full breadth of C99 designated initializers in C++, with the exception that we disallow a partial overwrite of an initializer with a non-trivially-destructible type. (Full overwrite is OK, because we won't run the first initializer at all.) * The C99 extensions are disallowed in SFINAE contexts and during overload resolution, where they could change the meaning of valid programs. * C++20 disallows reordering of initializers. We only check for that for the simple cases that the C++20 rules permit (designators of the form '.field_name =' and continue to allow reordering in other cases). It would be nice to improve this behavior in future. * All C99 designated initializer extensions produce a warning by default in C++20 mode. People are going to learn the C++ rules based on what Clang diagnoses, so it's important we diagnose these properly by default. * In C++ <= 17, we apply the C++20 rules rather than the C99 rules, and so still diagnose C99 extensions as described above. We continue to accept designated C++20-compatible initializers in C++ <= 17 silently by default (but naturally still reject under -pedantic-errors). This is not a complete implementation of P0329R4. In particular, that paper introduces new non-C99-compatible syntax { .field { init } }, and we do not support that yet. This is based on a previous patch by Don Hinton, though I've made substantial changes when addressing the above interactions. Differential Revision: https://reviews.llvm.org/D59754 llvm-svn: 370544
* Improve behavior in the case of stack exhaustion.Richard Smith2019-08-261-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Clang performs various recursive operations (such as template instantiation), and may use non-trivial amounts of stack space in each recursive step (for instance, due to recursive AST walks). While we try to keep the stack space used by such steps to a minimum and we have explicit limits on the number of such steps we perform, it's impractical to guarantee that we won't blow out the stack on deeply recursive template instantiations on complex ASTs, even with only a moderately high instantiation depth limit. The user experience in these cases is generally terrible: we crash with no hint of what went wrong. Under this patch, we attempt to do better: * Detect when the stack is nearly exhausted, and produce a warning with a nice template instantiation backtrace, telling the user that we might run slowly or crash. * For cases where we're forced to trigger recursive template instantiation in arbitrarily-deeply-nested contexts, check whether we're nearly out of stack space and allocate a new stack (by spawning a new thread) after producing the warning. Reviewers: rnk, aaron.ballman Subscribers: mgorny, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66361 llvm-svn: 369940
* PR42513: Enter the proper DeclContext before substituting into anRichard Smith2019-08-241-0/+17
| | | | | | | | | | | | default template argument expression. We already did this for type template parameters and template template parameters, but apparently forgot to do so for non-type template parameters. This causes the substituted default argument expression to be substituted in the proper context, and in particular to properly mark its subexpressions as odr-used. llvm-svn: 369834
* Revert "Fix crash on switch conditions of non-integer types in templates"Dmitri Gribenko2019-08-134-16/+6
| | | | | | This reverts commit r368706. It broke ClangTidy tests. llvm-svn: 368738
* Fix crash on switch conditions of non-integer types in templatesElizabeth Andrews2019-08-134-6/+16
| | | | | | | | | | | | | | | | | | | Clang currently crashes for switch statements inside a template when the condition is a non-integer field. The crash is due to incorrect type-dependency of field. Type-dependency of member expressions is currently set based on the containing class. This patch changes this for 'members of the current instantiation' to set the type dependency based on the member's type instead. A few lit tests started to fail once I applied this patch because errors are now diagnosed earlier (does not wait till instantiation). I've modified these tests in this patch as well. Patch fixes PR#40982 Differential Revision: https://reviews.llvm.org/D61027 llvm-svn: 368706
* Renamed and changed the wording of warn_cconv_ignoredSunil Srivastava2019-07-171-1/+1
| | | | | | | | As discussed in D64780 the wording of this warning message is being changed to say 'is not supported' instead of 'ignored', and the diag ID itself is being changed to warn_cconv_not_supported. llvm-svn: 366368
* [SemaTemplate] Fix uncorrected typos after pack expansionSam McCall2019-07-161-0/+2
| | | | | | | | | | | | | | | | Summary: This case is particularly important for clangd, as it is triggered after inserting the snippet for variadic functions. Reviewers: kadircet, ilya-biryukov Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64677 llvm-svn: 366200
* Add regression test for PR41576 (which is already fixed in trunk,Richard Smith2019-06-251-1/+9
| | | | | | perhaps by r361300). llvm-svn: 364340
* PR42362: Fix auto deduction of template parameter packs fromRichard Smith2019-06-241-0/+15
| | | | | | | | | type-dependent argument packs. We need to strip off the PackExpansionExpr to get the real (dependent) type rather than an opaque DependentTy. llvm-svn: 364165
* Fix crash and rejects-valid when a later template parameter or defaultRichard Smith2019-06-202-0/+31
| | | | | | | | | | | | | | | | | | | | template argument contains a backreference to a dependently-typed earlier parameter. In a case like: template<typename T, T A, decltype(A) = A> struct X {}; template<typename U> auto Y = X<U, 0>(); we previously treated both references to `A` in the third parameter as being of type `int` when checking the template-id in `Y`. That`s wrong; the type of `A` in these contexts is the dependent type `U`. When we encounter a non-type template argument that we can't convert to the parameter type because of type-dependence, we now insert a dependent conversion node so that the SubstNonTypeTemplateParmExpr for the template argument will have the parameter's type rather than whatever type the argument had. llvm-svn: 363972
* Fix crash when checking a dependently-typed reference that isRichard Smith2019-06-171-0/+8
| | | | | | initialized from a non-value-dependent initializer. llvm-svn: 363622
* Mark declarations as referenced by a default argument in aRichard Smith2019-06-111-0/+6
| | | | | | | | | potentially-evaluated context. This applies even if the use of the default argument is within an unevaluated context. llvm-svn: 363113
* PR42104: Support instantiations of lambdas that implicitly captureRichard Smith2019-06-041-0/+17
| | | | | | | | | | | | | | | | | packs. Two changes: * Track odr-use via FunctionParmPackExprs to properly handle dependent odr-uses of packs in generic lambdas. * Do not instantiate implicit captures; instead, regenerate them by instantiating the body of the lambda. This is necessary to distinguish between cases where only one element of a pack is captured and cases where the entire pack is captured. This reinstates r362358 (reverted in r362375) with a fix for an uninitialized variable use in UpdateMarkingForLValueToRValue. llvm-svn: 362531
* Revert rL362358 : PR42104: Support instantiations of lambdas that implicitly ↵Simon Pilgrim2019-06-031-17/+0
| | | | | | | | | | | | | | | | capture packs. Two changes: * Track odr-use via FunctionParmPackExprs to properly handle dependent odr-uses of packs in generic lambdas. * Do not instantiate implicit captures; instead, regenerate them by instantiating the body of the lambda. This is necessary to distinguish between cases where only one element of a pack is captured and cases where the entire pack is captured. ........ Fixes http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win buildbot failures llvm-svn: 362375
* PR42104: Support instantiations of lambdas that implicitly captureRichard Smith2019-06-031-0/+17
| | | | | | | | | | | | | | packs. Two changes: * Track odr-use via FunctionParmPackExprs to properly handle dependent odr-uses of packs in generic lambdas. * Do not instantiate implicit captures; instead, regenerate them by instantiating the body of the lambda. This is necessary to distinguish between cases where only one element of a pack is captured and cases where the entire pack is captured. llvm-svn: 362358
* [c++20] P0780R2: Support pack-expansion of init-captures.Richard Smith2019-05-211-1/+7
| | | | | | | | | | | This permits an init-capture to introduce a new pack: template<typename ...T> auto x = [...a = T()] { /* a is a pack */ }; To support this, the mechanism for allowing ParmVarDecls to be packs has been extended to support arbitrary local VarDecls. llvm-svn: 361300
* Make tentative parsing to detect template-argument-lists less aggressiveRichard Smith2019-05-151-4/+4
| | | | | | | | | | | | | | | | | | (and less wrong). It's not correct to assume that X<something, Type> is always a template-id; there are a few cases where the comma takes us into a non-expression syntactic context in which 'Type' might be permissible. Stop doing that. This slightly regresses our error recovery on the cases where the construct is intended to be a template-id. We typically do still manage to diagnose a missing 'template' keyword, but we realize this too late to properly recover from the error. This fixes a regression introduced by r360308. llvm-svn: 360827
* PR41845: Detect and reject mismatched inner/outer pack expansion sizesRichard Smith2019-05-131-0/+10
| | | | | | in fold expressions rather than crashing. llvm-svn: 360563
* Replace 'REQUIRES: not_?san' with 'UNSUPPORTED: ?san' as that betterPaul Robinson2019-05-101-1/+1
| | | | | | expresses the intent of the exclusion. llvm-svn: 360447
* [c++20] Implement P0846R0: allow (ADL-only) calls to template-ids whoseRichard Smith2019-05-094-10/+13
| | | | | | | | | | | | | | | | | | | | | | | | | template name is not visible to unqualified lookup. In order to support this without a severe degradation in our ability to diagnose typos in template names, this change significantly restructures the way we handle template-id-shaped syntax for which lookup of the template name finds nothing. Instead of eagerly diagnosing an undeclared template name, we now form a placeholder template-name representing a name that is known to not find any templates. When the parser sees such a name, it attempts to disambiguate whether we have a less-than comparison or a template-id. Any diagnostics or typo-correction for the name are delayed until its point of use. The upshot should be a small improvement of our diagostic quality overall: we now take more syntactic context into account when trying to resolve an undeclared identifier on the left hand side of a '<'. In fact, this works well enough that the backwards-compatible portion (for an undeclared identifier rather than a lookup that finds functions but no function templates) is enabled in all language modes. llvm-svn: 360308
* P1286R2: Remove restriction that the exception specification of aRichard Smith2019-05-061-5/+1
| | | | | | defaulted special member matches the implicit exception specification. llvm-svn: 360011
* CWG issue 727: Fix numerous bugs in support for class-scope explicitRichard Smith2019-05-031-6/+20
| | | | | | specializations for variable templates. llvm-svn: 359947
* PR41607: Don't forget to substitute outer template arguments into aRichard Smith2019-04-261-0/+17
| | | | | | class-scope explicit specialization of a class template. llvm-svn: 359266
* PR41427: This has apparently been fixed already, just add a regressionRichard Smith2019-04-241-0/+17
| | | | | | test. llvm-svn: 359155
* Permit redeclarations of a builtin to specify calling convention.Erich Keane2019-03-211-1/+1
| | | | | | | | | | | | | | | | | | | | After https://reviews.llvm.org/rL355317 we noticed that quite a decent amount of code redeclares builtins (memcpy in particular, I believe reduced from an MSVC header) with a calling convention specified. This gets particularly troublesome when the user specifies a new 'default' calling convention on the command line. When looking to add a diagnostic for this case, it was noticed that we had 3 other diagnostics that differed only slightly. This patch ALSO unifies those under a 'select'. Unfortunately, the order of words in ONE of these diagnostics was reversed ("'thiscall' calling convention" vs "calling convention 'thiscall'"), so this patch also standardizes on the former. Differential Revision: https://reviews.llvm.org/D59560 Change-Id: I79f99fe7c2301640755ffdd774b46eb44526bb22 llvm-svn: 356663
* [Sema] Deduplicate some availability checking logicErik Pilkington2019-03-201-2/+2
| | | | | | | | | | | | | | | Before this commit, we emit unavailable errors for calls to functions during overload resolution, and for references to all other declarations in DiagnoseUseOfDecl. The early checks during overload resolution aren't as good as the DiagnoseAvailabilityOfDecl based checks, as they error on the code from PR40991. This commit fixes this by removing the early checking. llvm.org/PR40991 rdar://48564179 Differential revision: https://reviews.llvm.org/D59394 llvm-svn: 356599
* Remove an assert in template pack deduction during nested instantiation.Richard Trieu2019-03-151-0/+19
| | | | llvm-svn: 356231
* [MS] Fix for Bug 8446, template instantiation without a 'typename' keywordReid Kleckner2019-02-261-0/+102
| | | | | | | | Patch by Zahira Ammarguellat! Differential Revision: https://reviews.llvm.org/D41950 llvm-svn: 354838
* Fix implementation of [temp.local]p4.Richard Smith2019-02-151-4/+35
| | | | | | | | | | | | | | | | | | | | | | | | When a template-name is looked up, we need to give injected-class-name declarations of class templates special treatment, as they denote a template rather than a type. Previously we achieved this by applying a filter to the lookup results after completing name lookup, but that is incorrect in various ways, not least of which is that it lost all information about access and how members were named, and the filtering caused us to generally lose all ambiguity errors between templates and non-templates. We now preserve the lookup results exactly, and the few places that need to map from a declaration found by name lookup into a declaration of a template do so explicitly. Deduplication of repeated lookup results of the same injected-class-name declaration is done by name lookup instead of after the fact. This reinstates r354091, which was previously reverted in r354097 because it exposed bugs in lldb and compiler-rt. Those bugs were fixed in r354173 and r354174 respectively. llvm-svn: 354176
* Revert "Fix implementation of [temp.local]p4."Francis Visoiu Mistrih2019-02-151-35/+4
| | | | | | | | | This reverts commit 40bd10b770813bd1471d46f514545437516aa4ba. This seems to now emit an error when building the sanitizer tests: http://green.lab.llvm.org/green/job/clang-stage1-configure-RA/53965/consoleFull. llvm-svn: 354097
* Fix implementation of [temp.local]p4.Richard Smith2019-02-151-4/+35
| | | | | | | | | | | | | | | | | | | | When a template-name is looked up, we need to give injected-class-name declarations of class templates special treatment, as they denote a template rather than a type. Previously we achieved this by applying a filter to the lookup results after completing name lookup, but that is incorrect in various ways, not least of which is that it lost all information about access and how members were named, and the filtering caused us to generally lose all ambiguity errors between templates and non-templates. We now preserve the lookup results exactly, and the few places that need to map from a declaration found by name lookup into a declaration of a template do so explicitly. Deduplication of repeated lookup results of the same injected-class-name declaration is done by name lookup instead of after the fact. llvm-svn: 354091
* [NFC] Explicitly add -std=c++14 option to tests that rely on the C++14 defaultNemanja Ivanovic2019-02-053-4/+4
| | | | | | | | | | | When Clang/LLVM is built with the CLANG_DEFAULT_STD_CXX CMake macro that sets the default standard to something other than C++14, there are a number of lit tests that fail as they rely on the C++14 default. This patch just adds the language standard option explicitly to such test cases. Differential revision: https://reviews.llvm.org/D57581 llvm-svn: 353163
* Remember to instantiate explicit template argument lists in a friendRichard Smith2019-01-111-0/+75
| | | | | | | | | | | | | | | function declaration. We'd previously often just drop these on the floor, and friend redeclaration matching would usually (but not always) figure out the right redeclaration anyway. Also, don't try to match a dependent friend function template specialization to a template until instantiation, and don't forget to reject qualified friend declarations in dependent contexts that don't name an already-declared entity. llvm-svn: 350915
* Fix crash if an in-class explicit function specialization has explicitRichard Smith2018-12-041-0/+11
| | | | | | template arguments referring to template paramaeters. llvm-svn: 348313
* PR12884: Add test (bug is already fixed).Richard Smith2018-11-281-0/+56
| | | | llvm-svn: 347729
* PR39231: fix null dereference when diagnosing deduction failure due toRichard Smith2018-10-091-0/+16
| | | | | | conflicting values for a non-type pack. llvm-svn: 344070
* [cxx2a] P0641R2: (Some) type mismatches on defaulted functions onlyRichard Smith2018-09-281-2/+2
| | | | | | | | | | | | | | | | render the function deleted instead of rendering the program ill-formed. This change also adds an enabled-by-default warning for the case where an explicitly-defaulted special member function of a non-template class is implicitly deleted by the type checking rules. (This fires either due to this language change or due to pre-C++20 reasons for the member being implicitly deleted). I've tested this on a large codebase and found only bugs (where the program means something that's clearly different from what the programmer intended), so this is enabled by default, but we should revisit this if there are problems with this being enabled by default. llvm-svn: 343285
* PR38627: Fix handling of exception specification adjustment forRichard Smith2018-09-051-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | destructors. We previously tried to patch up the exception specification after completing the class, which went wrong when the exception specification was needed within the class body (in particular, by a friend redeclaration of the destructor in a nested class). We now mark the destructor as having a not-yet-computed exception specification immediately after creating it. This requires delaying various checks against the exception specification (where we'd previously have just got the wrong exception specification, and now find we have an exception specification that we can't compute yet) when those checks fire while the class is being defined. This also exposed an issue that we were missing a CodeSynthesisContext for computation of exception specifications (otherwise we'd fail to make the module containing the definition of the class visible when computing its members' exception specs). Adding that incidentally also gives us a diagnostic quality improvement. This has also exposed an pre-existing problem: making the exception specification evaluation context a non-SFINAE context (as it should be) results in a bootstrap failure; PR38850 filed for this. llvm-svn: 341499
* [CMake] Use normalized Windows target triplesPetr Hosek2018-08-091-1/+1
| | | | | | | | | | | Changes the default Windows target triple returned by GetHostTriple.cmake from the old environment names (which we wanted to move away from) to newer, normalized ones. This also requires updating all tests to use the new systems names in constraints. Differential Revision: https://reviews.llvm.org/D47381 llvm-svn: 339307
* [Sema] Ensure an auto non-type template parameter is dependentErik Pilkington2018-08-071-0/+43
| | | | | | | | | | | The dependent auto was getting stripped away while rebuilding the template parameter type, so substitute it in. rdar://41852459 Differential revision: https://reviews.llvm.org/D50088 llvm-svn: 339198
* Append new attributes to the end of an AttributeList.Michael Kruse2018-08-031-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Recommit of r335084 after revert in r335516. ... instead of prepending it at the beginning (the original behavior since implemented in r122535 2010-12-23). This builds up an AttributeList in the the order in which the attributes appear in the source. The reverse order caused nodes for attributes in the AST (e.g. LoopHint) to be in the reverse order, and therefore printed in the wrong order in -ast-dump. Some TODO comments mention this. The order was explicitly reversed for enable_if attribute overload resolution and name mangling, which is not necessary anymore with this patch. The change unfortunately has some secondary effect, especially on diagnostic output. In the simplest cases, the CHECK lines or expected diagnostic were changed to the the new output. If the kind of error/warning changed, the attributes' order was changed instead. This unfortunately causes some 'previous occurrence here' hints to be textually after the main marker. This typically happens when attributes are merged, but are incompatible to each other. Interchanging the role of the the main and note SourceLocation will also cause the case where two different declaration's attributes (in contrast to multiple attributes of the same declaration) are merged to be reverse. There is no easy fix because sometimes previous attributes are merged into a new declaration's attribute list, sometimes new attributes are added to a previous declaration's attribute list. Since 'previous occurrence here' pointing to locations after the main marker is not rare, I left the markers as-is; it is only relevant when the attributes are declared in the same declaration anyway. Differential Revision: https://reviews.llvm.org/D48100 llvm-svn: 338800
* PR38257: don't perform ADL when instantiating a unary & operator that turns outRichard Smith2018-07-221-0/+45
| | | | | | to be forming a pointer-to-member. llvm-svn: 337653
OpenPOWER on IntegriCloud