summaryrefslogtreecommitdiffstats
path: root/clang/test/CXX
Commit message (Collapse)AuthorAgeFilesLines
...
* [c++20] Add support for explicit(bool), as described in P0892R2.Richard Smith2019-05-092-5/+5
| | | | | | | | Patch by Tyker! Differential Revision: https://reviews.llvm.org/D60934 llvm-svn: 360311
* [c++20] Implement P0846R0: allow (ADL-only) calls to template-ids whoseRichard Smith2019-05-094-16/+65
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* When typo-correcting a function name, consider correcting to a type nameRichard Smith2019-05-091-2/+2
| | | | | | for a function-style cast. llvm-svn: 360302
* Revert r359949 "[clang] adding explicit(bool) from c++2a"Hans Wennborg2019-05-062-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This caused Clang to start erroring on the following: struct S {   template <typename = int> explicit S(); }; struct T : S {}; struct U : T {   U(); }; U::U() {} $ clang -c /tmp/x.cc /tmp/x.cc:10:4: error: call to implicitly-deleted default constructor of 'T' U::U() {}    ^ /tmp/x.cc:5:12: note: default constructor of 'T' is implicitly deleted because base class 'S' has no default constructor struct T : S {};            ^ 1 error generated. See discussion on the cfe-commits email thread. This also reverts the follow-ups r359966 and r359968. > this patch adds support for the explicit bool specifier. > > Changes: > - The parsing for the explicit(bool) specifier was added in ParseDecl.cpp. > - The storage of the explicit specifier was changed. the explicit specifier was stored as a boolean value in the FunctionDeclBitfields and in the DeclSpec class. now it is stored as a PointerIntPair<Expr*, 2> with a flag and a potential expression in CXXConstructorDecl, CXXDeductionGuideDecl, CXXConversionDecl and in the DeclSpec class. > - Following the AST change, Serialization, ASTMatchers, ASTComparator and ASTPrinter were adapted. > - Template instantiation was adapted to instantiate the potential expressions of the explicit(bool) specifier When instantiating their associated declaration. > - The Add*Candidate functions were adapted, they now take a Boolean indicating if the context allowing explicit constructor or conversion function and this boolean is used to remove invalid overloads that required template instantiation to be detected. > - Test for Semantic and Serialization were added. > > This patch is not yet complete. I still need to check that interaction with CTAD and deduction guides is correct. and add more tests for AST operations. But I wanted first feedback. > Perhaps this patch should be spited in smaller patches, but making each patch testable as a standalone may be tricky. > > Patch by Tyker > > Differential Revision: https://reviews.llvm.org/D60934 llvm-svn: 360024
* P1286R2: Remove restriction that the exception specification of aRichard Smith2019-05-063-17/+54
| | | | | | defaulted special member matches the implicit exception specification. llvm-svn: 360011
* [c++20] Implement P0428R2 - Familiar template syntax for generic lambdasHamza Sood2019-05-041-6/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D36527 llvm-svn: 359967
* [clang] adding explicit(bool) from c++2aNicolas Lesser2019-05-042-5/+5
| | | | | | | | | | | | | | | | | | | | | this patch adds support for the explicit bool specifier. Changes: - The parsing for the explicit(bool) specifier was added in ParseDecl.cpp. - The storage of the explicit specifier was changed. the explicit specifier was stored as a boolean value in the FunctionDeclBitfields and in the DeclSpec class. now it is stored as a PointerIntPair<Expr*, 2> with a flag and a potential expression in CXXConstructorDecl, CXXDeductionGuideDecl, CXXConversionDecl and in the DeclSpec class. - Following the AST change, Serialization, ASTMatchers, ASTComparator and ASTPrinter were adapted. - Template instantiation was adapted to instantiate the potential expressions of the explicit(bool) specifier When instantiating their associated declaration. - The Add*Candidate functions were adapted, they now take a Boolean indicating if the context allowing explicit constructor or conversion function and this boolean is used to remove invalid overloads that required template instantiation to be detected. - Test for Semantic and Serialization were added. This patch is not yet complete. I still need to check that interaction with CTAD and deduction guides is correct. and add more tests for AST operations. But I wanted first feedback. Perhaps this patch should be spited in smaller patches, but making each patch testable as a standalone may be tricky. Patch by Tyker Differential Revision: https://reviews.llvm.org/D60934 llvm-svn: 359949
* CWG issue 727: Fix numerous bugs in support for class-scope explicitRichard Smith2019-05-031-3/+96
| | | | | | specializations for variable templates. llvm-svn: 359947
* Do not warn on switches over enums that do not use [[maybe_unused]] enumeratorsDavid Blaikie2019-05-021-2/+16
| | | | | | | | | | PR36231, [dcl.attr.unused]p3 Reviewers: aaron.ballman Differential Revision: https://reviews.llvm.org/D61444 llvm-svn: 359800
* [www] Rebuild cxx_dr_status.Richard Smith2019-04-261-1/+1
| | | | llvm-svn: 359261
* C++ DR2387: a variable template declared wtih (or instantiated with) aRichard Smith2019-04-263-4/+30
| | | | | | | | | const-qualified type is not implicitly given internal linkage. But a variable template declared 'static' is. This reinstates part of r359048, reverted in r359076. llvm-svn: 359260
* Add missing diagnostic for explicit instantiation declarations namingRichard Smith2019-04-261-4/+3
| | | | | | | | | | | | | | | | | internal linkage entities. Such constructs are ill-formed by [temp.explicit]p13. We make a special exception to permit an invalid construct used by libc++ in some build modes: its <valarray> header declares some functions with the internal_linkage attribute and then (meaninglessly) provides explicit instantiation declarations for them. Luckily, Clang happens to effectively ignore the explicit instantiation declaration when generating code in this case, and this change codifies that behavior. This reinstates part of r359048, reverted in r359076. (The libc++ issue triggering the rollback has been addressed.) llvm-svn: 359259
* Revert r359048: C++ DR2387: a variable template declared wthiIlya Biryukov2019-04-245-34/+9
| | | | | | | | | | | | | The change breaks libc++ with the follwing error: In file included from valarray:4: .../include/c++/v1/valarray:1062:60: error: explicit instantiation declaration of 'valarray<_Tp>' with internal linkage _LIBCPP_EXTERN_TEMPLATE(_LIBCPP_FUNC_VIS valarray<size_t>::valarray(size_t)) ^ .../include/c++/v1/valarray:1063:60: error: explicit instantiation declaration of '~valarray<_Tp>' with internal linkage _LIBCPP_EXTERN_TEMPLATE(_LIBCPP_FUNC_VIS valarray<size_t>::~valarray()) llvm-svn: 359076
* Add missing diagnostic for anonymous struct/union definitions that don'tRichard Smith2019-04-246-15/+16
| | | | | | introduce any names. llvm-svn: 359051
* C++ DR2387: a variable template declared wtih (or instantiated with) aRichard Smith2019-04-235-9/+34
| | | | | | | const-qualified type is not implicitly given internal linkage. But a variable template declared 'static' is. llvm-svn: 359048
* [c++2a] Implement semantic restrictions for 'export' declarations.Richard Smith2019-04-228-24/+244
| | | | llvm-svn: 358932
* [Sema] ADL: Associated namespaces for class types and enumeration types (CWG ↵Bruno Ricci2019-04-222-5/+61
| | | | | | | | | | | | | | | | | | | 1691) CWG 1691 changed the definition of the namespaces associated with a class type or enumeration type. For a class type, the associated namespaces are the innermost enclosing namespaces of the associated classes. For an enumeration type, the associated namespace is the innermost enclosing namespace of its declaration. This also fixes CWG 1690 and CWG 1692. Differential Revision: https://reviews.llvm.org/D60573 Reviewed By: rjmccall, rsmith llvm-svn: 358882
* [Sema][NFC] Add more tests for the behavior of argument-dependent name lookupBruno Ricci2019-04-225-0/+565
| | | | | | | | | | | | | | | | | | | | | | | The goal here is to exercise each rule in [basic.lookup.argdep] at least once. These new tests expose what I believe are 2 issues: 1. CWG 1691 needs to be implemented (p2: [...] Its associated namespaces are the innermost enclosing namespaces of its associated classes [...]) The corresponding tests are adl_class_type::X2 and adl_class_type::X5. 2. The end of paragraph 2 ([...] Additionally, if the aforementioned set of overloaded functions is named with a template-id, its associated classes and namespaces also include those of its type template-arguments and its template template-arguments.) is not implemented. Closely related, the restriction on non-dependent parameter types in this same paragraph needs to be removed. The corresponding tests are in adl_overload_set (both issues are from CWG 997). Differential Revision: https://reviews.llvm.org/D60570 Reviewed By: riccibruno, Quuxplusone llvm-svn: 358881
* [c++2a] Add semantic support for private module fragments.Richard Smith2019-04-184-11/+88
| | | | llvm-svn: 358713
* [Sema][NFC] Mark DR1563 as done (List-initialization and overloaded function ↵Bruno Ricci2019-04-181-0/+10
| | | | | | | | disambiguation) It has been supported since at least clang 3.1 so just mark it as done. llvm-svn: 358679
* [Sema][NFC] Mark DR705 (Suppressing argument-dependent lookup via ↵Bruno Ricci2019-04-181-0/+13
| | | | | | | | parentheses) as done It was supported since at least clang 3 so just mark it as done. llvm-svn: 358678
* [c++2a] Improve diagnostic for use of declaration from another TU'sRichard Smith2019-04-181-0/+86
| | | | | | | | | | global module fragment. We know that the declaration in question should have been introduced by a '#include', so try to figure out which one and suggest it. Don't suggest importing the global module fragment itself! llvm-svn: 358631
* PR41192: fix cases where "missing ';' after class" error wouldRichard Smith2019-04-161-3/+2
| | | | | | incorrectly fire. llvm-svn: 358467
* [c++20] Enable driver and frontend support for building and usingRichard Smith2019-04-141-0/+40
| | | | | | modules when -std=c++2a is specified. llvm-svn: 358355
* [c++20] Parsing support for module-declarations, import-declarations,Richard Smith2019-04-144-21/+107
| | | | | | | | | and the global and private module fragment. For now, the private module fragment introducer is ignored, but use of the global module fragment introducer should be properly enforced. llvm-svn: 358353
* [C++20] Implement context-sensitive header-name lexing and pp-import parsing ↵Richard Smith2019-04-117-0/+135
| | | | | | in the preprocessor. llvm-svn: 358231
* Fix implementation of [temp.local]p4.Richard Smith2019-02-152-10/+6
| | | | | | | | | | | | | | | | | | | | | | | | 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-152-6/+10
| | | | | | | | | 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-152-10/+6
| | | | | | | | | | | | | | | | | | | | 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
* Add a triple to this test so it passes for targets where alignof(double)Richard Smith2019-01-241-1/+1
| | | | | | really should be equal to alignof(float). llvm-svn: 352102
* Mark the lambda function pointer conversion operator as noexcept.Aaron Ballman2019-01-212-0/+20
| | | | | | This implements CWG DR 1722 and fixes PR40309. Patch by Ignat Loskutov. llvm-svn: 351750
* PR40329: [adl] Fix determination of associated classes when searching aRichard Smith2019-01-161-0/+30
| | | | | | | | | | | | | | | | | | | | | | | member enum and then its enclosing class. There are situations where ADL will collect a class but not the complete set of associated classes / namespaces of that class. When that happened, and we later tried to collect those associated classes / namespaces, we would previously short-circuit the lookup and not find them. Eg, for: struct A : B { enum E; }; if we first looked for associated classes/namespaces of A::E, we'd find only A. But if we then tried to also collect associated classes/namespaces of A (which should include the base class B), we would not add B because we had already visited A. This also fixes a minor issue where we would fail to collect associated classes from an overloaded class member access expression naming a static member function. llvm-svn: 351382
* DR674, PR38883, PR40238: Qualified friend lookup should look for aRichard Smith2019-01-076-27/+48
| | | | | | | | | | | | | | | | | | template specialization if there is no matching non-template function. This exposed a couple of related bugs: - we would sometimes substitute into a friend template instead of a suitable non-friend declaration; this would now crash because we'd decide the specialization of the friend is a redeclaration of itself - ADL failed to properly handle the case where an invisible local extern declaration redeclares an invisible friend Both are fixed herein: in particular, we now never make invisible friends or local extern declarations visible to name lookup unless they are the only declaration of the entity. (We already mostly did this for local extern declarations.) llvm-svn: 350505
* Refactor the way we handle diagnosing unused expression results.Aaron Ballman2019-01-041-5/+4
| | | | | | | | Rather than sprinkle calls to DiagnoseUnusedExprResult() around in places where we want diagnostics, we now diagnose unused expression statements and full expressions in a more generic way when acting on the final expression statement. This results in more appropriate diagnostics for [[nodiscard]] where we were previously lacking them, such as when the body of a for loop is not a compound statement. This patch fixes PR39837. llvm-svn: 350404
* Diagnose an unused result from a call through a function pointer whose ↵Aaron Ballman2019-01-031-0/+29
| | | | | | | | | | return type is marked [[nodiscard]]. When a function returns a type and that type was declared [[nodiscard]], we diagnose any unused results from that call as though the function were marked nodiscard. The same behavior should apply to calls through a function pointer. This addresses PR31526. llvm-svn: 350317
* [Sema] Produce diagnostics when C++17 aligned allocation/deallocationAkira Hatanaka2018-12-211-2/+2
| | | | | | | | | | | functions that are unavailable on Darwin are explicitly called or called from deleting destructors. rdar://problem/40736230 Differential Revision: https://reviews.llvm.org/D47757 llvm-svn: 349890
* [NFC] Test commit: tweak whitespace in commentTan S. B.2018-12-171-2/+2
| | | | llvm-svn: 349384
* [constexpr][c++2a] Try-catch blocks in constexpr functionsBruno Cardoso Lopes2018-12-103-8/+40
| | | | | | | | | | | | | | | | | | | | | | Implement support for try-catch blocks in constexpr functions, as proposed in http://wg21.link/P1002 and voted in San Diego for c++20. The idea is that we can still never throw inside constexpr, so the catch block is never entered. A try-catch block like this: try { f(); } catch (...) { } is then morally equivalent to just { f(); } Same idea should apply for function/constructor try blocks. rdar://problem/45530773 Differential Revision: https://reviews.llvm.org/D55097 llvm-svn: 348789
* Revert r345562: "PR23833, DR2140: an lvalue-to-rvalue conversion on a ↵Richard Smith2018-11-031-10/+0
| | | | | | | | | | | | glvalue of type" This exposes a (known) CodeGen bug: it can't cope with emitting lvalue expressions that denote non-odr-used but usable-in-constant-expression variables. See PR39528 for a testcase. Reverted for now until that issue can be fixed. llvm-svn: 346065
* PR23833, DR2140: an lvalue-to-rvalue conversion on a glvalue of typeRichard Smith2018-10-301-0/+10
| | | | | | | | | nullptr_t does not access memory. We now reuse CK_NullToPointer to represent a conversion from a glvalue of type nullptr_t to a prvalue of nullptr_t where necessary. llvm-svn: 345562
* [C++17] Reject shadowing of capture by parameter in lambdaNicolas Lesser2018-10-251-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change rejects the shadowing of a capture by a parameter in lambdas in C++17. ``` int main() { int a; auto f = [a](int a) { return a; }; } ``` results in: ``` main.cpp:3:20: error: a lambda parameter cannot shadow an explicitly captured entity auto f = [a](int a) { return a; }; ^ main.cpp:3:13: note: variable a is explicitly captured here auto f = [a](int a) { return a; }; ^ ``` Reviewers: rsmith Reviewed By: rsmith Subscribers: lebedev.ri, erik.pilkington, cfe-commits Differential Revision: https://reviews.llvm.org/D53595 llvm-svn: 345308
* PR24164, PR39336: init-captures are not distinct full-expressions.Richard Smith2018-10-191-1/+51
| | | | | | | | | Rather, they are subexpressions of the enclosing lambda-expression, and any temporaries in them are destroyed at the end of that full-expression, or when the corresponding lambda-expression is destroyed if they are lifetime-extended. llvm-svn: 344801
* Add basic test that we perform lifetime extension in the expectedRichard Smith2018-10-191-0/+190
| | | | | | situations. llvm-svn: 344800
* Revert "[CodeGenCXX] Treat 'this' as noalias in constructors"Sean Fertile2018-10-151-6/+6
| | | | | | | This reverts commit https://reviews.llvm.org/rL344150 which causes MachineOutliner related failures on the ppc64le multistage buildbot. llvm-svn: 344526
* [CodeGenCXX] Treat 'this' as noalias in constructorsAnton Bikineev2018-10-101-6/+6
| | | | | | | | | This is currently a clang extension and a resolution of the defect report in the C++ Standard. Differential Revision: https://reviews.llvm.org/D46441 llvm-svn: 344150
* [cxx2a] P0641R2: (Some) type mismatches on defaulted functions onlyRichard Smith2018-09-287-10/+57
| | | | | | | | | | | | | | | | 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
* P0859R0: List-initialization is potentially-constant-evaluated andRichard Smith2018-09-262-0/+51
| | | | | | | | | | | | triggers instantiation of constexpr functions. We mostly implemented this since Clang 6, but missed the template instantiation case. We do not implement the '&cast-expression' special case. It appears to be a mistake / oversight. I've mailed CWG to see if we can remove it. llvm-svn: 343064
* P0969R0: allow structured binding of accessible members, not only public ↵Richard Smith2018-09-251-5/+46
| | | | | | members. llvm-svn: 343036
* P0962R1: only use the member form of 'begin' and 'end' in a range-basedRichard Smith2018-09-241-2/+57
| | | | | | | | | | for loop if both members exist. This resolves a DR whereby an errant 'begin' or 'end' member in a base class could result in a derived class not being usable as a range with non-member 'begin' and 'end'. llvm-svn: 342925
* [Sema] Remove location from implicit capture init exprVedant Kumar2018-09-132-4/+4
| | | | | | | | | | | | | | | | | | A lambda's closure is initialized when the lambda is declared. For implicit captures, the initialization code emitted from EmitLambdaExpr references source locations *within the lambda body* in the function containing the lambda. This results in a poor debugging experience: we step to the line containing the lambda, then into lambda, out again, over and over, until every capture's field is initialized. To improve stepping behavior, assign the starting location of the lambda to expressions which initialize an implicit capture within it. rdar://39807527 Differential Revision: https://reviews.llvm.org/D50927 llvm-svn: 342194
OpenPOWER on IntegriCloud