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
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.
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 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>
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.
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
058e4454 added an XFAIL for this test on AIX because of a backend
limitation. That backend limitation
has been resolved by 0295c2ad and will be available for clang 19, so we
should update the test to
limit the XFAIL to clang versions before that.
There were 7 occurrences of `UNSUPPORTED: !has-unix-headers`, versus 212
occurrences of `REQUIRES: has-unix-headers`.
I don't completely understand how libc++ uses UNSUPPORTED versus
REQUIRES, but it seems better to be consistent, and to avoid the double
negation in "this is unsupported if we don't have unix headers".
(This came to my attention because of the single occurrence in
`libcxx/test/std`. Our MSVC-internal test harness isn't aware of lit
features, so we teach it to skip tests via the incredibly primitive
method of searching for specific comments, so I had to deal with this
comment inconsistency.)
The return of malloc is implementation defined when the requested size
is 0. On platforms (such as AIX) that return a null pointer for 0 size,
operator new will throw a bad_alloc exception. operator new should
return a non null pointer for 0 size instead.
I noticed that these tests had empty `main` functions. Dropping them and
renaming the tests to `MEOW.compile.pass.cpp` will slightly improve test
throughput.
Three unrelated, small improvements:
* `test_macros.h` was incorrectly saying `__has_include("<version>")`
instead of `__has_include(<version>)`.
+ This caused `<ciso646>` to always be included (noticed because MSVC's
STL emitted a deprecation warning).
+ I searched all of LLVM and found no other occurrences.
* `thread.condition.condvarany/wait_for_pred.pass.cpp` forgot to test
anything.
+ I followed what `wait_for.pass.cpp` is testing.
* Uncomment spaceship test coverage.
This patch improves the preservation of qualifiers and loss of type
sugar in TemplateNames.
This problem is analogous to https://reviews.llvm.org/D112374 and this
patch takes a very similar approach to that patch, except the impact
here is much lesser.
When a TemplateName was written bare, without qualifications, we
wouldn't produce a QualifiedTemplate which could be used to disambiguate
it from a Canonical TemplateName. This had effects in the TemplateName
printer, which had workarounds to deal with this, and wouldn't print the
TemplateName as-written in most situations.
There are also some related fixes to help preserve this type sugar along
the way into diagnostics, so that this patch can be properly tested.
- Fix dropping the template keyword.
- Fix type deduction to preserve sugar in TST TemplateNames.
* Guard `std::__make_from_tuple_impl` tests with `#ifdef _LIBCPP_VERSION` and `LIBCPP_STATIC_ASSERT`.
* Change `_LIBCPP_CONSTEXPR_SINCE_CXX20` to `TEST_CONSTEXPR_CXX20`.
+ Other functions in `variant.swap/swap.pass.cpp` were already using the proper test macro.
* Mark `what` as `[[maybe_unused]]` when used by `TEST_LIBCPP_REQUIRE`.
+ This updates one occurrence in `libcxx/test/libcxx` for consistency.
* Windows `_putenv_s()` takes 2 arguments, not 3.
+ See MSVC documentation: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/putenv-s-wputenv-s?view=msvc-170
+ POSIX `setenv()` takes `int overwrite`, but Windows `_putenv_s()` always overwrites.
* Avoid non-Standard zero-length arrays.
+ Followup to #74183 and #79792.
* Add `operator++()` to `unsized_it`.
+ The Standard requires this due to [N4981][] [move.iter.requirements]/1 "The template parameter `Iterator` shall
either meet the *Cpp17InputIterator* requirements ([input.iterators])
or model `input_iterator` ([iterator.concept.input])."
+ MSVC's STL requires this because it has a strengthened exception
specification in `move_iterator` that inspects the underlying iterator's
increment operator.
* `uniform_int_distribution` forbids `int8_t`/`uint8_t`.
+ See [N4981][] [rand.req.genl]/1.5. MSVC's STL enforces this.
+ Note that when changing the distribution's `IntType`, we need to be
careful to preserve the original value range of `[0, max_input]`.
* fstreams are constructible from `const fs::path::value_type*` on wide systems.
+ See [ifstream.cons], [ofstream.cons], [fstream.cons].
* In `msvc_stdlib_force_include.h`, map `_HAS_CXX23` to `TEST_STD_VER` 23 instead of 99.
+ On 2023-05-23, 71400505ca
started recognizing 23 as a distinct value.
* Fix test name typo: `destory_elements.pass.cpp` => `destroy_elements.pass.cpp`
[N4981]: https://wg21.link/N4981
Found while running libc++'s tests with MSVC's STL.
* Avoid MSVC warning C5101: use of preprocessor directive in
function-like macro argument list is undefined behavior.
+ We can easily make this portable by extracting `const bool is_newlib`.
+ Followup to #73440.
+ See #73598.
+ See #73836.
* Avoid MSVC warning C4267: 'return': conversion from 'size_t' to 'int',
possible loss of data.
+ This warning is valid, but harmless for the test, so
`static_cast<int>` will avoid it.
* Avoid MSVC warning C4146: unary minus operator applied to unsigned
type, result still unsigned.
+ This warning is also valid (the scenario is sometimes intentional, but
surprising enough that it's worth warning about). This is a C++17 test,
so we can easily avoid it by testing `is_signed_v` at compile-time
before testing `m < 0` and `n < 0` at run-time.
* Silence MSVC warning C4310: cast truncates constant value.
+ These warnings are being emitted by `T(255)`. Disabling the warning is
simpler than attempting to restructure the code.
+ Followup to #79791.
* MSVC no longer emits warning C4521: multiple copy constructors
specified.
+ This warning was removed from the compiler, since at least 2021-12-09.
