[clang] [Clang] Fix Microsoft ABI inheritance model when member pointer is used in a base specifier (PR #91990)

https://github.com/MitalAshok updated https://github.com/llvm/llvm-project/pull/91990 >From 5dc9193af0d98335a87e93ad70d945dbc0ffce79 Mon Sep 17 00:00:00 2001 From: Mital Ashok Date: Mon, 13 May 2024 16:59:06 +0100 Subject: [PATCH] [Clang] Fix Microsoft ABI inheritance model when member

[clang] [Clang] Fix Microsoft ABI inheritance model when member pointer is used in a base specifier (PR #91990)

MitalAshok wrote: Example of the incompatibility: https://godbolt.org/z/Mn1T57WGb ```c++ struct unspecified_inheritance; template struct X { static_assert(I == sizeof(int unspecified_inheritance::*), ""); }; struct Y : X {}; ``` Currently, the `sizeof(int Y::*)` locks down the inheritance

[clang] [Clang] Fix Microsoft ABI inheritance model when member pointer is used in a base specifier (PR #91990)

https://github.com/MitalAshok created https://github.com/llvm/llvm-project/pull/91990 Fix `CXXRecordDecl::isParsingBaseSpecifiers` so that it is true while parsing base specifiers instead of directly after they have been parsed. -fcomplete-member-pointers now issues a diagnostic when a member

[clang] [Clang] Add attribute for consteval builtins; Declare constexpr builtins as constexpr in C++ (PR #91894)

@@ -14,13 +14,18 @@ void __builtin_va_copy(double d); // expected-error@+2 {{cannot redeclare builtin function '__builtin_va_end'}} // expected-note@+1 {{'__builtin_va_end' is a builtin with type}} void __builtin_va_end(__builtin_va_list); -// RUN: %clang_cc1 %s -fsyntax-only

[clang] [Clang] Ensure ``if consteval`` consititute an immediate function context (PR #91939)

@@ -7964,6 +7964,15 @@ TreeTransform::TransformIfStmt(IfStmt *S) { // Transform the "then" branch. StmtResult Then; if (!ConstexprConditionValue || *ConstexprConditionValue) { +Sema::ExpressionEvaluationContext Context = +S->isNonNegatedConsteval() +

[clang] [Clang] Add attribute for consteval builtins; Declare constexpr builtins as constexpr in C++ (PR #91894)

MitalAshok wrote: Currently, GCC's behaviour for builtin function redeclarations is to just ignore `constexpr`: . This is slightly stricter, allowing non-`constexpr` redeclarations for `constexpr` builtins but still disallowing `constexpr` declarations for

[clang] [Clang] Add __builtin_is_within_lifetime to implement P2641R4's std::is_within_lifetime (PR #91895)

MitalAshok wrote: This is on top of #91894 [P2641R4](https://wg21.link/P2641R4) Currently, this doesn't strictly check "whose complete object's lifetime began within `E`". A bunch of the static_asserts I have for objects under construction should be ill-formed instead of false, but some of

[clang] [Clang] Add __builtin_is_within_lifetime to implement P2641R4's std::is_within_lifetime (PR #91895)

https://github.com/MitalAshok created https://github.com/llvm/llvm-project/pull/91895 None >From 56aed689dc5825fc5bacc6dfdff58ee0eaf71f82 Mon Sep 17 00:00:00 2001 From: Mital Ashok Date: Sun, 12 May 2024 19:48:24 +0100 Subject: [PATCH 1/2] [Clang] Add attribute for consteval builtins; Declare

[clang] [Clang] Add attribute for consteval builtins; Declare constexpr builtins as constexpr in C++ (PR #91894)

https://github.com/MitalAshok created https://github.com/llvm/llvm-project/pull/91894 Also support redeclaring now-constexpr builtins without constexpr >From 56aed689dc5825fc5bacc6dfdff58ee0eaf71f82 Mon Sep 17 00:00:00 2001 From: Mital Ashok Date: Sun, 12 May 2024 19:48:24 +0100 Subject:

[clang] [analyzer] Allow recursive functions to be trivial. (PR #91876)

MitalAshok wrote: You should add a test for mutually recursive functions. I suspect something like this doesn't work: ```c++ int non_trivial(); int f(bool b) { return g(!b) + non_trivial(); } int g(bool b) { return b ? f(b) : 1; } getFieldTrivial().f(true); //

[clang] [Clang] No longer require complete types with __builtin_launder (PR #91070)

MitalAshok wrote: Here's one scenario where it could make a difference in codegen : ```c++ // Header struct X; extern X x; void f(X&); inline void g() { f(x); } inline void h() { f(*__builtin_launder(__builtin_addressof(x))); } // Source struct X {

[clang] [Clang] No longer require complete types with __builtin_launder (PR #91070)

https://github.com/MitalAshok updated https://github.com/llvm/llvm-project/pull/91070 >From 11ad517cede0902945c0b7eba0e7f1ff93f08ea0 Mon Sep 17 00:00:00 2001 From: Mital Ashok Date: Sat, 4 May 2024 17:31:31 +0100 Subject: [PATCH] [Clang] No longer require complete types with __builtin_launder

[clang] [Clang] No longer require complete types with __builtin_launder (PR #91070)

https://github.com/MitalAshok updated https://github.com/llvm/llvm-project/pull/91070 >From fe8c0dc5f7beacae7b1494a5987c3674dbd330d3 Mon Sep 17 00:00:00 2001 From: Mital Ashok Date: Sat, 4 May 2024 17:31:31 +0100 Subject: [PATCH] [Clang] No longer require complete types with __builtin_launder

[clang] [Clang] No longer require complete types with __builtin_launder (PR #91070)

https://github.com/MitalAshok created https://github.com/llvm/llvm-project/pull/91070 Incomplete types are assumed to need the llvm.launder.invariant.group intrinsic Fixes #90949 >From 21d9f27692b2a2fa9ac99f4644109e62e3730133 Mon Sep 17 00:00:00 2001 From: Mital Ashok Date: Sat, 4 May 2024

[clang] [Clang][Sema] Fix incorrect rejection default construction of union with nontrivial member (PR #82407)

@@ -9442,9 +9442,21 @@ bool SpecialMemberDeletionInfo::shouldDeleteForSubobjectCall( int DiagKind = -1; - if (SMOR.getKind() == Sema::SpecialMemberOverloadResult::NoMemberOrDeleted) -DiagKind = !Decl ? 0 : 1; - else if (SMOR.getKind() ==

[clang] [Clang][Sema] Fix incorrect rejection default construction of union with nontrivial member (PR #82407)

MitalAshok wrote: This is [CWG2084](https://wg21.link/CWG2084). Could you also add some tests to CXX/drs/ so that www/cxx_dr_status.html can be updated? https://github.com/llvm/llvm-project/pull/82407 ___ cfe-commits mailing list

[clang] [Clang] Ensure "=default"ed function can be deleted when used as an extension in C++03 (PR #90725)

https://github.com/MitalAshok updated https://github.com/llvm/llvm-project/pull/90725 >From 0793795ba7d5d5974b1403cd6ead0221fc20c5bb Mon Sep 17 00:00:00 2001 From: Mital Ashok Date: Wed, 1 May 2024 12:45:54 +0100 Subject: [PATCH 1/3] [Clang] Ensure "=default"ed function can be deleted when

[clang] [Clang] Ensure "=default"ed function can be deleted when used as an extension in C++03 (PR #90725)

https://github.com/MitalAshok updated https://github.com/llvm/llvm-project/pull/90725 >From 0793795ba7d5d5974b1403cd6ead0221fc20c5bb Mon Sep 17 00:00:00 2001 From: Mital Ashok Date: Wed, 1 May 2024 12:45:54 +0100 Subject: [PATCH 1/2] [Clang] Ensure "=default"ed function can be deleted when

[clang] [Clang] Ensure "=default"ed function can be deleted when used as an extension in C++03 (PR #90725)

@@ -9767,7 +9767,9 @@ bool Sema::ShouldDeleteSpecialMember(CXXMethodDecl *MD, return false; CXXRecordDecl *RD = MD->getParent(); assert(!RD->isDependentType() && "do deletion after instantiation"); - if (!LangOpts.CPlusPlus || (!LangOpts.CPlusPlus11 &&

[clang] [Clang] Ensure "=default"ed function can be deleted when used as an extension in C++03 (PR #90725)

https://github.com/MitalAshok converted_to_draft https://github.com/llvm/llvm-project/pull/90725 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] Ensure "=default"ed function can be deleted when used as an extension in C++03 (PR #90725)

https://github.com/MitalAshok updated https://github.com/llvm/llvm-project/pull/90725 >From 0793795ba7d5d5974b1403cd6ead0221fc20c5bb Mon Sep 17 00:00:00 2001 From: Mital Ashok Date: Wed, 1 May 2024 12:45:54 +0100 Subject: [PATCH 1/2] [Clang] Ensure "=default"ed function can be deleted when

[clang] [Clang] Ensure "=default"ed function can be deleted when used as an extension in C++03 (PR #90725)

https://github.com/MitalAshok created https://github.com/llvm/llvm-project/pull/90725 Fixes #90605 >From 0793795ba7d5d5974b1403cd6ead0221fc20c5bb Mon Sep 17 00:00:00 2001 From: Mital Ashok Date: Wed, 1 May 2024 12:45:54 +0100 Subject: [PATCH] [Clang] Ensure "=default"ed function can be

[clang] [Clang] [C++26] Implement P2573R2: `= delete("should have a reason");` (PR #86526)

@@ -2280,18 +2294,18 @@ class FunctionDecl : public DeclaratorDecl, /// Returns whether this specific declaration of the function has a body. bool doesThisDeclarationHaveABody() const { -return (!FunctionDeclBits.HasDefaultedFunctionInfo && Body) || +return

[clang] [clang] Implement CWG2851: floating-point conversions in converted constant expressions (PR #90387)

@@ -67,6 +68,69 @@ void B::g() requires true; } // namespace cwg2847 +namespace cwg2851 { // cwg2851: 19 + +#if __cplusplus >= 202002L +template struct Val { static constexpr T value = v; }; + + +// Floating-point promotions + +static_assert(Val::value == 0.0L);

[clang] [clang] Implement CWG2851: floating-point conversions in converted constant expressions (PR #90387)

https://github.com/MitalAshok updated https://github.com/llvm/llvm-project/pull/90387 >From 77cb28e6faf95f5beb3fadc225cb5f0525b3dfe6 Mon Sep 17 00:00:00 2001 From: Mital Ashok Date: Sun, 28 Apr 2024 09:48:47 +0100 Subject: [PATCH] [clang] Implement CWG2851: floating-point conversions in

[clang] [Clang] Reuse tail-padding for more types that are not POD for the purpose of layout (PR #90462)

MitalAshok wrote: Some choices I've made: * Removed `TargetCXXABI::TailPaddingUseRules` and `TargetCXXABI::getTailPaddingUseRules()`. Now there are 5 distinct tail padding rules (7 if you count tail padding rules that change with `-fclang-abi-compat=18.0`), and it was only used in the

[clang] [Clang] Reuse tail-padding for more types that are not POD for the purpose of layout (PR #90462)

https://github.com/MitalAshok created https://github.com/llvm/llvm-project/pull/90462 This will be done for types with over-large bitfields and potentially-overlapping ([[no_unique_address]]) members Compatible with old Clang 18 semantics with -fclang-abi-compat Fixes #50766 >From

[clang] [clang] Implement CWG2851: floating-point conversions in converted constant expressions (PR #90387)

https://github.com/MitalAshok updated https://github.com/llvm/llvm-project/pull/90387 >From 0b8176cf2171da0ce780c15131e19a24473a6989 Mon Sep 17 00:00:00 2001 From: Mital Ashok Date: Sun, 28 Apr 2024 09:48:47 +0100 Subject: [PATCH] [clang] Implement CWG2851: floating-point conversions in

[clang] [clang] Implement CWG2851: floating-point conversions in converted constant expressions (PR #90387)

@@ -6229,7 +6231,37 @@ static ExprResult BuildConvertedConstantExpression(Sema , Expr *From, if (Result.isInvalid()) return Result; - // Check for a narrowing implicit conversion. + if (SCS->Second == ICK_Floating_Conversion) { MitalAshok wrote:

[clang] [clang] Implement CWG2851: floating-point conversions in converted constant expressions (PR #90387)

MitalAshok wrote: Waiting on #90352 because it's not on the cxx_dr_status page yet (`make_dr_status` doesn't do anything) https://github.com/llvm/llvm-project/pull/90387 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[clang] [clang] Implement CWG2851: floating-point conversions in converted constant expressions (PR #90387)

https://github.com/MitalAshok updated https://github.com/llvm/llvm-project/pull/90387 >From 13e2943dea677daf8976ab55a673d43982ac8a4c Mon Sep 17 00:00:00 2001 From: Mital Ashok Date: Sun, 28 Apr 2024 09:48:47 +0100 Subject: [PATCH] [clang] Implement CWG2851: floating-point conversions in

[clang] [clang] Implement CWG2851: floating-point conversions in converted constant expressions (PR #90387)

https://github.com/MitalAshok updated https://github.com/llvm/llvm-project/pull/90387 >From a87399f8a41bb7d9a61c2d44c75836d86c6b4c38 Mon Sep 17 00:00:00 2001 From: Mital Ashok Date: Sun, 28 Apr 2024 09:48:47 +0100 Subject: [PATCH] [clang] Implement CWG2851: floating-point conversions in

[clang] [clang] Implement CWG2851: floating-point conversions in converted constant expressions (PR #90387)

https://github.com/MitalAshok created https://github.com/llvm/llvm-project/pull/90387 https://cplusplus.github.io/CWG/issues/2851.html The only time the target type for a converted constant expression is a floating-point type is in a NTTP, so this only affects C++20+. >From

[clang] [SemaCXX] Qualified functions can't decay into pointers (PR #90353)

https://github.com/MitalAshok created https://github.com/llvm/llvm-project/pull/90353 Fixes #27059 Dependent function parameters, template parameters and exception declarations that have qualified function types now error instead of silently decaying into an invalid pointer type. Also fix

[clang] [clang] [SemaCXX] Implement CWG2627 Bit-fields and narrowing conversions (PR #78112)

MitalAshok wrote: New version gives a pedantic warning if this is used before C++23 (and it is a substitution failure before C++23) https://github.com/llvm/llvm-project/pull/78112 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[clang] [clang] [SemaCXX] Implement CWG2627 Bit-fields and narrowing conversions (PR #78112)

https://github.com/MitalAshok updated https://github.com/llvm/llvm-project/pull/78112 >From 92f8720e3d21521b589d5291f086a2f32b87bfe0 Mon Sep 17 00:00:00 2001 From: Mital Ashok Date: Sun, 14 Jan 2024 19:52:31 + Subject: [PATCH] [clang] [SemaCXX] Implement CWG2627 Bit-fields and narrowing

[clang] [SemaCXX] Implement CWG2351 `void{}` (PR #78060)

https://github.com/MitalAshok updated https://github.com/llvm/llvm-project/pull/78060 >From 6ed7cad5d4993603221c3d9a777463675d69643b Mon Sep 17 00:00:00 2001 From: Mital Ashok Date: Sat, 13 Jan 2024 18:03:15 + Subject: [PATCH] [SemaCXX] Implement CWG2351 `void{}` ---

[clang] [SemaCXX] Implement CWG2351 `void{}` (PR #78060)

@@ -1600,12 +1600,25 @@ Sema::BuildCXXTypeConstructExpr(TypeSourceInfo *TInfo, return ExprError(Diag(TyBeginLoc, diag::err_init_for_function_type) << Ty << FullRange); - // C++17 [expr.type.conv]p2: - // If the type is cv void and the

[clang] [SemaCXX] Recognise initializer_list injected-class-name types as initializer_lists (PR #90210)

MitalAshok wrote: Original Differential revision: https://reviews.llvm.org/D156064 Doesn't appear that anything has changed since, just rebased the changes. https://github.com/llvm/llvm-project/pull/90210 ___ cfe-commits mailing list

[clang] [SemaCXX] Recognise initializer_list injected-class-name types as initializer_lists (PR #90210)

https://github.com/MitalAshok created https://github.com/llvm/llvm-project/pull/90210 This allows the implicitly-generated deduction guide for the copy constructor to be recognised as an initializer-list constructor, allowing CTAD for std::initializer_list >From

[clang] [SemaCXX] Make __builtin_addressof more like std::addressof (PR #78035)

https://github.com/MitalAshok converted_to_draft https://github.com/llvm/llvm-project/pull/78035 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [libcxx] [SemaCXX] Implement CWG2137 (list-initialization from objects of the same type) (PR #77768)

MitalAshok wrote: With the standard as is, `B(A)` should be a better match because of [[over.ics.list]p(7.1)](https://wg21.link/over.ics.list#7.1), it is an Exact Match, and `B(std::vector)` is a user defined conversion. With the current CWG2311 fix, the call to `B(A)` is an Exact Match

[libcxx] [clang] [SemaCXX] Implement CWG2137 (list-initialization from objects of the same type) (PR #77768)

MitalAshok wrote: @cor3ntin Still waiting for Windows checks, but yes, could you merge if you please https://github.com/llvm/llvm-project/pull/77768 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[libcxx] [clang] [SemaCXX] Implement CWG2137 (list-initialization from objects of the same type) (PR #77768)

MitalAshok wrote: @cor3ntin It looks like it was in an unrelated file. I've rebased and the format check is passing now https://github.com/llvm/llvm-project/pull/77768 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[libcxx] [clang] [SemaCXX] Implement CWG2137 (list-initialization from objects of the same type) (PR #77768)

https://github.com/MitalAshok updated https://github.com/llvm/llvm-project/pull/77768 >From 644ec10fc357f70ca8af94ae6544e9631021eb5e Mon Sep 17 00:00:00 2001 From: Mital Ashok Date: Sat, 22 Jul 2023 20:07:00 +0100 Subject: [PATCH 1/2] [SemaCXX] Implement CWG2137 (list-initialization from

[clang] [Clang] fix static operator()/[] call not evaluating object (PR #78356)

MitalAshok wrote: This pull request changes `E(...)` to produce the same AST as `E.operator()(...)`, which is similar to `E.f(...)` for a static member function `f`. But the linked #68485 changes this to CXXOperatorCallExpr, which is more appropriate since it is used for non-member call

[clang] [Clang] fix static operator()/[] call not evaluating object (PR #78356)

https://github.com/MitalAshok converted_to_draft https://github.com/llvm/llvm-project/pull/78356 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] fix static operator()/[] call not evaluating object (PR #78356)

@@ -598,3 +600,27 @@ namespace B { } void g(B::X x) { A::f(x); } } + +namespace static_operator { +#if __cplusplus >= 201703L MitalAshok wrote: No way to modify things in a C++11/14 constexpr function (`++x` is not a constant expression), so no way to make a

[clang] [clang] Fix parenthesized list initialization of arrays not working with `new` (PR #76976)

https://github.com/MitalAshok edited https://github.com/llvm/llvm-project/pull/76976 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Fix parenthesized list initialization of arrays not working with `new` (PR #76976)

@@ -1561,16 +1577,21 @@ llvm::Value *CodeGenFunction::EmitCXXNewExpr(const CXXNewExpr *E) { // 1. Build a call to the allocation function. FunctionDecl *allocator = E->getOperatorNew(); - // If there is a brace-initializer, cannot allocate fewer elements than inits. +

[clang] [clang] Fix parenthesized list initialization of arrays not working with `new` (PR #76976)

@@ -1073,7 +1075,7 @@ void CodeGenFunction::EmitNewArrayInitializer( return; } -InitListElements = ILE->getNumInits(); +InitListElements = ILE ? ILE->getNumInits() : CPLIE->getInitExprs().size(); MitalAshok wrote: ```suggestion ArrayRef

[clang] [Clang] fix static operator()/[] call not evaluating object (PR #78356)

https://github.com/MitalAshok updated https://github.com/llvm/llvm-project/pull/78356 >From c6d4aca37bf7ede785313135abdad986d9cd783a Mon Sep 17 00:00:00 2001 From: Mital Ashok Date: Tue, 16 Jan 2024 21:42:01 + Subject: [PATCH] [Clang] fix static operator()/[] call not evaluating object

[clang] [Clang] fix static operator()/[] call not evaluating object (PR #78356)

https://github.com/MitalAshok created https://github.com/llvm/llvm-project/pull/78356 Fixes #78355 >From 08c7087d4b40a915f123ba3c448a6ca3233af6a1 Mon Sep 17 00:00:00 2001 From: Mital Ashok Date: Tue, 16 Jan 2024 21:42:01 + Subject: [PATCH] [Clang] fix static operator()/[] call not

[clang] [SemaCXX] Make __builtin_addressof more like std::addressof (PR #78035)

https://github.com/MitalAshok updated https://github.com/llvm/llvm-project/pull/78035 >From 33af5fc0a2e1ec2168a1609508cb119034801908 Mon Sep 17 00:00:00 2001 From: Mital Ashok Date: Sat, 13 Jan 2024 10:48:21 + Subject: [PATCH] [SemaCXX] Make __builtin_addressof more like std::addressof

[clang] [clang] Fix direct-initialization with new expressions for arrays (PR #78201)

https://github.com/MitalAshok closed https://github.com/llvm/llvm-project/pull/78201 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Fix direct-initialization with new expressions for arrays (PR #78201)

MitalAshok wrote: Yeah #76976 supersedes this. I would still recommend removing `diag::err_new_array_init_args` if only so: ```c++ int x[2](1, 2); int* y = new int[2](1, 2); ``` have similar error messages. https://github.com/llvm/llvm-project/pull/78201

[clang] [clang] Fix direct-initialization with new expressions for arrays (PR #78201)

https://github.com/MitalAshok converted_to_draft https://github.com/llvm/llvm-project/pull/78201 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Fix direct-initialization with new expressions for arrays (PR #78201)

https://github.com/MitalAshok updated https://github.com/llvm/llvm-project/pull/78201 >From 730f7159c04cbb83fa18f50e8db32f6c5295ef6f Mon Sep 17 00:00:00 2001 From: Mital Ashok Date: Mon, 15 Jan 2024 18:31:06 + Subject: [PATCH 1/2] [clang] Fix direct-initialization with new expressions for

[clang] [clang] Fix direct-initialization with new expressions for arrays (PR #78201)

https://github.com/MitalAshok created https://github.com/llvm/llvm-project/pull/78201 Fixes #78183 Just removed the check entirely. The diagnostic issued for trying to initialize an array (`array initializer must be an initializer list`) is much clearer (than `array 'new' cannot have

[clang] [Clang] Implement CWG2598: Union of non-literal types (PR #78195)

@@ -1383,6 +1383,34 @@ void CXXRecordDecl::addedMember(Decl *D) { } } +bool CXXRecordDecl::isLiteral() const { + const LangOptions = getLangOpts(); + if (!(LangOpts.CPlusPlus20 ? hasConstexprDestructor() + : hasTrivialDestructor())) +

[clang] [clang] [SemaCXX] Implement CWG2627 Bit-fields and narrowing conversions (PR #78112)

https://github.com/MitalAshok updated https://github.com/llvm/llvm-project/pull/78112 >From 12307d487a956896f283aebf73cdb9b95587d068 Mon Sep 17 00:00:00 2001 From: Mital Ashok Date: Sun, 14 Jan 2024 19:52:31 + Subject: [PATCH] [clang] [SemaCXX] Implement CWG2627 Bit-fields and narrowing

[clang] [clang] [SemaCXX] Implement CWG2627 Bit-fields and narrowing conversions (PR #78112)

https://github.com/MitalAshok created https://github.com/llvm/llvm-project/pull/78112 [CWG2627](https://wg21.link/CWG2627) I've implemented this to apply to C++11 to 20 as well without a warning. Should this be a SFINAE-able error before C++23? (It isn't currently) >From

[clang] [SemaCXX] Implement CWG2351 `void{}` (PR #78060)

https://github.com/MitalAshok updated https://github.com/llvm/llvm-project/pull/78060 >From b33b2bc24ff0af7b2cb0f740826885f1f2dafb49 Mon Sep 17 00:00:00 2001 From: Mital Ashok Date: Sat, 13 Jan 2024 18:03:15 + Subject: [PATCH] [SemaCXX] Implement CWG2351 `void{}` ---

[clang] [SemaCXX] Implement CWG2351 `void{}` (PR #78060)

MitalAshok wrote: Looking at other places, it looks like init-list stuff is guarded behind `getLangOpts().CPlusPlus11`, so I'll add that check. It looks like this DR is CD5 (after C++17, applies to C++17), but `void{}` in C++11/14 without a warning seems fine. As for "regular tests", do you

[clang] [SemaCXX] Implement CWG2351 `void{}` (PR #78060)

MitalAshok wrote: Initializer list syntax isn't available in C++98 mode (even as an extension? I can't find the option) Even so, as a defect report it should apply to all prior C++ versions. https://github.com/llvm/llvm-project/pull/78060 ___

[clang] [SemaCXX] Implement CWG2351 `void{}` (PR #78060)

https://github.com/MitalAshok created https://github.com/llvm/llvm-project/pull/78060 As per [CWG2351](https://wg21.link/CWG2351), allow `void{}`, treated the same as `void()`: a prvalue expression of type `void` that performs no initialization. Note that the AST for the expression `T{}`

[clang] [libcxx] [SemaCXX] Implement CWG2137 (list-initialization from objects of the same type) (PR #77768)

@@ -132,6 +142,36 @@ namespace dr2126 { // dr2126: 12 #endif } +namespace dr2137 { // dr2137: 18 +#if __cplusplus >= 201103L + struct Q { +Q(); +Q(Q&&); +Q(std::initializer_list) = delete; // since-cxx11-note 2 {{has been explicitly marked deleted here}} + }; +

[libcxx] [clang] [SemaCXX] Implement CWG2137 (list-initialization from objects of the same type) (PR #77768)

https://github.com/MitalAshok updated https://github.com/llvm/llvm-project/pull/77768 >From 344366c3f749c43376aca09c5bd563ec823b76f9 Mon Sep 17 00:00:00 2001 From: Mital Ashok Date: Sat, 22 Jul 2023 20:07:00 +0100 Subject: [PATCH 1/2] [SemaCXX] Implement CWG2137 (list-initialization from

[libcxx] [clang] [SemaCXX] Implement CWG2137 (list-initialization from objects of the same type) (PR #77768)

https://github.com/MitalAshok updated https://github.com/llvm/llvm-project/pull/77768 >From 7b6bd8158ecc4645e26ec2f6fd6e7c5215bb038a Mon Sep 17 00:00:00 2001 From: Mital Ashok Date: Sat, 22 Jul 2023 20:07:00 +0100 Subject: [PATCH 1/2] [SemaCXX] Implement CWG2137 (list-initialization from

[clang] [SemaCXX] Make __builtin_addressof more like std::addressof (PR #78035)

https://github.com/MitalAshok created https://github.com/llvm/llvm-project/pull/78035 Fixes #77928 There are a few places which expect that, if for an expression `E->getType()->isBuiltinType(BuiltinType::Overload)`, then `E` must be an `OverloadExpr` or a `UnaryOperator` where

[clang] [libcxx] [SemaCXX] Implement CWG2137 (list-initialization from objects of the same type) (PR #77768)

https://github.com/MitalAshok updated https://github.com/llvm/llvm-project/pull/77768 >From 696d4f964805d1af04d4f94dbc8f47adfbc02428 Mon Sep 17 00:00:00 2001 From: Mital Ashok Date: Sat, 22 Jul 2023 20:07:00 +0100 Subject: [PATCH 1/2] [SemaCXX] Implement CWG2137 (list-initialization from

[clang] [libcxx] [SemaCXX] Implement CWG2137 (list-initialization from objects of the same type) (PR #77768)

https://github.com/MitalAshok created https://github.com/llvm/llvm-project/pull/77768 Closes #77638, #24186 Rebased from , see there for more information. Implements wording change in [CWG2137](https://wg21.link/CWG2137) in the first commit. This also