Changes in bit

a83004f4 - [libcxx][AIX][z/OS] Remove headers included via `_IBMCPP__`

Mon, 11 Jul 2022 15:05:42 +0000

[libcxx][AIX][z/OS] Remove headers included via `_IBMCPP__`D127650 removed support for non-clang-based XL compilers, but left someof the headers used only by this compiler and included under the__IBMCPP__ macro. This change cleans this up by deleting these headers.Reviewed By: hubert.reinterpretcast, fanbo-mengDifferential Revision: https://reviews.llvm.org/D129491 List of files: /llvm-project-15.0.7/libcxx/include/bit

de4a57cb - [libc++] Re-add transitive includes that had been removed since LLVM 14

Mon, 27 Jun 2022 19:53:41 +0000

[libc++] Re-add transitive includes that had been removed since LLVM 14This commit re-adds transitive includes that had been removed by4cd04d1687f1, c36870c8e79c, a83f4b9cda57, 1458458b558d, 2e2f3158c604,and 489637e66dd3. This should cover almost all the includes that hadbeen removed since LLVM 14 and that would contribute to breaking usercode when releasing LLVM 15.It is possible to disable the inclusion of these headers by defining_LIBCPP_REMOVE_TRANSITIVE_INCLUDES. The intent is that vendors willenable that macro and start fixing downstream issues immediately. Wecan then remove the macro (and the transitive includes) by default ina future release. That way, we will break users only once by removingtransitive includes in bulk instead of doing it bit by bit a everyrelease, which is more disruptive for users.Note 1: The set of headers to re-add was found by re-generating the transitive include test on a checkout of release/14.x, which provided the list of all transitive includes we used to provide.Note 2: Several includes of , , and have been added in this commit. These transitive inclusions were added when we implemented boyer_moore_searcher in .Note 3: This is a best effort patch to try and resolve downstream breakage caused since branching LLVM 14. I wasn't able to perfectly mirror transitive includes in LLVM 14 for a few headers, so I added a release note explaining it. To summarize, adding boyer_moore_searcher created a bunch of circular dependencies, so we have to break backwards compatibility in a few cases.Differential Revision: https://reviews.llvm.org/D128661 List of files: /llvm-project-15.0.7/libcxx/include/bit

21ba9d0b - [libc++][NFC] Merges unused functions in callers.

Tue, 14 Jun 2022 15:47:51 +0000

[libc++][NFC] Merges unused functions in callers.This is a follow up based on a request of @jloser in D127594.As drive-by qualified the function calls in the header.Reviewed By: #libc, EricWFDifferential Revision: https://reviews.llvm.org/D127760 List of files: /llvm-project-15.0.7/libcxx/include/bit

23b10a4a - [libc++][NFC] Use concepts in .

Sun, 12 Jun 2022 10:24:21 +0000

[libc++][NFC] Use concepts in .All supported compilers have concepts support so use that in the C++20functions in .s/_LIBCPP_INLINE_VISIBILITY/_LIBCPP_HIDE_FROM_ABI/ as drive-by fix.Reviewed By: #libc, ldionneDifferential Revision: https://reviews.llvm.org/D127594 List of files: /llvm-project-15.0.7/libcxx/include/bit

385cc25a - [libc++] Ensure that all public C++ headers include <__assert>

Fri, 25 Mar 2022 16:55:36 +0000

[libc++] Ensure that all public C++ headers include <__assert>This patch changes the requirement for getting the declaration of theassertion handler from including <__assert> to including any publicC++ header of the library. Note that C compatibility headers areexcluded because we don't implement all the C headers ourselves --some of them are taken straight from the C library, like assert.h.It also adds a generated test to check it. Furthermore, this newgenerated test is designed in a way that will make it possible toreplace almost all the existing test-generation scripts with thissystem in upcoming patches.Differential Revision: https://reviews.llvm.org/D122506 List of files: /llvm-project-15.0.7/libcxx/include/bit

3347e7d4 - [libc++] [LWG3656] Update the return type of std::bit_width.

Thu, 24 Feb 2022 01:08:28 +0000

[libc++] [LWG3656] Update the return type of std::bit_width.Fixes LWG3656, "Inconsistent bit operations returning a count".https://cplusplus.github.io/LWG/issue3656The fix has been approved for C++23 and left to vendors' discretionin C++20 (but it sounds like everyone's on the same page thatof course it should be DR'ed back to C++20 too).Differential Revision: https://reviews.llvm.org/D120444 List of files: /llvm-project-15.0.7/libcxx/include/bit

