See [LWG4106](https://cplusplus.github.io/LWG/issue4106) and
[P3341R0](https://wg21.link/p3341r0).
The test coverage for the empty state of `basic_format_args` in
`get.pass.cpp` is to be completely removed, because the
non-default-constructibility is covered in `ctor.pass.cpp`.
This is extracted from #94620. While libc++ doesn't have the problem
described in that issue, a test case is a good idea to ensure that we
don't regress this behavior in the future. This could happen for example
if we decide to use `_Complex` in the implementation of `std::complex`
while Clang doesn't handle bit_cast with _Complex yet.
https://cplusplus.github.io/CWG/issues/2137.html
This change was previously made as part of
924701311aa79180e86ad8ce43d253f27d25ec7d (#77768) and later reverted in
6e4930c67508a90bdfd756f6e45417b5253cd741
This change is still needed because the comment is still true: A
standards-conformant compiler is currently supposed to fail this test.
This also means that any future work on CWG2137 with Clang would not
need to modify the libc++ test suite
GCC 14 has been released a while ago. We've updated the CI to use GCC 14
now. This removes any old annotations in the tests and updates the
documentation to reflect the updated version requirements.
In #90373 size deallocation was enabled by default. Some test were
disabled to propagate the clang changes to the libc++ CI. These changes
have been propagated so the test filter can be updated.
This significantly simplifies the implementation and improves the
codegen. The only downside is that the accuracy can be marginally worse,
but that is up to the compiler to decide with this change, which means
it can be controlled by compiler flags.
Differential Revision: https://reviews.llvm.org/D155312
The new feature-test macro generator uses a JSON file as input.
Separating the
code from the data allows for testing the code. The generator has
several tests.
This JSON format is based on the new format proposed in #88630
At the moment the FTM script has the existing code and an unused new
generator. Followup patches will complete the generator and convert the
existing
Python `dict` to the new JSON format. Since that conversion is a manual
job and
quite a bit of work the transition path has some unused code for some
time.
While implementing the UTC clock it turns out that the implementation of
the leap seconds was not correct, it should store the individual value,
not the sum.
It also looks like LWG3359 has not been fully implemented.
Implements parts of:
- LWG3359 <chrono> leap second support should allow for negative leap
seconds
Fixes#54470.
See https://eel.is/c++draft/global.functions#2:
> A call to a non-member function signature described in [support]
> through [thread] and [depr] shall behave as if the implementation
> declared no additional non-member function signatures.
and https://eel.is/c++draft/global.functions#3:
> An implementation shall not declare a non-member function signature
> with additional default arguments.
PR #96165 broke code similar to this test, and was subsequently
reverted. Add a test-case, to ensure the problem won't reoccur.
This error is potentially related to issues #59292 and #59966.
This patch removes many annotations that are not relevant anymore since
we don't support or test back-deploying to macOS < 10.13. It also cleans
up raw usage of target triples to identify versions of dylibs shipped on
prior versions of macOS, and uses the target-agnostic Lit features
instead. Finally, it reorders both the Lit backdeployment features and
the corresponding availability macros in the library in a way that makes
more sense, and reformulates the Lit backdeployment features in terms of
when a version of LLVM was introduced instead of encoding the system
versions on which it hasn't been introduced yet. Although one can be
derived from the other, encoding the negative form is extremely
error-prone.
Fixes#80901
fixes#92676
So right now clang does not like
```
std::expected<std::any, int> e1;
auto e2 = e1;
```
So basically when clang tries to do overload resolution of `auto e2 =
e1;`
It finds
```
expected(const expected&); // 1. This is OK
expected(const expected<_Up, _OtherErr>&) requires __can_convert; // 2. This needs to check its constraints
```
Then in `__can_convert`, one of the check is
```
_Not<is_constructible<_Tp, expected<_Up, _OtherErr>&>>
```
which is checking
```
is_constructible<std::any, expected<_Up, _OtherErr>&>
```
Then it looks at `std::any`'s constructor
```
template < class _ValueType,
class _Tp = decay_t<_ValueType>,
class = enable_if_t< !is_same<_Tp, any>::value && !__is_inplace_type<_ValueType>::value &&
is_copy_constructible<_Tp>::value> >
any(_ValueType&& __value);
```
In the above, `is_copy_constructible<_Tp>` expands to
```
is_copy_constructible<std::expected<std::any, int>>
```
And the above goes back to the original thing we asked : copy the
`std::expected`, which goes to the overload resolution again.
```
expected(const expected&);
expected(const expected<_Up, _OtherErr>&) requires __can_convert;
```
So the second overload results in a logical cycle.
I am not a language lawyer. We could argue that clang should give up on
the second overload which has logical cycle, as the first overload is a
perfect match.
Anyway, the fix in this patch tries to short-circuiting the second
overload's constraint check: that is, if the argument matches exact same
`expected<T, E>`, we give up immediately and let the copy constructor to
deal with it
Try it again. Use the approach suggested by Tim in the LWG thread :
using function default argument SFINAE
- Revert "[libc++] Revert LWG3233 Broken requirements for shared_ptr
converting constructors (#93071)"
- Revert "[libc++] Revert temporary attempt to implement LWG 4110
(#95263)"
- test for default_delete
- Revert "Revert "[libc++] Revert temporary attempt to implement LWG
4110 (#95263)""
- test for NULL
This patch implements an improvement introduced in P3029R1 that was
missed in #87873. It adds a deduction of static extents if
integral_constant-like constants are passed to `std::extents`.
This effort has quite a history:
- This was first attempted in 2022 via bed3240bf7d1, which broke
std::shared_ptr<T const> and caused the change to be reverted in
9138666f5464.
- We then re-attempted landing the change in 276ca87382b8 after fixing
std::shared_ptr, but reports were made that this broke code en masse
within Google. This led to the patch being reverted again in
a54d028895c9 with the goal to land this again with a migration path for
vendors.
This patch re-lands the removal while providing a migration path for
vendors by providing the `_LIBCPP_ENABLE_REMOVED_ALLOCATOR_CONST` macro.
This macro will be honored for the LLVM 19 release and will be removed
after that, at which point allocator<const T> will be removed
unconditionally.
Fixes#73665
This is essentially a revert of 9853e9b which tried removing duplication
in the Windows config files by moving it to the CMake. However, we want
to decouple the CMake and the test suite as much as possible, so
encoding additional (non-official) Lit parameters in the CMake only as a
code reuse mechanism is not an approach we want to take.
We were not making any distinction between e.g. the "Apple-flavored"
libc++ built from trunk and the system-provided standard library on
Apple platforms. For example, any test that would be XFAILed on a
back-deployment target would unexpectedly pass when run on that
deployment target against the tip of trunk Apple-flavored libc++. In
reality, that test would be expected to pass because we're running
against the latest libc++, even if it is Apple-flavored.
To solve this issue, we introduce a new feature that describes whether
the Standard Library in use is the one provided by the system by
default, and that notion is different from the underlying standard
library flavor. We also refactor the existing Lit features to make a
distinction between availability markup and the library we're running
against at runtime, which otherwise limit the flexibility of what we can
express in the test suite. Finally, we refactor some of the
back-deployment versions that were incorrect (such as thinking that LLVM
10 was introduced in macOS 11, when in reality macOS 11 was synced with
LLVM 11).
Fixes#82107
Clang currently has a bug in the __has_unique_object_representations
builtin where it doesn't provide consistent answers based on the order
of instantiation of templates. This was reported as #95311.
This patch adds a workaround in libc++ to avoid breaking users until
Clang has been fixed. It also revamps the tests a bit.
Since 83ead2b, std::pair would not be trivially copyable when it holds a
trivially copyable type without an assignment operator. That is because
pair gained an elligible copy-assignment-operator (the const version) in
83ead2b in C++ >= 23.
This means that the trivially copyable property of std::pair for such
types would be inconsistent between C++11/14/17/20 (trivially copyable)
and C++23/26 (not trivially copyable). This patch makes std::pair's
behavior consistent in all Standard modes EXCEPT C++03, which is a
pre-existing condition and we have no way of changing (also, it
shouldn't matter because the std::is_trivially_copyable trait was
introduced in C++11).
While this is not technically an ABI break, in practice we do know that
folks sometimes use a different representation based on whether a type
is trivially copyable. So we're treating 83ead2b as an ABI break and
this patch is fixing said breakage.
This patch also adds tests stolen from #89652 that pin down the ABI of
std::pair with respect to being trivially copyable.
Fixes#95428
This changes the `is_swappable` implementation to use variable templates
first and basing the class templates on that. This avoids instantiating
them when the `_v` versions are used, which are generally less resource
intensive.
This patch makes a few adjustments to the way we run the tests in the
Apple configuration on macOS:
First, we stop using DYLD_LIBRARY_PATH. Using that environment variable
leads to libc++.dylib being replaced by the just-built one for the whole
process, and that assumes compatibility between the system-provided
dylib and the just-built one. Unfortunately, that is not the case
anymore due to typed allocation, which is only available in the system
one. Instead, we want to layer the just-built libc++ on top of the
system-provided one, which seems to be what happens when we set a rpath
instead.
Second, add a missing XFAIL for a std::print test that didn't work as
expected when building with availability annotations enabled. When we
enable these annotations, std::print falls back to a non-unicode and
non-terminal output, which breaks the test.
This reverts commit d868f0970, which was shown to break some code and we
don't know yet whether the code should be valid or not. Reverting until
we've had time to figure it out next week.
When I filed LWG4110 after the discussion in #93071, I thought it was
going to be a straightforward fix. It turns out that it isn't, so we
should stay in the state where libc++ is Standards conforming even if
that state leads to some reasonable code being rejected by the library.
Once WG21 figures out what to do with this issue and votes on it, we'll
implement it through our normal means.
This reverts f638f7b6a7c2 and 16f2aa1a2ddf.
This is a follow on to https://github.com/llvm/llvm-project/pull/92312,
where we address some more locale platform differences. These are:
- for locale fr_FR AIX libc expects `U202F` as `LC_MONETARY`
`thousands_sep`
- for locale zh_CN AIX libc `LC_MONETARY` has `n_sign_posn == 1`,
indicating the `negative_sign` should come before the `currency_symbol`
string
The feature has been implemented in LLVM 18 as an experimental feature.
This marks the paper as complete and sets the feature-test macro.
Implements
- P2465R3 Standard Library Modules std and std.compat
Fixes: https://github.com/llvm/llvm-project/issues/89579
The paper
P0768R1 Library Support for the Spaceship (Comparison) Operator
did not add a feature-test macro. This omission has been corrected in
P1353R0 Missing Feature Test Macros
This enables the FTM for P0768R1
Fixes: https://github.com/llvm/llvm-project/issues/73953
---------
Co-authored-by: S. B. Tam <cpplearner@outlook.com>
The experimental PSTL's current dispatching mechanism was designed with
flexibility in mind. However, while reviewing the in-progress OpenMP
backend, I realized that the dispatching mechanism based on ADL and
default definitions in the frontend had several downsides. To name a
few:
1. The dispatching of an algorithm to the back-end and its default
implementation is bundled together via `_LIBCPP_PSTL_CUSTOMIZATION_POINT`.
This makes the dispatching really confusing and leads to annoyances
such as variable shadowing and weird lambda captures in the front-end.
2. The distinction between back-end functions and front-end algorithms
is not as clear as it could be, which led us to call one where we meant
the other in a few cases. This is bad due to the exception requirements
of the PSTL: calling a front-end algorithm inside the implementation of
a back-end is incorrect for exception-safety.
3. There are two levels of back-end dispatching in the PSTL, which treat
CPU backends as a special case. This was confusing and not as flexible
as we'd like. For example, there was no straightforward way to dispatch
all uses of `unseq` to a specific back-end from the OpenMP backend,
or for CPU backends to fall back on each other.
This patch rewrites the backend dispatching mechanism to solve these
problems, but doesn't touch any of the actual implementation of
algorithms. Specifically, this rewrite has the following
characteristics:
- There is a single level of backend dispatching, however partial backends can
be stacked to provide a full implementation of the PSTL. The two-level dispatching
that was used for CPU-based backends is handled by providing CPU-based basis
operations as simple helpers that can easily be reused when defining any PSTL
backend.
- The default definitions for algorithms are separated from their dispatching logic.
- The front-end is thus simplified a whole lot and made very consistent
for all algorithms, which makes it easier to audit the front-end for
things like exception-correctness, appropriate forwarding, etc.
Fixes#70718
3 error_code related cleanups/corrections in the std::filesystem
operations functions.
1. In `__copy`, the `ec->clear()` is unnecessary as `ErrorHandler` at
the start of each function clears the error_code as part of its
initialization.
2. In `__copy`, in the recursive codepath we are not checking the
error_code result of `it.increment(m_ec2)` immediately after use in the
for loop condition (and we aren't checking it after the final increment
when we don't enter the loop).
3. In `__weakly_canonical`, it makes calls to `__canonical` (which
internally uses OS APIs implementing POSIX `realpath`) and we are not
checking the error code result from the `__canonical` call. Both
`weakly_canonical` and `canonical` are supposed to set the error_code
when underlying OS APIs result in an error
(https://eel.is/c++draft/fs.err.report#3.1). With this change we
propagate up the error_code from `__canonical` caused by any underlying
OS API failure up to the `__weakly_canonical`. Essentially, if
`__canonical` thinks an error code should be set, then
`__weakly_canonical` must as well. Before this change it would be
throwing an exception in the non-error_code form of the function when
`__canonical` fails, while not setting the error code in the error_code
form of the function (an inconsistency).
Added a little coverage in weakly_canonical.pass.cpp for the error_code
forms of the API that was missing. Though I am lacking utilities in
libcxx testing to add granular testing of the failure scenarios (like
forcing realpath to fail for a given path, as it could if you had
something like a flaky remote filesystem).
This PR carves out small portion of the test in subject to avoid the
following failure when unicode is not available.
```
# | Assertion failure: result == expected .../formatter.char.funsigned-char.pass.cpp 56
# |
# | Format string ?}
# | Expected output '\x{80}'
# | Actual output '�'
```
This was traced down to different definition of
`__code_point_view::__consume()` under macro_LIBCXX_HAS_NO_UNICODE which
is called inside `__formatter::__escape()`. The `__consume()` returns
`__ok` and code assumes that escaped sequence was already written but it
is not., thus the failure. Here is the snippen code we fall into:
```
typename __unicode::__consume_result __result = __view.__consume();
if (__result.__status == __unicode::__consume_result::__ok) {
__escape = __formatter::__is_escaped_sequence_written(__str, __result.__code_point, __escape, __mark);
```
This avoids breaking code that should arguably be valid but technically
isn't after enforcing the constraints on shared_ptr's constructors. A
new LWG issue was filed to fix this in the Standard.
This patch applies the expected resolution of this issue to avoid
flip-flopping users whose code should always be considered valid.
See #93071 for more context.
