- add zip_view and views::zip for C++23
- added unit tests
- implemented section 5.6 (zip) in P2321R2
I used clang-format to format the files but they look nothing like the rest of the code base. Manually indenting each line to match the styles sounds like an impossible task. Is there any clang-format file which can format it reasonable similar to the rest of the code base so that I can manually format the rest lines that look weird?
Reviewed By: ldionne, #libc, philnik, var-const
Spies: Mordante, philnik, libcxx-commits, mgorny
Differential Revision: https://reviews.llvm.org/D122806
`vector<bool>::const_reference` and `vector<bool>::const_iterator::reference` should be the same type.
Reviewed By: Mordante, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D123851
- added views::join adaptor object
- added test for the adaptor object
- fixed some join_view's tests. e.g iter_swap test
- added some negative tests for join_view to test that operations do not exist when constraints aren't met
- added tests that locks down issues that were already addressed in previous change
- LWG3500 `join_view::iterator::operator->()` is bogus
- LWG3313 `join_view::iterator::operator--` is incorrectly constrained
- LWG3517 `join_view::iterator`'s `iter_swap` is underconstrained
- P2328R1 join_view should join all views of ranges
- fixed some issues in join_view and added tests
- LWG3535 `join_view::iterator::iterator_category` and `::iterator_concept` lie
- LWG3474 Nesting ``join_views`` is broken because of CTAD
- added tests for an LWG issue that isn't resolved in the standard yet, but the previous code has workaround.
- LWG3569 Inner iterator not default_initializable
Reviewed By: #libc, var-const
Spies: var-const, libcxx-commits
Differential Revision: https://reviews.llvm.org/D123466
Note that this class was called just `split_view` in the original One
Ranges Proposal and was renamed to `lazy_split_view` by
[P2210](https://wg21.link/p2210).
Co-authored-by: zoecarver <z.zoelec2@gmail.com>
Differential Revision: https://reviews.llvm.org/D107500
This supersedes and incoroporates content from both D108906 and D54966,
and also some original content.
Co-Authored-by: Marshall Clow <mclow.lists@gmail.com>
Co-Authored-by: Gonzalo Brito Gadeschi
Differential Revision: https://reviews.llvm.org/D118938
This patch implements P0674R1, i.e. support for arrays in std::make_shared
and std::allocate_shared.
Co-authored-by: Zoe Carver <z.zoelec2@gmail.com>
Differential Revision: https://reviews.llvm.org/D62641
Since a8d15a9266 / D110975, this is
the default, even if winpthread headers are available, so we don't
need to cargo cult setting this option in all builds.
Differential Revision: https://reviews.llvm.org/D122717
Reduced the details of the non-chrono formatting information. This has
been shipped and these details part of P0645 which is still documented.
Removing this information keeps the information up-to-date.
Adds the formatters required for the types chrono namespace.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D122735
It seems to have been added back in 761e42fa3d for Clang to use it,
however it seems to have never been used for that purpose, so it is
probably fine to remove it.
Differential Revision: https://reviews.llvm.org/D122330
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
This allows us to detect whether we're being compiled with LLVM's libunwind
more easily, without CMake having to set explicit variables.
As discussed in https://llvm.org/D119538.
Differential Revision: https://reviews.llvm.org/D121015
This patch adds a lightweight assertion handler mechanism that can be
overriden at link-time in a fashion similar to `operator new`.
This is a third take on https://llvm.org/D121123 (which allowed customizing
the assertion handler at compile-time), and https://llvm.org/D119969
(which allowed customizing the assertion handler at runtime only).
This approach is, I think, the best of all three explored approaches.
Indeed, replacing the assertion handler in user code is ergonomic,
yet we retain the ability to provide a custom assertion handler when
deploying to older platforms that don't have a default handler in
the dylib.
As-is, this patch provides a pretty good amount of backwards compatibility
with the previous debug mode:
- Code that used to set _LIBCPP_DEBUG=0 in order to get basic assertions
in their code will still get basic assertions out of the box, but
those assertions will be using the new assertion handler support.
- Code that was previously compiled with references to __libcpp_debug_function
and friends will work out-of-the-box, no changes required. This is
because we provide the same symbols in the dylib as we used to.
- Code that used to set a custom __libcpp_debug_function will stop
compiling, because we don't provide that declaration anymore. Users
will have to migrate to the new way of setting a custom assertion
handler, which is extremely easy. I suspect that pool of users is
very limited, so breaking them at compile-time is probably acceptable.
The main downside of this approach is that code being compiled with
assertions enabled but deploying to an older platform where the assertion
handler didn't exist yet will fail to compile. However users can easily
fix the problem by providing a custom assertion handler and defining
the _LIBCPP_AVAILABILITY_CUSTOM_ASSERTION_HANDLER_PROVIDED macro to
let the library know about the custom handler. In a way, this is
actually a feature because it avoids a load-time error that one would
otherwise get when trying to run the code on the older target.
Differential Revision: https://reviews.llvm.org/D121478
Addresses LWG 3548 which mandates that when shared_ptr is being constructed from a unique_ptr, the unique_ptr's deleter should be moved and not copied.
Reviewed By: #libc, philnik, EricWF
Differential Revision: https://reviews.llvm.org/D119159
Changes in [P0896](https://wg21.link/p0896):
- add `disable_sized_sentinel_for`;
- add `iter_move` and `iter_swap`;
- add a `requires` clause to the `operator->`;
- add `iterator_concept`;
- check that the `Iterator` template parameter is a bidirectional
iterator;
- add constraints to all comparison operators;
- change the definitions of `iterator_category`, `value_type`,
`difference_type` and `reference` (changes to `iterator_category` were
already implemented).
Also add a few forgotten things to the `reverse_iterator` synopsis
(notably the spaceship operator).
Differential Revision: https://reviews.llvm.org/D120180
We've been meaning to remove support for the legacy testing configuration
for a long time. This patch switches the default from the legacy config
to the appropriate new-style configuration based on a few hints.
We've been running with the new-style configuration for more than a year
in our CI, however it's possible that this will uncover issues with some
users that run the tests on platforms that we don't support yet with the
new-style configs. Unfortunately, there is no way to know about it other
than to land this patch and see whether anything breaks.
Differential Revision: https://reviews.llvm.org/D121632
It's the role of the C++ ABI library to install its own headers, not libc++.
This fixes an existing issue causing spurious CI failures where both libc++
and libc++abi would try to install <cxxabi.h> & friends in the same location,
leading to failures during the installation step.
Differential Revision: https://reviews.llvm.org/D121706
Now that we've branched for the LLVM 14 release, our support window
moves to clang-13 and clang-14. Similarly, AppleClang 13 has been
released for some time now, so that should be the oldest compiler
we support, per our policy.
A possible follow-up would be to remove _LIBCPP_HAS_NO_CONCEPTS, since
I don't think we support any compiler that doesn't support concepts
anymore.
Differential Revision: https://reviews.llvm.org/D118831
This reverts commit 276ca873. That commit has quite a history at this
point. It was first landed in dbc647643577, which broke std::shared_ptr<T const>
and was reverted in 9138666f5. It was then re-applied in 276ca873, with
the std::shared_ptr issue fixed, but it caused widespread breakage at
Google (which suggests it would cause similar breakage in the wild too),
so now I'm reverting again.
Instead, I will add a escape hatch that vendors can turn on to enable
the extension and perform a phased transition over one or two releases
like we sometimes do when things become non-trivial.
This extension is a portability trap for users, since no other standard
library supports it. Furthermore, the Standard explicitly allows
implementations to reject std::allocator<cv T>, so allowing it is
really going against the current.
This was discovered in D120684: this extension required `const_cast`ing
in `__construct_range_forward`, a fishy bit of code that can be removed
if we don't support the extension anymore.
This is a re-application of dbc647643577, which was reverted in 9138666f5
because it broke std::shared_ptr<T const>. Tests have now been added and
we've made sure that std::shared_ptr<T const> wouldn't be broken in this
version.
Differential Revision: https://reviews.llvm.org/D120996
As a fly-by fix, enable the complexity-changing assertions in __debug_less
only when the full debug mode is enabled, since debugging level 0 is usually
understood to only contain basic assertions that do not change the complexity
of algorithms.
Differential Revision: https://reviews.llvm.org/D121129
If LIBCXX_ENABLE_SHARED isn't explicitly set on the cmake command
line, isn't set in the cache, and the libcxxabi project is configured
before libcxx, then LIBCXX_ENABLE_SHARED isn't defined yet. Once
the libcxx cmake project has been parsed, LIBCXX_ENABLE_SHARED would
have been set to its default value of ON.
This makes sure that the symbols are properly dllexported in such
a configuration scenario.
Differential Revision: https://reviews.llvm.org/D120982
This extension is a portability trap for users, since no other standard
library supports it. Furthermore, the Standard explicitly allows
implementations to reject std::allocator<cv T>, so allowing it is
really going against the current.
This was discovered in D120684: this extension required `const_cast`ing
in `__construct_range_forward`, a fishy bit of code that can be removed
if we don't support the extension anymore.
Differential Revision: https://reviews.llvm.org/D120996
Move `__quoted_output_proxy` into the one file that uses it.
A `const char*` has no associated traits class, so `std::quoted("literal")`
should be printable into any basic_ostream regardless of traits.
Use hidden-friend `operator<<` and `operator>>`, since we're permitted to.
(The exact signature is unspecified because the class itself is unspecified.)
We shouldn't support `std::quoted("literal")` in C++03 or C++11 mode.
(We do need `std::__quoted(s)` and `std::__quoted(cs)` in C++11 mode,
because they're used by `std::__fs::filesystem::path`.)
Differential Revision: https://reviews.llvm.org/D120135
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
Add an explicit LIBCXX_CXX_ABI=system-libcxxabi option for linking to
system-installed libc++abi. This fixes the ability to link against one
when building libcxx via the runtimes build, as otherwise the build
system insists on linking into in-tree targets.
Differential Revision: https://reviews.llvm.org/D119539
Nikolas Klauser