[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 implem

[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 objec

[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 becaus

[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 `cast(E)->getOp

[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 objec

[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 objec

[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}} + }; +

[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{}` look

[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 ___ cfe-co

[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 m

[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/docs/ReleaseNot

[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 ba22259dfed861e6d339

[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 co

[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 &LangOpts = getLangOpts(); + if (!(LangOpts.CPlusPlus20 ? hasConstexprDestructor() + : hasTrivialDestructor())) +

[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 initiali

[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 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)

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 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] [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 Pro

[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 evaluati

[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 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 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)

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 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 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)

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 opera

[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 objec

[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 https://lists.llvm.org/cgi-

[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 https://lists.llvm.org/cgi-bin/mailman/listinf

[clang] [clang] Warn when builtin names are used outside of invocations (PR #96097)

MitalAshok wrote: Looks like `!__is_identifier()` is used instead of `__has_builtin` sometimes. With this patch, `__is_identifier()` is true because there's no lparen after the name In libc++: 7f302f220e7b8727ed1bf8832dcc2d87b897e527 (Pretty easy fix to replace `__has_keyword(__reference_binds

[clang] [clang][NFC] Use range-based for loops (PR #96831)

https://github.com/MitalAshok approved this pull request. LGTM https://github.com/llvm/llvm-project/pull/96831 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Warn when builtin names are used outside of invocations (PR #96097)

MitalAshok wrote: What if we went in the other direction? We want to deprecate `__is_pointer` as an identifier, so only make it an identifier when it is being used by libstdc++ as an identifier. libstdc++ usage looks something like: ```c++ // type template template struct __is_pointer; templat

[clang] [NFC] [Clang] Some core issues have changed status from tentatively ready -> ready / review (PR #97200)

https://github.com/MitalAshok created https://github.com/llvm/llvm-project/pull/97200 Also classes the "ready" status similarly to "tentatively ready" in make_cxx_dr_status >From 0dea95701ca4dfca9b7d0bd889003fc35aa3017e Mon Sep 17 00:00:00 2001 From: Mital Ashok Date: Sun, 30 Jun 2024 10:39:

[clang] [Clang] [C23] Implement N2653: u8 strings are char8_t[] (PR #97208)

https://github.com/MitalAshok created https://github.com/llvm/llvm-project/pull/97208 https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2653.htm Closes #97202 >From ef0072d1fc9b14f7ee657fa95f44a686b78b525a Mon Sep 17 00:00:00 2001 From: Mital Ashok Date: Sun, 30 Jun 2024 12:07:54 +0100 Subje

[clang] [Clang] [C23] Implement N2653: u8 strings are char8_t[] (PR #97208)

MitalAshok wrote: CC @AaronBallman Also the clang-format issues are intentional to fit the style of the surrounding lines https://github.com/llvm/llvm-project/pull/97208 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/c

[clang] [Clang] Warn with -Wpre-c23-compat instead of -Wpre-c++17-compat for u8 character literals in C23 (PR #97210)

https://github.com/MitalAshok created https://github.com/llvm/llvm-project/pull/97210 None >From c6ee783243e1888074778e2cb6de05df41cc8333 Mon Sep 17 00:00:00 2001 From: Mital Ashok Date: Sun, 30 Jun 2024 12:55:04 +0100 Subject: [PATCH] [Clang] Warn with -Wpre-c23-compat instead of -Wpre-c++17

[clang] [NFC] [Clang] Some core issues have changed status from tentatively ready -> ready / review (PR #97200)

https://github.com/MitalAshok updated https://github.com/llvm/llvm-project/pull/97200 >From 0dea95701ca4dfca9b7d0bd889003fc35aa3017e Mon Sep 17 00:00:00 2001 From: Mital Ashok Date: Sun, 30 Jun 2024 10:39:15 +0100 Subject: [PATCH 1/8] [NFC] [Clang] Some core issues have changed status from ten

[clang] [NFC] [Clang] Some core issues have changed status from tentatively ready -> ready / review (PR #97200)

@@ -111,7 +111,7 @@ struct D : N::B { #endif } // namespace cwg2857 -namespace cwg2858 { // cwg2858: 19 tentatively ready 2024-04-05 +namespace cwg2858 { // cwg2858: 19 ready 2024-04-05 MitalAshok wrote: The date of the proposed resolution did not change for

[clang] [NFC] [Clang] Some core issues have changed status from tentatively ready -> ready / review (PR #97200)

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

[clang] [NFC] [Clang] Some core issues have changed status from tentatively ready -> ready / review (PR #97200)

https://github.com/MitalAshok updated https://github.com/llvm/llvm-project/pull/97200 >From 0dea95701ca4dfca9b7d0bd889003fc35aa3017e Mon Sep 17 00:00:00 2001 From: Mital Ashok Date: Sun, 30 Jun 2024 10:39:15 +0100 Subject: [PATCH 1/9] [NFC] [Clang] Some core issues have changed status from ten

[clang] [Clang] [C23] Implement N2653: u8 strings are char8_t[] (PR #97208)

@@ -1342,8 +1342,10 @@ static void InitializePredefinedMacros(const TargetInfo &TI, getLockFreeValue(TI.get##Type##Width(), TI)); DEFINE_LOCK_FREE_MACRO(BOOL, Bool); DEFINE_LOCK_FREE_MACRO(CHAR, Char); -if (LangOpts.Char8) - DEFINE_LOCK_F

[clang] [Clang] [C23] Implement N2653: u8 strings are char8_t[] (PR #97208)

https://github.com/MitalAshok updated https://github.com/llvm/llvm-project/pull/97208 >From ef0072d1fc9b14f7ee657fa95f44a686b78b525a Mon Sep 17 00:00:00 2001 From: Mital Ashok Date: Sun, 30 Jun 2024 12:07:54 +0100 Subject: [PATCH 1/3] [Clang] [C23] Implement N2653: u8 strings are char8_t[] ---

[clang] [Clang] [C23] Implement N2653: u8 strings are char8_t[] (PR #97208)

@@ -104,6 +107,7 @@ typedef _Atomic(long) atomic_long; typedef _Atomic(unsigned long) atomic_ulong; typedef _Atomic(long long) atomic_llong; typedef _Atomic(unsigned long long) atomic_ullong; +typedef _Atomic(unsigned char) atomic_char8_t; type

[clang] [NFC] [Clang] Some core issues have changed status from tentatively ready -> ready / review (PR #97200)

https://github.com/MitalAshok updated https://github.com/llvm/llvm-project/pull/97200 >From 0dea95701ca4dfca9b7d0bd889003fc35aa3017e Mon Sep 17 00:00:00 2001 From: Mital Ashok Date: Sun, 30 Jun 2024 10:39:15 +0100 Subject: [PATCH 01/10] [NFC] [Clang] Some core issues have changed status from t

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

MitalAshok wrote: I'm waiting to rebase on #97403 to remove the libc++ component of this now https://github.com/llvm/llvm-project/pull/94355 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-com

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

MitalAshok wrote: Is there anything else that needs to be done for this? Also, thanks for all the reviews and help on this! https://github.com/llvm/llvm-project/pull/78060 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/

[clang] [Clang] [C23] Implement N2653: u8 strings are char8_t[] (PR #97208)

@@ -104,6 +107,7 @@ typedef _Atomic(long) atomic_long; typedef _Atomic(unsigned long) atomic_ulong; typedef _Atomic(long long) atomic_llong; typedef _Atomic(unsigned long long) atomic_ullong; +typedef _Atomic(unsigned char) atomic_char8_t; type

[clang] [Clang] [C23] Implement N2653: u8 strings are char8_t[] (PR #97208)

https://github.com/MitalAshok updated https://github.com/llvm/llvm-project/pull/97208 >From ef0072d1fc9b14f7ee657fa95f44a686b78b525a Mon Sep 17 00:00:00 2001 From: Mital Ashok Date: Sun, 30 Jun 2024 12:07:54 +0100 Subject: [PATCH 1/5] [Clang] [C23] Implement N2653: u8 strings are char8_t[] ---

[clang] [Clang] [C23] Implement N2653: u8 strings are char8_t[] (PR #97208)

@@ -1165,6 +1165,8 @@ static void InitializePredefinedMacros(const TargetInfo &TI, DefineType("__WCHAR_TYPE__", TI.getWCharType(), Builder); DefineType("__WINT_TYPE__", TI.getWIntType(), Builder); DefineTypeSizeAndWidth("__SIG_ATOMIC", TI.getSigAtomicType(), TI, Builder)

[clang] [Clang] Warn on backslash-newline-EOF (PR #97585)

https://github.com/MitalAshok created https://github.com/llvm/llvm-project/pull/97585 C99 §5.1.1.2p2, C23 §5.1.1.2p2 > A source file that is not empty shall end in a new-line character, which > shall not be immediately preceded by a backslash character before any such > splicing takes place.

[clang] [Clang] [C23] Implement N2653: u8 strings are char8_t[] (PR #97208)

@@ -1165,6 +1165,8 @@ static void InitializePredefinedMacros(const TargetInfo &TI, DefineType("__WCHAR_TYPE__", TI.getWCharType(), Builder); DefineType("__WINT_TYPE__", TI.getWIntType(), Builder); DefineTypeSizeAndWidth("__SIG_ATOMIC", TI.getSigAtomicType(), TI, Builder)

[clang] [Clang] Warn on backslash-newline-EOF (PR #97585)

https://github.com/MitalAshok updated https://github.com/llvm/llvm-project/pull/97585 >From 8af656659b79d76c971b01f1f4c14dc7315565b8 Mon Sep 17 00:00:00 2001 From: Mital Ashok Date: Fri, 21 Jun 2024 18:55:38 +0100 Subject: [PATCH 1/2] [Clang] Warn on backslash-newline-EOF --- clang/docs/Relea

[clang] [Clang] Warn on backslash-newline-EOF (PR #97585)

https://github.com/MitalAshok updated https://github.com/llvm/llvm-project/pull/97585 >From 8af656659b79d76c971b01f1f4c14dc7315565b8 Mon Sep 17 00:00:00 2001 From: Mital Ashok Date: Fri, 21 Jun 2024 18:55:38 +0100 Subject: [PATCH 1/3] [Clang] Warn on backslash-newline-EOF --- clang/docs/Relea

[clang] [Clang] Warn on backslash-newline-EOF (PR #97585)

https://github.com/MitalAshok updated https://github.com/llvm/llvm-project/pull/97585 >From 8af656659b79d76c971b01f1f4c14dc7315565b8 Mon Sep 17 00:00:00 2001 From: Mital Ashok Date: Fri, 21 Jun 2024 18:55:38 +0100 Subject: [PATCH 1/4] [Clang] Warn on backslash-newline-EOF --- clang/docs/Relea

[clang] [Clang] Warn on backslash-newline-EOF (PR #97585)

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

[clang] [Clang] Warn on backslash-newline-EOF (PR #97585)

https://github.com/MitalAshok updated https://github.com/llvm/llvm-project/pull/97585 >From 8af656659b79d76c971b01f1f4c14dc7315565b8 Mon Sep 17 00:00:00 2001 From: Mital Ashok Date: Fri, 21 Jun 2024 18:55:38 +0100 Subject: [PATCH 1/5] [Clang] Warn on backslash-newline-EOF --- clang/docs/Relea

[clang] [Clang] Warn on backslash-newline-EOF (PR #97585)

https://github.com/MitalAshok updated https://github.com/llvm/llvm-project/pull/97585 >From 8af656659b79d76c971b01f1f4c14dc7315565b8 Mon Sep 17 00:00:00 2001 From: Mital Ashok Date: Fri, 21 Jun 2024 18:55:38 +0100 Subject: [PATCH 1/6] [Clang] Warn on backslash-newline-EOF --- clang/docs/Relea

[clang] [Clang] Warn on backslash-newline-EOF (PR #97585)

@@ -0,0 +1,11 @@ +// RUN: %clang_cc1 -std=c++11 -pedantic-errors -verify=expected %s -E | FileCheck %s --strict-whitespace --allow-empty MitalAshok wrote: Fixed now, thanks https://github.com/llvm/llvm-project/pull/97585

[clang] [Clang] [C23] Fix typeof_unqual for qualified array types (PR #92767)

https://github.com/MitalAshok updated https://github.com/llvm/llvm-project/pull/92767 >From f87cb4c754a477515746e2ac2f8906b93ccd1fe3 Mon Sep 17 00:00:00 2001 From: Mital Ashok Date: Mon, 20 May 2024 15:58:58 +0100 Subject: [PATCH 1/5] [Clang] [C23] Fix typeof_unqual for qualified array types P

[clang] [Clang] Warn on backslash-newline-EOF (PR #97585)

@@ -3183,8 +3193,35 @@ bool Lexer::LexEndOfFile(Token &Result, const char *CurPtr) { DiagID = diag::ext_no_newline_eof; } -Diag(BufferEnd, DiagID) - << FixItHint::CreateInsertion(EndLoc, "\n"); +if (LastNewline.empty()) { + Diag(BufferEnd, DiagID)

[clang] [Clang] Warn on backslash-newline-EOF (PR #97585)

@@ -647,6 +647,8 @@ Improvements to Clang's diagnostics - Clang now shows implicit deduction guides when diagnosing overload resolution failure. #GH92393. +- Clang now emits ``-Wnewline-eof`` when the last newline is deleted by a preceding backslash. #GH41571. -

[clang] [Clang] Warn on backslash-newline-EOF (PR #97585)

https://github.com/MitalAshok updated https://github.com/llvm/llvm-project/pull/97585 >From 8af656659b79d76c971b01f1f4c14dc7315565b8 Mon Sep 17 00:00:00 2001 From: Mital Ashok Date: Fri, 21 Jun 2024 18:55:38 +0100 Subject: [PATCH 1/8] [Clang] Warn on backslash-newline-EOF --- clang/docs/Relea

[clang] [Clang] Warn on backslash-newline-EOF (PR #97585)

@@ -3183,8 +3193,35 @@ bool Lexer::LexEndOfFile(Token &Result, const char *CurPtr) { DiagID = diag::ext_no_newline_eof; } -Diag(BufferEnd, DiagID) - << FixItHint::CreateInsertion(EndLoc, "\n"); +if (LastNewline.empty()) { + Diag(BufferEnd, DiagID)

[clang] [Clang] Warn on backslash-newline-EOF (PR #97585)

https://github.com/MitalAshok updated https://github.com/llvm/llvm-project/pull/97585 >From 8af656659b79d76c971b01f1f4c14dc7315565b8 Mon Sep 17 00:00:00 2001 From: Mital Ashok Date: Fri, 21 Jun 2024 18:55:38 +0100 Subject: [PATCH 1/9] [Clang] Warn on backslash-newline-EOF --- clang/docs/Relea

[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 1/4] [Clang] Fix Microsoft ABI inheritance model when member poi

[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 1/5] [Clang] Fix Microsoft ABI inheritance model when member poi

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

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

[clang] [Clang] [C23] Implement N2653: u8 strings are char8_t[] (PR #97208)

https://github.com/MitalAshok updated https://github.com/llvm/llvm-project/pull/97208 >From ef0072d1fc9b14f7ee657fa95f44a686b78b525a Mon Sep 17 00:00:00 2001 From: Mital Ashok Date: Sun, 30 Jun 2024 12:07:54 +0100 Subject: [PATCH 1/6] [Clang] [C23] Implement N2653: u8 strings are char8_t[] ---

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

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

[clang] [Clang] Make -fcomplete-member-pointers the same as using the Microsoft C++ ABI (PR #98010)

https://github.com/MitalAshok created https://github.com/llvm/llvm-project/pull/98010 This essentially adds a new language mode `CompleteMemberPointers`. With the Microsoft C++ ABI, this will always be true. Otherwise, it can be enabled with `-fcomplete-member-pointers`, and will work the same

[clang] [Clang] Make -fcomplete-member-pointers the same as using the Microsoft C++ ABI (PR #98010)

MitalAshok wrote: TODO: - Tests for `-Wincomplete-member-pointer` - Possibly do something else about `-fsanitize=cfi-mfcall`. `-Wincomplete-member-pointer` is too broad, for the sanitizer we only care about a call to a pointer to member function. The warning could also be emitted here: htt

[clang] [Clang] Make -fcomplete-member-pointers the same as using the Microsoft C++ ABI (PR #98010)

https://github.com/MitalAshok updated https://github.com/llvm/llvm-project/pull/98010 >From 7cc8f4c8c4e39db82ff8f7cb7164a94abf6b2029 Mon Sep 17 00:00:00 2001 From: Mital Ashok Date: Mon, 8 Jul 2024 10:36:35 +0100 Subject: [PATCH] [Clang] Make -fcomplete-member-pointers the same as using the Mi

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

MitalAshok wrote: > Will that include fixing clang incorrectly warning when an inheritance model > is explicitly specified? Yes, I have a WIP of it here #98010 where that doesn't get a warning (https://github.com/llvm/llvm-project/pull/98010/files#diff-bec1ae40e5793adbd61e7a9dc41a4715a06e27888

[clang] [clang-tools-extra] [Clang] Make -fcomplete-member-pointers the same as using the Microsoft C++ ABI (PR #98010)

https://github.com/MitalAshok updated https://github.com/llvm/llvm-project/pull/98010 >From 5163153a122f705c6ed25a372bec6868aa42d0b5 Mon Sep 17 00:00:00 2001 From: Mital Ashok Date: Mon, 8 Jul 2024 10:36:35 +0100 Subject: [PATCH] [Clang] Make -fcomplete-member-pointers the same as using the Mi

[clang] [llvm] [Clang] Fix definition of layout-compatible to ignore empty classes (PR #92103)

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

[clang] [Clang] CWG2749: relational operators involving pointers to void (PR #93046)

https://github.com/MitalAshok updated https://github.com/llvm/llvm-project/pull/93046 >From e1172958f43af7490b5b6e3752a9070265ad17ca Mon Sep 17 00:00:00 2001 From: Mital Ashok Date: Wed, 22 May 2024 16:01:13 +0100 Subject: [PATCH 1/4] [Clang] CWG2749: relational operators involving pointers to

[clang] [Clang] CWG2749: relational operators involving pointers to void (PR #93046)

MitalAshok wrote: @cor3ntin Done! https://github.com/llvm/llvm-project/pull/93046 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] CWG2749: relational operators involving pointers to void (PR #93046)

https://github.com/MitalAshok updated https://github.com/llvm/llvm-project/pull/93046 >From e1172958f43af7490b5b6e3752a9070265ad17ca Mon Sep 17 00:00:00 2001 From: Mital Ashok Date: Wed, 22 May 2024 16:01:13 +0100 Subject: [PATCH 1/5] [Clang] CWG2749: relational operators involving pointers to

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

@@ -13,3 +15,18 @@ template struct S3 { int T::*foo; }; + +template struct Base {}; +struct +S5 // #S5 +: +Base +// expected-error@-1 {{member pointer has incomplete base type 'S5'}} MitalAshok wrote: Yes, that's just how `-fcomplete-member-pointers` works

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

@@ -215,6 +215,14 @@ struct NewUnspecified; SingleTemplate tmpl_single; UnspecTemplate tmpl_unspec; +// Member pointers used in base specifiers force an unspecified inheritance model +struct MemPtrInBase : UnspecTemplate {}; MitalAshok wrote: I see what you

[clang] [Clang][SemaCXX] Preserve qualifiers in derived-to-base cast in defaulted comparison operators (PR #102619)

https://github.com/MitalAshok created https://github.com/llvm/llvm-project/pull/102619 Fixes #102588 >From f47340974464dccae08980a1f8e78f0982169a58 Mon Sep 17 00:00:00 2001 From: Mital Ashok Date: Fri, 9 Aug 2024 15:03:38 +0100 Subject: [PATCH] [Clang][SemaCXX] Preserve qualifiers in derived-t

[clang] [Clang] Check explicit object parameter for defaulted operators properly (PR #100419)

https://github.com/MitalAshok updated https://github.com/llvm/llvm-project/pull/100419 >From 5d2b3fa876c00869a3964081a57ae23563d18175 Mon Sep 17 00:00:00 2001 From: Mital Ashok Date: Wed, 24 Jul 2024 16:58:56 +0100 Subject: [PATCH 1/4] [Clang] Check explicit object param for defaulted relation

[clang] [Clang][SemaCXX] Preserve qualifiers in derived-to-base cast in defaulted comparison operators (PR #102619)

https://github.com/MitalAshok updated https://github.com/llvm/llvm-project/pull/102619 >From fc436186e37ff9852269599c750f8e836aee5e99 Mon Sep 17 00:00:00 2001 From: Mital Ashok Date: Fri, 9 Aug 2024 15:03:38 +0100 Subject: [PATCH] [Clang][SemaCXX] Preserve qualifiers in derived-to-base cast in

[clang] [Clang] Check explicit object parameter for defaulted operators properly (PR #100419)

MitalAshok wrote: @cor3ntin If everything is still good with this could you commit this for me? Thanks! https://github.com/llvm/llvm-project/pull/100419 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/lis

[clang] [clang] Avoid triggering vtable instantiation for C++23 constexpr dtor (PR #102605)

MitalAshok wrote: Does this also fix #92486? https://github.com/llvm/llvm-project/pull/102605 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] Add [[clang::diagnose_specializations]] (PR #101469)

@@ -5408,7 +5408,10 @@ def note_dependent_function_template_spec_discard_reason : Note< "not a member of the enclosing %select{class template|" "namespace; did you mean to explicitly qualify the specialization?}1}0">; def warn_invalid_specialization : Warning< - "%0 shoul

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

MitalAshok wrote: @cor3ntin A `void*` can be a pointer to an object but `void*` is not a pointer-to-object type. `is_object_v` -> `is_object_v || is_void_v` or `!is_function_v` https://github.com/llvm/llvm-project/pull/91895 ___ cfe-commits mailing l

[clang] [clang] Implement `__builtin_is_implicit_lifetime()` (PR #101807)

@@ -5637,6 +5638,27 @@ static bool EvaluateUnaryTypeTrait(Sema &Self, TypeTrait UTT, return false; case UTT_IsTriviallyEqualityComparable: return isTriviallyEqualityComparableType(Self, T, KeyLoc); + case UTT_IsImplicitLifetime: { +DiagnoseVLAInCXXTypeTrait(Self

[clang] [clang] Implement `__builtin_is_implicit_lifetime()` (PR #101807)

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

[clang] [clang] Implement `__builtin_is_implicit_lifetime()` (PR #101807)

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

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

MitalAshok wrote: The feature test macro (`__cpp_lib_is_within_lifetime`) should be defined by the standard library in ``/`` (so libc++ or libstdc++). All that changes for Clang with this patch is `__has_builtin(__builtin_is_within_lifetime)`. P2641R4 doesn't appear to be in [cxx_status](htt

[clang] [NFC] Replace bool <= bool comparison (PR #102948)

https://github.com/MitalAshok created https://github.com/llvm/llvm-project/pull/102948 Closes #102912 >From fea4def3e66e7934718bab9d288094f7cbc5e4b7 Mon Sep 17 00:00:00 2001 From: Mital Ashok Date: Mon, 12 Aug 2024 19:03:53 +0100 Subject: [PATCH] [NFC] Replace bool <= bool --- clang/lib/Sema

[clang] [NFC] Replace bool <= bool comparison (PR #102948)

@@ -542,7 +542,7 @@ NarrowingKind StandardConversionSequence::getNarrowingKind( // If the bit-field width was dependent, it might end up being small // enough to fit in the target type (unless the target type is unsigned // and the source type is signed, in wh

[clang] [NFC] Deduplicate clang::AccessKinds to diagnostic strings (PR #102030)

MitalAshok wrote: @cor3ntin Could you please merge this for me? Thanks https://github.com/llvm/llvm-project/pull/102030 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

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

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

MitalAshok wrote: Hmm. On reading https://eel.is/c++draft/meta.const.eval#4 again, it says: > *Remarks*: During the evaluation of an expression `E` as a core constant > expression, a call to this function is ill-formed unless `p` points to an > object that is usable in constant expressions or

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

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

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

@@ -17160,3 +17184,72 @@ bool Expr::tryEvaluateStrLen(uint64_t &Result, ASTContext &Ctx) const { EvalInfo Info(Ctx, Status, EvalInfo::EM_ConstantFold); return EvaluateBuiltinStrLen(this, Result, Info); } + +namespace { +struct IsWithinLifetimeHandler { + EvalInfo &Info; +

  1   2   3   4   5   >