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
As time went by, a few files have become mis-formatted w.r.t.
clang-format. This was made worse by the fact that formatting was not
being enforced in extensionless headers. This commit simply brings all
of libcxx/include in-line with clang-format again.
We might have to do this from time to time as we update our clang-format
version, but frankly this is really low effort now that we've formatted
everything once.
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.
These were required a long time ago due to `static_assert` not actually
being available in C++03. Now `static_assert` is simply mapped to
`_Static_assert` in C++03, making the additional parens unnecessary.
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 is a follow-up to https://github.com/llvm/llvm-project/pull/80282.
The transitive includes of `<locale>` in `<vector>` were all guarded by
the availability macro -- the new include should also be guarded,
otherwise any users who compile with localization disabled will start
getting errors trying to include `<vector>`.
Since switching the Windows CI environment over to GitHub Actions
runners, the mingw tests run in a setup where the default compiler
binary is a mingw-targeting compiler, so we don't need to specify a
custom executable name.
For the i686 tests, we still specify a custom compiler name, in order to
target i686 instead of x86_64.
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.
After PR#90394, "__chrono/exception.h" will trigger
"deprecated-copy-with-user-provided-dtor" warning on Windows x64 runtime
testing with ToT Clang. This patch addresses this issue by explicitly
adding those default copy ctors.
It is a bit weird that the same warning will not happen when testing on
Linux x64 under the same condition, despite the warning flag was enabled
(with `-Wdeprecated-copy -Wdeprecated-copy-dtor`). It might be a bug.
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
We want the PSTL implementation details to be available regardless of
the Standard mode or whether the experimental PSTL is enabled. This
patch guards the inclusion of the PSTL to the top-level headers that
define the public API in `__numeric` and `__algorithm`.
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);
```
The lstat/stat/fstat functions have no guarantee whether the `struct stat`
buffer is changed or not on failure. The filesystem::__copy function assumes
that the `struct stat` buffer is not updated on failure, which is not
necessarily correct.
It appears that for a non-existing destination `detail::posix_lstat(to,
t_st, &m_ec1)` returns a failure indicator and overwrites the `struct stat`
buffer with a garbage value, which is accidentally equal to the `f_st` from
stack internals from the previous `detail::posix_lstat(from, f_st, &m_ec1)`
call.
file_type::not_found is a known status, so checking against
`if (not status_known(t))` passes spuriously and execution continues.
Then the __copy function returns errc::function_not_supported because stats
are accidentally equivalent, which is incorrect.
Before checking for `detail::stat_equivalent`, we instead need to make sure
that the call to lstat/stat/fstat was successful.
As a result of `f_st` and `t_st` not being accessed anymore without checking
for the lstat/stat/fstat success indicator, it is not needed to zero-initialize
them.
It looks like the last references got removed in c747bd0e2339.
It removed a __zero() function, which was probably created at
some point in the ancient past to optimize copying the string
representation. The __zero() function got simplified to an
assignment as part of making string constexpr, rendering this
code unnecessary.
Instead of hardcoding a loop for small strings, always call
char_traits::compare which ends up desugaring to __builtin_memcmp.
Note that the original code dates back 11 years, when we didn't lower to
intrinsics in `char_traits::compare`.
Fixes#94222
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.
This implements the throwing overload and the exception classes throw by
this overload.
Implements parts of:
- P0355 Extending chrono to Calendars and Time Zones
This patch reverts 9b832b72 (#87111):
- [libc++] Deprecated `shared_ptr` Atomic Access APIs as per P0718R2
- [libc++] Implemented P2869R3: Remove Deprecated `shared_ptr` Atomic Access APIs from C++26
As explained in [1], the suggested replacement in P2869R3 is `__cpp_lib_atomic_shared_ptr`,
which libc++ does not yet implement. Let's not deprecate the old way of doing things before
the new way of doing things exists.
[1]: https://github.com/llvm/llvm-project/pull/87111#issuecomment-2112740039
For regex patterns that produce zero-length matches, there is one
(imaginary) match in-between every character in the sequence being
searched (as well as before the first character and after the last
character). It's easiest to demonstrate using replacement:
`std::regex_replace("abc"s, "!", "")` should produce `!a!b!c!`, where
each exclamation mark makes a zero-length match visible.
Currently our implementation doesn't correctly set the prefix of each
zero-length match, "swallowing" the characters separating the imaginary
matches -- e.g. when going through zero-length matches within `abc`, the
corresponding prefixes should be `{'', 'a', 'b', 'c'}`, but before this
patch they will all be empty (`{'', '', '', ''}`). This happens in the
implementation of `regex_iterator::operator++`. Note that the Standard
spells out quite explicitly that the prefix might need to be adjusted
when dealing with zero-length matches in
[`re.regiter.incr`](http://eel.is/c++draft/re.regiter.incr):
> In all cases in which the call to `regex_search` returns `true`,
`match.prefix().first` shall be equal to the previous value of
`match[0].second`... It is unspecified how the implementation makes
these adjustments.
[Reproduction example](https://godbolt.org/z/8ve6G3dav)
```cpp
#include <iostream>
#include <regex>
#include <string>
int main() {
std::string str = "abc";
std::regex empty_matching_pattern("");
{ // The underlying problem is that `regex_iterator::operator++` doesn't update
// the prefix correctly.
std::sregex_iterator i(str.begin(), str.end(), empty_matching_pattern), e;
std::cout << "\"";
for (; i != e; ++i) {
const std::ssub_match& prefix = i->prefix();
std::cout << prefix.str();
}
std::cout << "\"\n";
// Before the patch: ""
// After the patch: "abc"
}
{ // `regex_replace` makes the problem very visible.
std::string replaced = std::regex_replace(str, empty_matching_pattern, "!");
std::cout << "\"" << replaced << "\"\n";
// Before the patch: "!!!!"
// After the patch: "!a!b!c!"
}
}
```
Fixes#64451
rdar://119912002