f87aa19b - [libc++] Move everything related solely to _LIBCPP_ASSERT to its own file

Mon, 14 Feb 2022 18:41:09 +0000

[libc++] Move everything related solely to _LIBCPP_ASSERT to its own fileThis is the first step towards disentangling the debug mode and assertionsin libc++. This patch doesn't make any functional change: it simply moves_LIBCPP_ASSERT-related stuff to its own file so as to make it clear thatlibc++ assertions and the debug mode are different things. Future patcheswill make it possible to enable assertions without enabling the debugmode.Differential Revision: https://reviews.llvm.org/D119769 List of files: /llvm-project-15.0.7/libcxx/include/bit

fa6b9e40 - [libc++] Normalize all our '#pragma GCC system_header', and regression-test.

Wed, 02 Feb 2022 01:16:40 +0000

[libc++] Normalize all our '#pragma GCC system_header', and regression-test.Now we'll notice if a header forgets to include this magic phrase.Differential Revision: https://reviews.llvm.org/D118800 List of files: /llvm-project-15.0.7/libcxx/include/bit

5675b611 - [libc++] Disable _LIBCPP_DEBUG_ASSERT during constant evaluation

Thu, 16 Dec 2021 13:55:03 +0000

[libc++] Disable _LIBCPP_DEBUG_ASSERT during constant evaluationDisable `_LIBCPP_DEBUG_ASSERT` and debug iterators in during constant evaluationReviewed By: ldionne, #libcSpies: goncharov, libcxx-commitsDifferential Revision: https://reviews.llvm.org/D115788 List of files: /llvm-project-15.0.7/libcxx/include/bit

1dc62f26 - [libc++] Implement P1272R4 (std::byteswap)

Sun, 21 Nov 2021 23:22:55 +0000

[libc++] Implement P1272R4 (std::byteswap)Implement P1274R4Reviewed By: Quuxplusone, Mordante, #libcSpies: jloser, lebedev.ri, mgorny, libcxx-commits, arichardsonDifferential Revision: https://reviews.llvm.org/D114074 List of files: /llvm-project-15.0.7/libcxx/include/bit

eb8650a7 - [runtimes][NFC] Remove filenames at the top of the license notice

Wed, 17 Nov 2021 21:25:01 +0000

[runtimes][NFC] Remove filenames at the top of the license noticeWe've stopped doing it in libc++ for a while now because these nameswould end up rotting as we move things around and copy/paste stuff.This cleans up all the existing files so as to stop the spreadingas people copy-paste headers around. List of files: /llvm-project-15.0.7/libcxx/include/bit

b1fb3d75 - [libc++] Implement C++20's P0476R2: std::bit_cast

Thu, 28 May 2020 18:28:38 +0000

[libc++] Implement C++20's P0476R2: std::bit_castThanks to Arthur O'Dwyer for fixing up some of the tests.Differential Revision: https://reviews.llvm.org/D75960 List of files: /llvm-project-15.0.7/libcxx/include/bit

4e0ea2cf - [libc++] Use enable_if_t instead of _EnableIf

Tue, 17 Aug 2021 16:26:09 +0000

[libc++] Use enable_if_t instead of _EnableIfI just ran into a compiler error involving __bind_back and some overloadsthat were being disabled with _EnableIf. I noticed that the error messagewas quite bad and did not mention the reason for the overload beingexcluded. Specifically, the error looked like this: candidate template ignored: substitution failure [with _Args = ]: no member named '_EnableIfImpl' in 'std::_MetaBase'Instead, when using enable_if or enable_if_t, the compiler is clever andcan produce better diagnostics, like so: candidate template ignored: requirement 'is_invocable_v< std::__bind_back_op<1, std::integer_sequence>, std::ranges::views::__transform::__fn &, std::tuple &, ContiguousView>' was not satisfied [with _Args = ]Basically, it tries to do a poor man's implementation of concepts, whichis already a lot better than simply complaining about substitution failure.Hence, this commit uses enable_if_t instead of _EnableIf wheneverpossible. That is both more straightforward than using the internalhelper, and also leads to better error messages in those cases.I understand the motivation for _EnableIf's implementation was to improvecompile-time performance, however I believe striving to improve errormessages is even more important for our QOI, hence this patch. Furthermore,it is unclear that _EnableIf actually improved compile-time performancein any noticeable way (see discussion in the review for details).Differential Revision: https://reviews.llvm.org/D108216 List of files: /llvm-project-15.0.7/libcxx/include/bit

