In reaction to the issues raised by Richard in https://llvm.org/D109066,
this commit does not apply P1951 as a DR in previous standard modes,
since it breaks valid code.
I do believe it should be applied as a DR, however ideally we'd get some
sort of statement from the Committee to this effect (and all implementations
would behave consistently). In the meantime, only implement P1951 starting
with C++23 -- we can always come back and apply it as a DR if that's what
the Committee says.
Differential Revision: https://reviews.llvm.org/D110347
Implements parts of P1614, including synth-three-way and three way comparison for std::pair.
Reviewed By: #libc, Quuxplusone, Mordante
Differential Revision: https://reviews.llvm.org/D107721
Instead of overloading `__to_address`, let's specialize `pointer_traits`.
Function overloads need to be in scope at the point where they're called,
whereas template specializations do not. (User code can provide pointer_traits
specializations to be used by already-included library code, so obviously
`__wrap_iter` can do the same.)
`pointer_traits<__wrap_iter<It>>` cannot provide `pointer_to`, because
you generally cannot create a `__wrap_iter` without also knowing the
identity of the container into which you're trying to create an iterator.
I believe this is OK; contiguous iterators are required to provide
`to_address` but *not* necessarily `pointer_to`.
Differential Revision: https://reviews.llvm.org/D110198
LWG 2447 is marked as `Complete`, but there is no `static_assert` to
reject volatile types in `std::allocator`. See the discussion at
https://reviews.llvm.org/D108856.
Add `static_assert` in `std::allocator` to disallow volatile types. Since this
is an implementation choice, mark the binding test as `libc++` only.
Remove tests that use containers backed by `std::allocator` that test
the container when used with a volatile type.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D109056
There were basically two bugs here:
When C++20 `to_address` is called on `int arr[10]`, then `const _Ptr&` becomes
a reference to a const array, and then we dispatch to `__to_address<const int(&)[10]>`,
which, oops, gives us a `const int*` result instead of an `int*` result.
Solution: We need to provide the two standard-specified overloads of
`std::to_address` in exactly the same way that we provide two overloads
of `__to_address`.
When `__to_address` is called on a pointer type, `__to_address(const _Ptr&)`
is disabled so we successfully avoid trying to instantiate pointer_traits of
that pointer type. But when it's called on an array type, it's not disabled
for array types, so we go ahead and instantiate pointer_traits<int[10]>,
which goes boom. Solution: We need to disable `__to_address(const _Ptr&)`
for both pointer and array types. Also disable it for function types,
so that they get the nice error message; and put a test on it.
Differential Revision: https://reviews.llvm.org/D109331
This implements the initial version of the `std::formatter` class and its specializations. It also implements the following formatting functions:
- `format`
- `vformat`
- `format_to`
- `vformat_to`
- `format_to_n`
- `formatted_size`
All functions have a `char` and `wchar_t` version. Parsing the format-spec and
using the parsed format-spec hasn't been implemented. The code isn't optimized,
neither for speed, nor for size.
The goal is to have the rudimentary basics working, which can be used as a
basis to improve upon. The formatters used in this commit are simple stubs that
will be replaced by real formatters in later commits.
The formatters that are slated to be replaced in this patch series don't have
an availability macro to avoid merge conflicts.
Note the formatter for `bool` uses `0` and `1` instead of "false" and
"true". This will be fixed when the stub is replaced with a real
formatter.
Implements parts of:
- P0645 Text Formatting
Completes:
- LWG3539 format_to must not copy models of output_iterator<const charT&>
Reviewed By: ldionne, #libc, vitaut
Differential Revision: https://reviews.llvm.org/D96664
This implements the struct `__format_arg_store` and its dependencies:
* the class basic_format_arg,
* the class basic_format_args,
* the class basic_format_context,
* the function make_format_args,
* the function wmake_format_args,
* the function visit_format_arg,
* several Standard required typedefs.
The following parts will be implemented in a later patch:
* the child class `basic_format_arg::handle`,
* the function `basic_format_arg::basic_format_arg(const T* p)`.
The following extension has been implemented:
* the class basic_format_arg supports `__[u]int128_t` on platform where libc++ supports 128 bit integrals.
Implements parts of:
* P0645 Text Formatting
Completes:
* LWG3371 visit_format_arg and make_format_args are not hidden friends
* LWG3542 basic_format_arg mishandles basic_string_view with custom traits
Note https://mordante.github.io/blog/2021/06/05/format.html gives a bit more information about the goals and non-goals of this initial patch series.
Reviewed By: #libc, ldionne, vitaut
Differential Revision: https://reviews.llvm.org/D103357
This allows testing the rest of those headers on most platforms, instead
of XFAILing the whole test just because of a few functions.
As a fly-by fix, remove std/utilities/time/date.time/ctime.pass.cpp,
which was a duplicate of std/language.support/support.runtime/ctime.pass.cpp.
Differential Revision: https://reviews.llvm.org/D108295
All supported compilers have supported deduction guides in C++17 for a
while, so this isn't necessary anymore.
Differential Revision: https://reviews.llvm.org/D108213
The test precision_type.pass.cpp was a duplicate of precision.pass.cpp,
so it is removed. atomic_flag_test.pass.cpp was a duplicate of
atomic_flag_test_and_set.pass.cpp, so instead I wrote a proper
test for it. Those duplicate tests were detected with
find libcxx ! -empty -type f -exec md5sum {} + | sort | uniq -w32 -dD
Instead of trying to sniff out what features are supported by the
library being tested, the way we normally handle these things is with
Lit annotations. This should not be treated differently.
Differential Revision: https://reviews.llvm.org/D108209
Since we officially don't support several older compilers now, we can
drop a lot of the markup in the test suite. This helps keep the test
suite simple and makes sure that UNSUPPORTED annotations don't rot.
This is the first patch of a series that will remove annotations for
compilers that are now unsupported.
Differential Revision: https://reviews.llvm.org/D107787
All supported compilers have been supporting __is_aggregate for a long
time now, so it's reasonable to remove this workaround.
Differential Revision: https://reviews.llvm.org/D107833
This patch fixes the constrains on the __perfect_forward constructor
and its call operators, which were incorrect. In particular, it makes
sure that we closely follow [func.require], which basically says that
we must deliver the bound arguments with the appropriate value category
or make the call ill-formed, but not silently fall back to using a
different value category.
As a fly-by, this patch also:
- Adds types __bind_front_t and __not_fn_t to make the result of
calling bind_front and not_fn more opaque, and improve diagnostics
for users.
- Adds a bunch of tests for bind_front and remove some that are now
redundant.
- Adds some missing _LIBCPP_HIDE_FROM_ABI annotations.
Immense thanks to @tcanens for raising awareness about this issue, and
providing help with the = delete bits.
Differential Revision: https://reviews.llvm.org/D107199
Also, improve tests for std::destroy and std::destroy_n so that they
check for array support.
These changes are part of http://wg21.link/p0896 (the One Ranges proposal).
Differential Revision: https://reviews.llvm.org/D106916
This started breaking in the CI because we bumped the Clang version to 14,
which requires adjusting the markup in the test suite. I think it's actually
nice the we need to do that and that it doesn't happen automatically, since
it serves as a reminder that this is broken in Clang.
Adds a new CMake option to disable the usage of incomplete headers.
These incomplete headers are not guaranteed to be ABI stable. This
option is intended to be used by vendors so they can avoid their users
from code that's not ready for production usage.
The option is enabled by default.
Differential Revision: https://reviews.llvm.org/D106763
Move the tests to libcxx so they no longer need `REQUIRES: libc++`.
Verify tests don't need `REQUIRES: libc++`.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D106673
This configuration is interesting because GCC has a different level of
strictness for some C++ rules. In particular, it implements the older
standards more stringently than Clang, which can help find places where
we are non-conforming (especially in the test suite).
Differential Revision: https://reviews.llvm.org/D105936
std::exchange is only constexpr in C++20 and later. We were using it
in a constructor marked unconditionally constexpr, which caused issues
when building with -std=c++17.
The weird part is that the issue only showed up when building on the
arm64 macs, but that must be caused by the specific version of Clang
used on those. Since the code is clearly wrong and the fix is obvious,
I'm not going to investigate this further.
The unit tests test some implementation details. As @Quuxplusone pointed
out in D96664 this should only be tested when the tests use libc++. This
addresses the issue for code already in main.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D105568
Now that Lit supports regular expressions inside XFAIL & friends, it is
much easier to write Lit annotations based on the triple.
Differential Revision: https://reviews.llvm.org/D104747
Moves:
* `std::move`, `std::forward`, `std::declval`, and `std::swap` into
`__utility/${FUNCTION_NAME}`.
* `std::swap_ranges` and `std::iter_swap` into
`__algorithm/${FUNCTION_NAME}`
Differential Revision: https://reviews.llvm.org/D103734
C++03 didn't support `explicit` conversion operators;
but Clang's C++03 mode does, as an extension, so we can use it.
This lets us make the conversion explicit in `std::function` (even in '03),
and remove some silly metaprogramming in `std::basic_ios`.
Drive-by improvements to the tests for these operators, in addition
to making sure all these tests also run in `c++03` mode.
Differential Revision: https://reviews.llvm.org/D104682
While the std::allocator<void> specialization was deprecated by
https://wg21.link/p0174#2.2, the *use* of std::allocator<void> by users
was not. The intent was that std::allocator<void> could still be used
in C++17 and C++20, but starting with C++20 (with the removal of the
specialization), std::allocator<void> would use the primary template.
That intent was called out in wg21.link/p0619r4#3.9.
As a result of this patch, _LIBCPP_ENABLE_CXX20_REMOVED_ALLOCATOR_MEMBERS
will also not control whether the explicit specialization is provided or
not. It shouldn't matter, since in C++20, one can simply use the primary
template.
Fixes http://llvm.org/PR50299
Differential Revision: https://reviews.llvm.org/D104323
This has been broken out of D104170 since it should be merged whether or
not we go ahead with the module map changes.
Differential Revision: https://reviews.llvm.org/D104175
Makes the following operations constexpr:
* `std::swap(optional, optional)`
* `optional(optional<U> const&)`
* `optional(optional<U>&&)`
* `~optional()`
* `operator=(nullopt_t)`
* `operator=(U&&)`
* `operator=(optional<U> const&)`
* `operator=(optional<U>&&)`
* `emplace(Args&&...)`
* `emplace(initializer_list<U>, Args&&...)`
* `swap(optional&)`
* `reset()`
P2231 has been accepted by plenary, with the committee recommending
implementers retroactively apply to C++20. It's necessary for us to
implement _`semiregular-box`_ and _`non-propagating-cache`_, both of
which are required for ranges (otherwise we'll need to reimplement
`std::optional` with these members `constexpr`ified).
Differential Revision: https://reviews.llvm.org/D102119
The post-conditions for the self move assignment of `std::unique_ptr`
were changed. This requires no implementation changes. A test was added
to validate the new post-conditions.
Addresses
- LWG-3455: Incorrect Postconditions on `unique_ptr` move assignment
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D103764
This define was out of sync with the corresponding define in tests, it
was added inconsistently in 171c77b7da.
Modern MSVC environments do have these typedefs and functions.
Differential Revision: https://reviews.llvm.org/D103398
Make sure we provide the correct It::difference_type member and update
the tests and synopses to be accurate.
Supersedes D102657 and D103101 (thanks to the original authors).
Differential Revision: https://reviews.llvm.org/D103273
Louis Dionne