[PATCH] D151952: [clang] adds `__type_pack_index` so we can get a type's parameter pack index

jwakely added a comment. In D151952#4396485 , @cjdb wrote: > Since we're doing this, it may also be worth checking that `T1s...` are > unique in `T2s...`, which I'd intended to be a separate feature. It seems like it would be more efficient to include

[PATCH] D135238: [clang] adds copy-constructible type-trait builtins

jwakely added inline comments. Comment at: clang/include/clang/Basic/TokenKinds.def:528 +TYPE_TRAIT_1(__is_nothrow_copy_constructible, IsNothrowCopyConstructible, KEYCXX) +TYPE_TRAIT_1(__is_trivially_copy_constructible, IsTriviallyCopyConstructible, KEYCXX)

[PATCH] D131963: [libc++] Add custom clang-tidy checks

jwakely added inline comments. Comment at: libcxx/test/tools/clang_tidy_checks/robust_against_adl.cpp:22 +AST_MATCHER(clang::UnresolvedLookupExpr, isCustomizationPoint) { + // TODO: Are make_error_code and make_error_condition actually customization points? + return

[PATCH] D131963: [libc++] Add custom clang-tidy checks

jwakely added inline comments. Comment at: libcxx/test/tools/clang_tidy_checks/robust_against_adl.cpp:22 +AST_MATCHER(clang::UnresolvedLookupExpr, isCustomizationPoint) { + // TODO: Are make_error_code and make_error_condition actually customization points? + return

[PATCH] D112906: [PowerPC] Emit warning for ieeelongdouble on older GNU toolchain

jwakely added a comment. In D112906#3304925 , @qiucf wrote: > Is that because clang lacks something required by this feature? (for example. > clang-12 doesn't have `__ibm128` and many builtins) If so, clang-14 should > have these fixed. When I

[PATCH] D112906: [PowerPC] Emit warning for ieeelongdouble on older GNU toolchain

jwakely added a comment. > GCC 12 should have proper support for IEEE-754 compliant 128-bit floating > point in libstdc++. Yes, but it's unconditionally disabled when including the headers with Clang. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION

[PATCH] D40319: [libcxx] Support getentropy as a source of randomness for std::random_device

jwakely added subscribers: fweimer, dalias. jwakely added inline comments. Comment at: libcxx/trunk/src/random.cpp:29 +#if defined(_LIBCPP_USING_GETENTROPY) +#include +#elif defined(_LIBCPP_USING_DEV_RANDOM) mcgrathr wrote: > jwakely wrote: > > jwakely wrote: >

[PATCH] D40319: [libcxx] Support getentropy as a source of randomness for std::random_device

jwakely added inline comments. Comment at: libcxx/trunk/src/random.cpp:29 +#if defined(_LIBCPP_USING_GETENTROPY) +#include +#elif defined(_LIBCPP_USING_DEV_RANDOM) jwakely wrote: > musl only declares `getentropy` in `` not ``. Glibc > declares it in both.

[PATCH] D40319: [libcxx] Support getentropy as a source of randomness for std::random_device

jwakely added inline comments. Herald added a subscriber: abrachet. Comment at: libcxx/trunk/src/random.cpp:29 +#if defined(_LIBCPP_USING_GETENTROPY) +#include +#elif defined(_LIBCPP_USING_DEV_RANDOM) musl only declares `getentropy` in `` not ``. Glibc

[PATCH] D102936: [CUDA] Work around compatibility issue with libstdc++ 11.1.0

jwakely accepted this revision. jwakely added a comment. This revision is now accepted and ready to land. LGTM Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D102936/new/ https://reviews.llvm.org/D102936

[PATCH] D102936: [CUDA] Work around compatibility issue with libstdc++ 11.1.0

jwakely requested changes to this revision. jwakely added a comment. This revision now requires changes to proceed. You can't use `__GLIBCXX__` this way. It will be different for different snapshots from the gcc-11 branch. I would just check RELEASE == 11. If `__failed_assertion` is present,

[PATCH] D93377: [Clang] Add __ibm128 type to represent ppc_fp128

jwakely added inline comments. Comment at: clang/lib/AST/ItaniumMangle.cpp:2668 // ::= g # __float128 + // ::= g # __ibm128 // UNSUPPORTED:::= Dd # IEEE 754r decimal floating point (64 bits) steven.zhang wrote: > This

[PATCH] D93377: [Clang] Add __ibm128 type to represent ppc_fp128

jwakely added inline comments. Comment at: clang/lib/Parse/ParseExprCXX.cpp:2245 + case tok::kw___ibm128: +DS.SetTypeSpecType(DeclSpec::TST_ibm128, Loc, PrevSpec, DiagID, Policy); +break; hubert.reinterpretcast wrote: > jwakely wrote: > >

[PATCH] D93377: [Clang] Add __ibm128 type to represent ppc_fp128

jwakely added inline comments. Comment at: clang/lib/Parse/ParseExprCXX.cpp:2245 + case tok::kw___ibm128: +DS.SetTypeSpecType(DeclSpec::TST_ibm128, Loc, PrevSpec, DiagID, Policy); +break; hubert.reinterpretcast wrote: > qiucf wrote: > >

[PATCH] D87974: [Builtin] Add __builtin_zero_non_value_bits.

jwakely added a comment. In D87974#2440533 , @BillyONeal wrote: > Of course if it's already publicly documented for you the horse has > presumably already left the barn which makes the discussion moot? It's not in a shipping release yet. But the point

[PATCH] D87974: [Builtin] Add __builtin_zero_non_value_bits.

jwakely added a comment. In D87974#2438723 , @zoecarver wrote: > In D87974#2438682 , @BillyONeal > wrote: > >>> Are they actually the same, with the same handling of corner cases like >>> unions and tail padding?

[PATCH] D87974: [Builtin] Add __builtin_zero_non_value_bits.

jwakely added a comment. In D87974#2436169 , @BillyONeal wrote: > The name MSFT is already shipping in production is > `__builtin_zero_non_value_bits`. If gcc is already shipping another name in > production I think clang is stuck supporting both names,

[PATCH] D87974: [Builtin] Add __builtin_zero_non_value_bits.

jwakely added a comment. As of a few hours ago, GCC has [`__builtin_clear_padding`](https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#index-_005f_005fbuiltin_005fclear_005fpadding) Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D87974/new/

[PATCH] D68364: Implement C++20's P0784 (More constexpr containers)

jwakely added a comment. In D68364#2293971 , @leonardchan wrote: > Is there a recommended way for working around this? We're using GCC 10.2.1. > Thanks. I don't think your implementation is valid. I think P0784 only allows new-expressions and calls to

[PATCH] D68364: Implement C++20's P0784 (More constexpr containers)

jwakely added inline comments. Comment at: libcxx/include/new:243 # ifdef _LIBCPP_HAS_NO_BUILTIN_OVERLOADED_OPERATOR_NEW_DELETE return ::operator new(__size, __align_val); # else ldionne wrote: > jwakely wrote: > > jwakely wrote: > > > ldionne wrote: > >

[PATCH] D68364: Implement C++20's P0784 (More constexpr containers)

jwakely added inline comments. Comment at: libcxx/include/new:243 # ifdef _LIBCPP_HAS_NO_BUILTIN_OVERLOADED_OPERATOR_NEW_DELETE return ::operator new(__size, __align_val); # else jwakely wrote: > ldionne wrote: > > This breaks GCC (as of GCC 9). I don't

[PATCH] D68364: Implement C++20's P0784 (More constexpr containers)

jwakely added inline comments. Comment at: libcxx/include/new:243 # ifdef _LIBCPP_HAS_NO_BUILTIN_OVERLOADED_OPERATOR_NEW_DELETE return ::operator new(__size, __align_val); # else ldionne wrote: > This breaks GCC (as of GCC 9). I don't know what mechanism

[PATCH] D51262: Implement P0553 and P0556

jwakely added a comment. In D51262#1213514 , @mclow.lists wrote: > I should also mention that as a conforming extension, I have implemented the > non-numeric bit operations for `std::byte` I thought there was a DR or proposal to enable that, but I

[PATCH] D55741: Implementation Feature Test Macros for P0722R3

jwakely added a comment. As it looks like libc++ isn't going to define the type for earlier dialects, libstdc++ doesn't either (which seems right anyway because the names aren't reserved prior to C++20). We now define the type and variable unconditionally for C++2a, but only define the

[PATCH] D55741: Implementation Feature Test Macros for P0722R3

jwakely added a comment. I'd be happy to restrict this to > C++17 only (which is automatically the case when using G++ because there's no `-fdestroying-delete` to enable it, you only get it with `-std=c++2a`, `-std=gnu++2a` etc.) Repository: rC Clang CHANGES SINCE LAST ACTION

[PATCH] D55741: Implementation Feature Test Macros for P0722R3

jwakely added a comment. The simplest solution would be to change libstdc++'s `` to: #if __cplusplus >= 201703L && __cpp_impl_destroying_delete #define __cpp_lib_destroying_delete 201806L Or we could be fancier and do: #if __cplusplus >= 201103L && __cpp_impl_destroying_delete

[PATCH] D46593: Allow copy elision in path concatenation

jwakely added a comment. @chandlerc thanks for catching this. As the original author I agree to contribute this patch to libc++ under the terms of the MIT and the University of Illinois licences, and under the terms of "Apache 2 with LLVM exception" if necessary in future. This permission

[PATCH] D28981: Use GNU-style attributes for several __throw_XXX() functions

jwakely added a comment. The __throw_xxx functions are not part of the public libstdc++ API and whatever Firefox is trying to do with them is not supported by libstdc++ and is undefined behaviour. Make it stop. https://reviews.llvm.org/D28981 ___