|
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init |
|
| #
a83004f4 |
| 11-Jul-2022 |
David Tenty <[email protected]> |
[libcxx][AIX][z/OS] Remove headers included via `_IBMCPP__`
D127650 removed support for non-clang-based XL compilers, but left some of the headers used only by this compiler and included under the _
[libcxx][AIX][z/OS] Remove headers included via `_IBMCPP__`
D127650 removed support for non-clang-based XL compilers, but left some of 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-meng
Differential Revision: https://reviews.llvm.org/D129491
show more ...
|
| #
de4a57cb |
| 27-Jun-2022 |
Louis Dionne <[email protected]> |
[libc++] Re-add transitive includes that had been removed since LLVM 14
This commit re-adds transitive includes that had been removed by 4cd04d1687f1, c36870c8e79c, a83f4b9cda57, 1458458b558d, 2e2f3
[libc++] Re-add transitive includes that had been removed since LLVM 14
This commit re-adds transitive includes that had been removed by 4cd04d1687f1, c36870c8e79c, a83f4b9cda57, 1458458b558d, 2e2f3158c604, and 489637e66dd3. This should cover almost all the includes that had been removed since LLVM 14 and that would contribute to breaking user code 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 will enable that macro and start fixing downstream issues immediately. We can then remove the macro (and the transitive includes) by default in a future release. That way, we will break users only once by removing transitive includes in bulk instead of doing it bit by bit a every release, 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 <vector>, <optional>, <array> and <unordered_map> have been added in this commit. These transitive inclusions were added when we implemented boyer_moore_searcher in <functional>.
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
show more ...
|
|
Revision tags: llvmorg-14.0.6 |
|
| #
21ba9d0b |
| 14-Jun-2022 |
Mark de Wever <[email protected]> |
[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 <bit> header.
Reviewed By: #libc, Er
[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 <bit> header.
Reviewed By: #libc, EricWF
Differential Revision: https://reviews.llvm.org/D127760
show more ...
|
| #
23b10a4a |
| 12-Jun-2022 |
Mark de Wever <[email protected]> |
[libc++][NFC] Use concepts in <bit>.
All supported compilers have concepts support so use that in the C++20 functions in <bit>.
s/_LIBCPP_INLINE_VISIBILITY/_LIBCPP_HIDE_FROM_ABI/ as drive-by fix.
[libc++][NFC] Use concepts in <bit>.
All supported compilers have concepts support so use that in the C++20 functions in <bit>.
s/_LIBCPP_INLINE_VISIBILITY/_LIBCPP_HIDE_FROM_ABI/ as drive-by fix.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D127594
show more ...
|
|
Revision tags: llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1 |
|
| #
385cc25a |
| 25-Mar-2022 |
Louis Dionne <[email protected]> |
[libc++] Ensure that all public C++ headers include <__assert>
This patch changes the requirement for getting the declaration of the assertion handler from including <__assert> to including any publ
[libc++] Ensure that all public C++ headers include <__assert>
This patch changes the requirement for getting the declaration of the assertion handler from including <__assert> to including any public C++ header of the library. Note that C compatibility headers are excluded 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 new generated test is designed in a way that will make it possible to replace almost all the existing test-generation scripts with this system in upcoming patches.
Differential Revision: https://reviews.llvm.org/D122506
show more ...
|
|
Revision tags: llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2 |
|
| #
3347e7d4 |
| 24-Feb-2022 |
Arthur O'Dwyer <[email protected]> |
[libc++] [LWG3656] Update the return type of std::bit_width.
Fixes LWG3656, "Inconsistent bit operations returning a count". https://cplusplus.github.io/LWG/issue3656
The fix has been approved for
[libc++] [LWG3656] Update the return type of std::bit_width.
Fixes LWG3656, "Inconsistent bit operations returning a count". https://cplusplus.github.io/LWG/issue3656
The fix has been approved for C++23 and left to vendors' discretion in C++20 (but it sounds like everyone's on the same page that of course it should be DR'ed back to C++20 too).
Differential Revision: https://reviews.llvm.org/D120444
show more ...
|
| #
f87aa19b |
| 14-Feb-2022 |
Louis Dionne <[email protected]> |
[libc++] Move everything related solely to _LIBCPP_ASSERT to its own file
This is the first step towards disentangling the debug mode and assertions in libc++. This patch doesn't make any functional
[libc++] Move everything related solely to _LIBCPP_ASSERT to its own file
This is the first step towards disentangling the debug mode and assertions in 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 that libc++ assertions and the debug mode are different things. Future patches will make it possible to enable assertions without enabling the debug mode.
Differential Revision: https://reviews.llvm.org/D119769
show more ...
|
|
Revision tags: llvmorg-14.0.0-rc1, llvmorg-15-init |
|
| #
fa6b9e40 |
| 02-Feb-2022 |
Arthur O'Dwyer <[email protected]> |
[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/D1188
[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
show more ...
|
|
Revision tags: llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2 |
|
| #
5675b611 |
| 16-Dec-2021 |
Nikolas Klauser <[email protected]> |
[libc++] Disable _LIBCPP_DEBUG_ASSERT during constant evaluation
Disable `_LIBCPP_DEBUG_ASSERT` and debug iterators in <string> during constant evaluation
Reviewed By: ldionne, #libc
Spies: goncha
[libc++] Disable _LIBCPP_DEBUG_ASSERT during constant evaluation
Disable `_LIBCPP_DEBUG_ASSERT` and debug iterators in <string> during constant evaluation
Reviewed By: ldionne, #libc
Spies: goncharov, libcxx-commits
Differential Revision: https://reviews.llvm.org/D115788
show more ...
|
|
Revision tags: llvmorg-13.0.1-rc1 |
|
| #
1dc62f26 |
| 21-Nov-2021 |
Nikolas Klauser <[email protected]> |
[libc++] Implement P1272R4 (std::byteswap)
Implement P1274R4
Reviewed By: Quuxplusone, Mordante, #libc
Spies: jloser, lebedev.ri, mgorny, libcxx-commits, arichardson
Differential Revision: https:
[libc++] Implement P1272R4 (std::byteswap)
Implement P1274R4
Reviewed By: Quuxplusone, Mordante, #libc
Spies: jloser, lebedev.ri, mgorny, libcxx-commits, arichardson
Differential Revision: https://reviews.llvm.org/D114074
show more ...
|
| #
eb8650a7 |
| 17-Nov-2021 |
Louis Dionne <[email protected]> |
[runtimes][NFC] Remove filenames at the top of the license notice
We've stopped doing it in libc++ for a while now because these names would end up rotting as we move things around and copy/paste st
[runtimes][NFC] Remove filenames at the top of the license notice
We've stopped doing it in libc++ for a while now because these names would end up rotting as we move things around and copy/paste stuff. This cleans up all the existing files so as to stop the spreading as people copy-paste headers around.
show more ...
|
|
Revision tags: llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2 |
|
| #
b1fb3d75 |
| 28-May-2020 |
Louis Dionne <[email protected]> |
[libc++] Implement C++20's P0476R2: std::bit_cast
Thanks to Arthur O'Dwyer for fixing up some of the tests.
Differential Revision: https://reviews.llvm.org/D75960
|
| #
4e0ea2cf |
| 17-Aug-2021 |
Louis Dionne <[email protected]> |
[libc++] Use enable_if_t instead of _EnableIf
I just ran into a compiler error involving __bind_back and some overloads that were being disabled with _EnableIf. I noticed that the error message was
[libc++] Use enable_if_t instead of _EnableIf
I just ran into a compiler error involving __bind_back and some overloads that were being disabled with _EnableIf. I noticed that the error message was quite bad and did not mention the reason for the overload being excluded. Specifically, the error looked like this:
candidate template ignored: substitution failure [with _Args = <ContiguousView>]: no member named '_EnableIfImpl' in 'std::_MetaBase<false>'
Instead, when using enable_if or enable_if_t, the compiler is clever and can produce better diagnostics, like so:
candidate template ignored: requirement 'is_invocable_v< std::__bind_back_op<1, std::integer_sequence<unsigned long, 0>>, std::ranges::views::__transform::__fn &, std::tuple<PlusOne> &, ContiguousView>' was not satisfied [with _Args = <ContiguousView>]
Basically, it tries to do a poor man's implementation of concepts, which is already a lot better than simply complaining about substitution failure.
Hence, this commit uses enable_if_t instead of _EnableIf whenever possible. That is both more straightforward than using the internal helper, and also leads to better error messages in those cases.
I understand the motivation for _EnableIf's implementation was to improve compile-time performance, however I believe striving to improve error messages is even more important for our QOI, hence this patch. Furthermore, it is unclear that _EnableIf actually improved compile-time performance in any noticeable way (see discussion in the review for details).
Differential Revision: https://reviews.llvm.org/D108216
show more ...
|
| #
bfbd73f8 |
| 19-May-2021 |
Arthur O'Dwyer <[email protected]> |
[libc++] Alphabetize and include-what-you-use. NFCI.
Differential Revision: https://reviews.llvm.org/D102781
|
| #
06b40e80 |
| 13-May-2021 |
Arthur O'Dwyer <[email protected]> |
[libc++] Alphabetize header inclusions and include-what-you-use <__debug>. NFCI.
|
| #
e130fbe2 |
| 12-May-2021 |
Arthur O'Dwyer <[email protected]> |
[libc++] Some fixes to the <bit> 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
[libc++] Some fixes to the <bit> 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't consume that trait anywhere yet.
Notice that `concept uniform_random_bit_generator` is specifically specified to 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<U::result_type>` and not `__is_unsigned_integer<U::result_type>` is simply IFNDR.
Orthogonally, fix an undefined behavior in std::countr_zero(__uint128_t).
Orthogonally, improve tests for the <bit> manipulation functions. It was these new tests that detected the bug in countr_zero.
Differential Revision: https://reviews.llvm.org/D102328
show more ...
|
| #
b5175681 |
| 02-Feb-2021 |
Louis Dionne <[email protected]> |
[libc++] Rename include/support to include/__support
We do ship those headers, so the directory name should not be something that can potentially conflict with user-defined directories.
Differentia
[libc++] Rename include/support to include/__support
We do ship those headers, so the directory name should not be something that can potentially conflict with user-defined directories.
Differential Revision: https://reviews.llvm.org/D95956
show more ...
|
| #
b973e2e2 |
| 18-Jan-2021 |
Thorsten Schütt <[email protected]> |
[libc++] Introduce __bits
It 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.
[libc++] Introduce __bits
It 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, ldionne
Differential Revision: https://reviews.llvm.org/D94908
show more ...
|
| #
d586f92c |
| 27-Nov-2020 |
Arthur O'Dwyer <[email protected]> |
[libc++] Consistently replace `std::` qualification with `_VSTD::` or nothing. NFCI.
I used a lot of `git grep` to find places where `std::` was being used outside of comments and assert-messages. T
[libc++] Consistently replace `std::` qualification with `_VSTD::` or nothing. NFCI.
I used a lot of `git grep` to find places where `std::` was being used outside 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 <atomic>, <math.h>, <new>, 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<T>`, despite `std::allocator<T>`'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<T>`.
Differential Revision: https://reviews.llvm.org/D92250
show more ...
|
| #
1a036e9c |
| 24-Nov-2020 |
Mark de Wever <[email protected]> |
[libcxx] Implement P1956 rename low-level bit functions
Implements P1956: On the names of low-level bit manipulation functions.
Users may use older versions of libc++ or other standard libraries wi
[libcxx] Implement P1956 rename low-level bit functions
Implements 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, #libc
Differential Revision: https://reviews.llvm.org/D90551
show more ...
|
| #
ebddf90a |
| 28-May-2020 |
Louis Dionne <[email protected]> |
[libc++] NFC: Remove outdated numbering in <bit> synopsis
|
|
Revision tags: llvmorg-10.0.1-rc1, llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1, llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1 |
|
| #
6b77ebdc |
| 23-Oct-2019 |
Louis Dionne <[email protected]> |
[NFC] Strip trailing whitespace from libc++
|
|
Revision tags: llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3, llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1 |
|
| #
30f12a42 |
| 23-Jul-2019 |
Marshall Clow <[email protected]> |
Implement most of P1612R1: Relocate endian. Moves the std::endian functionality from 'type-traits' to 'bit'. No other change. The reason that this is 'partial' is that P1621 also recommends a featur
Implement most of P1612R1: Relocate endian. Moves the std::endian functionality from 'type-traits' to 'bit'. No other change. The reason that this is 'partial' is that P1621 also recommends a feature-test macro, but I don't have the value for that one yet. In a month or so, I'll add that
llvm-svn: 366776
show more ...
|
|
Revision tags: llvmorg-10-init |
|
| #
f3b851f0 |
| 12-Jul-2019 |
Marshall Clow <[email protected]> |
Reorganize the 'bit' header to make most of the facilities available for internal use pre-C++20. NFC for external users
llvm-svn: 365854
|
|
Revision tags: llvmorg-8.0.1, llvmorg-8.0.1-rc4 |
|
| #
bd7f84a4 |
| 02-Jul-2019 |
Marshall Clow <[email protected]> |
Use new '__libcpp_is_constant_evaluated' call to remove an '#ifdef' from the bit code. NFC
llvm-svn: 364884
|