|
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 |
|
| #
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 |
|
| #
db1978b6 |
| 16-Jun-2022 |
Nikolas Klauser <[email protected]> |
[libc++] Mark standard-mandated includes as such
Reviewed By: ldionne, Mordante, #libc, saugustine
Spies: saugustine, MaskRay, arichardson, mstorsjo, jloser, libcxx-commits, arphaman
Differential
[libc++] Mark standard-mandated includes as such
Reviewed By: ldionne, Mordante, #libc, saugustine
Spies: saugustine, MaskRay, arichardson, mstorsjo, jloser, libcxx-commits, arphaman
Differential Revision: https://reviews.llvm.org/D127953
show more ...
|
|
Revision tags: llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1, 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 |
|
| #
2ae52326 |
| 08-Jun-2021 |
Louis Dionne <[email protected]> |
[libc++] Towards a simpler extern template story in libc++
The flexibility around extern template instantiation declarations in libc++ result in a very complicated model, especially when support for
[libc++] Towards a simpler extern template story in libc++
The flexibility around extern template instantiation declarations in libc++ result in a very complicated model, especially when support for slightly different configurations (like the debug mode or assertions in the dylib) are taken into account. That results in unexpected bugs like http://llvm.org/PR50534 (and there have been multiple similar bugs in the past, notably around the debug mode).
This patch gets rid of the _LIBCPP_DISABLE_EXTERN_TEMPLATE knob, which I don't think is fundamental. Indeed, the motivation for that knob was to avoid taking a dependency on the library, however that can be done better by linking against the static library instead. And in fact, some parts of the headers will always depend on things defined in the library, which defeats the original goal of _LIBCPP_DISABLE_EXTERN_TEMPLATE.
Differential Revision: https://reviews.llvm.org/D103960
show more ...
|
| #
b8f6f9e7 |
| 05-May-2022 |
Louis Dionne <[email protected]> |
[libc++] Avoid creating temporaries in unary expressions involving valarray
Currently, unary expressions involving valarray will create a temporary. This leads to dangling references in expressions
[libc++] Avoid creating temporaries in unary expressions involving valarray
Currently, unary expressions involving valarray will create a temporary. This leads to dangling references in expressions like `-a * b`, because `-a` is a temporary and the resulting expression will refer to it. This patch fixes the problem by creating a lazy expression to perform the unary operation instead of eagerly creating a temporary valarray. This is permitted by the Standard, which does not specify the exact type of most expressions involving valarrays.
This is technically an ABI break, however I believe the actual potential for breakage is very low.
rdar://90152242
Differential Revision: https://reviews.llvm.org/D125019
show more ...
|
| #
a83f4b9c |
| 23-Apr-2022 |
Nikolas Klauser <[email protected]> |
[libc++] Remove <functional> includes
Reviewed By: var-const, #libc, ldionne
Spies: #libc_vendors, ldionne, libcxx-commits, miyuki
Differential Revision: https://reviews.llvm.org/D124123
|
| #
faef447e |
| 17-Apr-2022 |
Nikolas Klauser <[email protected]> |
[libc++] Granularize <functional> includes
Reviewed By: Mordante, #libc
Spies: libcxx-commits, miyuki
Differential Revision: https://reviews.llvm.org/D123912
|
| #
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 ...
|
| #
48f8a7c4 |
| 25-Feb-2022 |
Corentin Jabot <[email protected]> |
[libc++] Make sure calls to std::move are always qualified
This fixes instances of the newly added `-Wunqualified-std-cast-call`.
(Commit 7853371146 removed unqualified `move` from the tests, but t
[libc++] Make sure calls to std::move are always qualified
This fixes instances of the newly added `-Wunqualified-std-cast-call`.
(Commit 7853371146 removed unqualified `move` from the tests, but these unqualified `move`s remained undetected in the actual headers.)
Differential Revision: https://reviews.llvm.org/D120509
show more ...
|
| #
2e2f3158 |
| 15-Feb-2022 |
Nikolas Klauser <[email protected]> |
[libc++] Granularize algorithm includes
Reviewed By: Mordante, ldionne, Quuxplusone, #libc, #libc_abi
Spies: #libc_vendors, libcxx-commits, miyuki
Differential Revision: https://reviews.llvm.org/D
[libc++] Granularize algorithm includes
Reviewed By: Mordante, ldionne, Quuxplusone, #libc, #libc_abi
Spies: #libc_vendors, libcxx-commits, miyuki
Differential Revision: https://reviews.llvm.org/D119667
show more ...
|
| #
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 ...
|
| #
bd6e6846 |
| 22-Dec-2021 |
Mark de Wever <[email protected]> |
[libc++] Add the version header to all headers.
Some headers which require the version header depend on other headers to provide it. Include the version header in all top-level headers to make sure
[libc++] Add the version header to all headers.
Some headers which require the version header depend on other headers to provide it. Include the version header in all top-level headers to make sure a header cleanup can't remove the version header.
Note this doesn't add the version header to the c headers.
Reviewed By: #libc, Quuxplusone, ldionne
Differential Revision: https://reviews.llvm.org/D116172
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 ...
|
| #
f9f97cae |
| 28-Oct-2021 |
Konstantin Varlamov <[email protected]> |
[libc++] P0433R2: add the remaining deduction guides.
Add deduction guides to `valarray` and `scoped_allocator_adaptor`. This largely finishes implementation of the paper:
* deduction guides for ot
[libc++] P0433R2: add the remaining deduction guides.
Add deduction guides to `valarray` and `scoped_allocator_adaptor`. This largely finishes implementation of the paper:
* deduction guides for other classes mentioned in the paper were implemented previously (see the list below); * deduction guides for several classes contained in the proposal (`reference_wrapper`, `lock_guard`, `scoped_lock`, `unique_lock`, `shared_lock`) were removed by [LWG2981](https://wg21.link/LWG2981).
Also add deduction guides to the synopsis for the few classes (e.g. `pair`) where they were missing.
The only part of the paper that isn't fully implemented after this patch is making sure certain deduction guides don't participate in overload resolution when given incorrect template parameters.
List of significant commits implementing the other parts of P0433 (omitting some minor fixes):
* [pair](https://github.com/llvm/llvm-project/commit/af65856eec160d163c764faad250d93357be7c83) * [basic_string](https://github.com/llvm/llvm-project/commit/6d9f750dec29e8ae5366092e64cd343dae2c7464) * [array](https://github.com/llvm/llvm-project/commit/0ca8c0895c6034615593c295dd955f29b25bf3d4) * [deque](https://github.com/llvm/llvm-project/commit/dbb6f8a8179b0604e25707b5c1b72be6164f62d9) * [forward_list](https://github.com/llvm/llvm-project/commit/e076700b7786959206acef136ecf05d54078e4e1) * [list](https://github.com/llvm/llvm-project/commit/4a227e582b2f13880ea049b29988a37a0f7c0742) * [vector](https://github.com/llvm/llvm-project/commit/df8f75479278d5ce16eede342ceb5ba2fd71460b) * [queue/stack/priority_queue](https://github.com/llvm/llvm-project/commit/5b8b8b5dce587f1e5a4a31cc24f09b18bd53ff9a) * [basic_regex](https://github.com/llvm/llvm-project/commit/edd5e29cfe9f67ec8e7e0eda12eb05e616fdeebc) * [optional](https://github.com/llvm/llvm-project/commit/f35b4bc3954f3b01051fc0848535ff784809e9e2) * [map/multimap](https://github.com/llvm/llvm-project/commit/edfe8525de1f7278f4754f2bffd47b13ec291a17) * [set/multiset](https://github.com/llvm/llvm-project/commit/e20865c387e09ea0ebd5add15c762cd5271ff65f) * [unordered_set/unordered_multiset](https://github.com/llvm/llvm-project/commit/296a80102a9b72c3eda80558fb78a3ed8849b341) * [unordered_map/unordered_multimap](https://github.com/llvm/llvm-project/commit/dfcd4384cbcac0eeb7e5cbce350f875ba4da79d5) * [function](https://github.com/llvm/llvm-project/commit/e1eabcdfad89f67ae575b0c86aa4a72d277378b4) * [tuple](https://github.com/llvm/llvm-project/commit/1308011e1b5c5382281a63dd4191a1784f8d2295) * [shared_ptr/weak_ptr](https://github.com/llvm/llvm-project/commit/83564056d4b186c9fcf016cdbb388755009f7b5a)
Additional notes: * It was revision 2 of the paper that was voted into the Standard. P0433R3 is a separate paper that is not part of the Standard. * The paper also mandates removing several `make_*_searcher` functions (e.g. `make_boyer_moore_searcher`) which are currently not implemented (except in `experimental/`). * The `__cpp_lib_deduction_guides` feature test macro from the paper was accidentally omitted from the Standard.
Differential Revision: https://reviews.llvm.org/D112510
show more ...
|
| #
b8608b87 |
| 28-Sep-2021 |
Mark de Wever <[email protected]> |
[libc++] Use addressof in assignment operator.
Replace `&__rhs` with `_VSTD::addressof(__rhs)` to guard against ADL hijacking of `operator&` in `operator=`. Thanks to @CaseyCarter for bringing it to
[libc++] Use addressof in assignment operator.
Replace `&__rhs` with `_VSTD::addressof(__rhs)` to guard against ADL hijacking of `operator&` in `operator=`. Thanks to @CaseyCarter for bringing it to our attention.
Similar issues with hijacking `operator&` still exist, they will be addressed separately.
Reviewed By: #libc, Quuxplusone, ldionne
Differential Revision: https://reviews.llvm.org/D110852
show more ...
|
| #
469d18c0 |
| 31-May-2021 |
Arthur O'Dwyer <[email protected]> |
[libc++] Fix result-type and value_type computation in <valarray>.
The `operator[]` of `_UnaryOp` and `_BinaryOp` returns the result of calling `__op_`, so its return type should be `__result_type`,
[libc++] Fix result-type and value_type computation in <valarray>.
The `operator[]` of `_UnaryOp` and `_BinaryOp` returns the result of calling `__op_`, so its return type should be `__result_type`, not e.g. `_A0::value_type`. However, `_UnaryOp::value_type` also should never have been `_A0::value_type`; it needs to be the correct type for the result of the unary op, e.g. `bool` when the op is `logical_not`.
This turns out to matter when multiple operators are nested, e.g. `+(v == v)` needs to have a `value_type` of `bool`, not `int`, even when `v` is of type `valarray<int>`.
Differential Revision: https://reviews.llvm.org/D103416
show more ...
|
| #
d39f5c3c |
| 29-May-2021 |
Arthur O'Dwyer <[email protected]> |
[libc++] Avoid `result_type` and `unary/binary_function` in <valarray>.
Give each of the relevant functional operators a `__result_type` instead, so that we can keep using those typedefs in <valarra
[libc++] Avoid `result_type` and `unary/binary_function` in <valarray>.
Give each of the relevant functional operators a `__result_type` instead, so that we can keep using those typedefs in <valarray> even when the public binder typedefs are removed in C++20.
Differential Revision: https://reviews.llvm.org/D103371
show more ...
|
|
Revision tags: llvmorg-12.0.1-rc1 |
|
| #
bfbd73f8 |
| 19-May-2021 |
Arthur O'Dwyer <[email protected]> |
[libc++] Alphabetize and include-what-you-use. NFCI.
Differential Revision: https://reviews.llvm.org/D102781
|
| #
4cd6ca10 |
| 20-Apr-2021 |
Louis Dionne <[email protected]> |
[libc++] NFC: Normalize `#endif //` comment indentation
|
|
Revision tags: 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 |
|
| #
be4c657b |
| 12-Dec-2020 |
Arthur O'Dwyer <[email protected]> |
[libc++] Consistently replace `::new(__p) T` with `::new ((void*)__p) T`. NFCI.
Everywhere, normalize the whitespace to `::new (EXPR) T`. Everywhere, normalize the spelling of the cast to `(void*)EX
[libc++] Consistently replace `::new(__p) T` with `::new ((void*)__p) T`. NFCI.
Everywhere, normalize the whitespace to `::new (EXPR) T`. Everywhere, normalize the spelling of the cast to `(void*)EXPR`.
Without the cast to `(void*)`, the expression triggers ADL on GCC. (I think this is a GCC bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98249) Even if it doesn't trigger ADL, it still seems incorrect to use any argument that's not exactly `(void*)` because that opens the possibility of overload resolution picking a user-defined overload of `operator new`, which would be wrong.
Differential Revision: https://reviews.llvm.org/D93153
show more ...
|
| #
644f68ed |
| 02-Dec-2020 |
zoecarver <[email protected]> |
[libc++] Add slice_array operator= valarray overload.
Add the slice_array::operator=(const std::valarray<T>& val_arr) overload.
Fixes https://llvm.org/PR40792.
Differential Revision: https://revie
[libc++] Add slice_array operator= valarray overload.
Add the slice_array::operator=(const std::valarray<T>& val_arr) overload.
Fixes https://llvm.org/PR40792.
Differential Revision: https://reviews.llvm.org/D58735
show more ...
|
|
Revision tags: llvmorg-11.0.1-rc1 |
|
| #
527a7fdf |
| 24-Nov-2020 |
Bruce Mitchener <[email protected]> |
[libc++] Replace several uses of 0 by nullptr
Differential Revision: https://reviews.llvm.org/D43159
|
|
Revision tags: llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5 |
|
| #
59f8ac3e |
| 28-Sep-2020 |
Louis Dionne <[email protected]> |
[libc++] Replace uses of __libcpp_allocate by std::allocator<>
Both are equivalent, however std::allocator can appear in constant expressions and is higher level.
|
|
Revision tags: 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, 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 |
|
| #
f97936fa |
| 13-Dec-2019 |
Eric Fiselier <[email protected]> |
[libc++] Cleanup and enable multiple warnings.
Too many warnings are being disabled too quickly. Warnings are important to keeping libc++ correct. This patch re-enables two warnings: -Wconstant-eval
[libc++] Cleanup and enable multiple warnings.
Too many warnings are being disabled too quickly. Warnings are important to keeping libc++ correct. This patch re-enables two warnings: -Wconstant-evaluated and -Wdeprecated-copy.
In future, all warnings disabled for the test suite should require an attached bug. The bug should state the plan for re-enabling that warning, or a strong case why it should remain disabled.
show more ...
|
|
Revision tags: llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1, 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, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2, llvmorg-8.0.1-rc1 |
|
| #
de329354 |
| 25-Apr-2019 |
Richard Smith <[email protected]> |
Remove incorrect explicit instantiation declarations for valarray
libc++ ABI v1 provides three valarray symbols as part of the shared library:
valarray<size_t>::valarray(size_t) valarray<size_t>::~
Remove incorrect explicit instantiation declarations for valarray
libc++ ABI v1 provides three valarray symbols as part of the shared library:
valarray<size_t>::valarray(size_t) valarray<size_t>::~valarray() valarray<size_t>::resize(size_t, size_t)
The first two of these are intended to be removed in V2 of the ABI: they're attributed _LIBCPP_HIDE_FROM_ABI_AFTER_V1, and it appears that the intention is that these symbols from the library are not used even when building using the V1 ABI. However, there are explicit instantiation declarations for all three symbols in the header, which are not correct as we do not intend to find an instantiation of these functions that is provided elsewhere.
(A recent change to clang to properly diagnose explicit instantiation declarations of internal linkage functions -- required by [temp.explicit]p13 -- had to be rolled back because it diagnosed these explicit instantiations.)
Remove the explicit instantiation declarations, and remove the explicit instantiation definitions for V2 of the libc++ ABI onwards.
llvm-svn: 359243
show more ...
|
| #
06571975 |
| 02-Apr-2019 |
Eric Fiselier <[email protected]> |
Fix a number of bugs in __val_expr's subset operator[].
The current definitions were entirely broken. They didn't call any existing constructor and the forgot to friend the expression types they wer
Fix a number of bugs in __val_expr's subset operator[].
The current definitions were entirely broken. They didn't call any existing constructor and the forgot to friend the expression types they were trying to construct.
llvm-svn: 357453
show more ...
|