bfbd73f8 - [libc++] Alphabetize and include-what-you-use. NFCI.

Wed, 19 May 2021 15:57:04 +0000

[libc++] Alphabetize and include-what-you-use. NFCI.Differential Revision: https://reviews.llvm.org/D102781 List of files: /llvm-project-15.0.7/libcxx/include/bit

06b40e80 - [libc++] Alphabetize header inclusions and include-what-you-use <__debug>. NFCI.

Thu, 13 May 2021 03:04:03 +0000

[libc++] Alphabetize header inclusions and include-what-you-use <__debug>. NFCI. List of files: /llvm-project-15.0.7/libcxx/include/bit

e130fbe2 - [libc++] Some fixes to the utilities.

Wed, 12 May 2021 17:09:26 +0000

[libc++] Some fixes to the utilities.Fix __bitop_unsigned_integer and rename to __libcpp_is_unsigned_integer.There are only five unsigned integer types, so we should just list them out.Also provide `__libcpp_is_signed_integer`, even though the Standard doesn'tconsume that trait anywhere yet.Notice that `concept uniform_random_bit_generator` is specifically specifiedto rely on `concept unsigned_integral` and *not* `__is_unsigned_integer`.Instantiating `std::ranges::sample` with a type `U` satisfying`uniform_random_bit_generator` where `unsigned_integral`and not `__is_unsigned_integer` is simply IFNDR.Orthogonally, fix an undefined behavior in std::countr_zero(__uint128_t).Orthogonally, improve tests for the manipulation functions.It was these new tests that detected the bug in countr_zero.Differential Revision: https://reviews.llvm.org/D102328 List of files: /llvm-project-15.0.7/libcxx/include/bit

b5175681 - [libc++] Rename include/support to include/__support

Tue, 02 Feb 2021 21:58:38 +0000

[libc++] Rename include/support to include/__supportWe do ship those headers, so the directory name should not be somethingthat can potentially conflict with user-defined directories.Differential Revision: https://reviews.llvm.org/D95956 List of files: /llvm-project-15.0.7/libcxx/include/bit

b973e2e2 - [libc++] Introduce __bits

Mon, 18 Jan 2021 12:21:00 +0000

[libc++] Introduce __bitsIt has the low-level bit fiddling operations from bit. It eliminates a cyclic dependency between __bit_reference, bits, and vector. I want to exploit this in later patches.Reviewed By: #libc, ldionneDifferential Revision: https://reviews.llvm.org/D94908 List of files: /llvm-project-15.0.7/libcxx/include/bit

d586f92c - [libc++] Consistently replace `std::` qualification with `_VSTD::` or nothing. NFCI.

Fri, 27 Nov 2020 16:02:06 +0000

[libc++] Consistently replace `std::` qualification with `_VSTD::` or nothing. NFCI.I used a lot of `git grep` to find places where `std::` was being usedoutside of comments and assert-messages. There were three outcomes:- Qualified function calls, e.g. `std::move` becomes `_VSTD::move`. This is the most common case.- Typenames that don't need qualification, e.g. `std::allocator` becomes `allocator`. Leaving these as `_VSTD::allocator` would also be fine, but I decided that removing the qualification is more consistent with existing practice.- Names that specifically need un-versioned `std::` qualification, or that I wasn't sure about. For example, I didn't touch any code in , , , or any ext/ or experimental/ headers; and I didn't touch any instances of `std::type_info`.In some deduction guides, we were accidentally using `class Alloc = typename std::allocator`,despite `std::allocator`'s type-ness not being template-dependent.Because `std::allocator` is a qualified name, this did parse as we intended;but what we meant was simply `class Alloc = allocator`.Differential Revision: https://reviews.llvm.org/D92250 List of files: /llvm-project-15.0.7/libcxx/include/bit

1a036e9c - [libcxx] Implement P1956 rename low-level bit functions

Tue, 24 Nov 2020 13:50:49 +0000

[libcxx] Implement P1956 rename low-level bit functionsImplements P1956: On the names of low-level bit manipulation functions.Users may use older versions of libc++ or other standard libraries with the old names. In order to keep compatibility the old functions are kept, but marked as deprecated.The patch also adds a new config macro `_LIBCPP_DEPRECATED_MSG`. Do you prefer a this is a separate patch?Reviewed By: ldionne, #libcDifferential Revision: https://reviews.llvm.org/D90551 List of files: /llvm-project-15.0.7/libcxx/include/bit