Since LLVM 17 has been branched and is on the verge of being released,
we can drop the CI job that tests against Clang 15. I think the number
of cherry-picks to `release/17.x` will be a lot smaller now, so keeping
a Clang 15 job around for that purpose seems unnecessary.
As a fly-by, this patch also removes some Clang 15 workarounds and test
suite annotations as we usually do. It also removes some slightly older
gcc test suite annotations that were missed.
After landing the implementation of LWG3545, I realized that the tests
for std::pointer_traits had become a bit disorganized. This patch is a
NFC that refactors the tests:
- Move compile-only tests to `.compile.pass.cpp` tests
- Re-create the clear distinction between tests for the std::pointer_traits base tempate and for the T* specialization.
- De-duplicate test coverage -- we had a bunch of things that were tested in duplication.
AppleClang 15 was released on September 18th and is now stable. Per our
policy, we're bumping the supported AppleClang compiler to the latest
release. This allows cleaning up the test suite, but most importantly
unblocking various other patches that are blocked on bumping the
compiler requirements.
Previously, assignment to a std::basic_string type with a _custom_
allocator could under certain conditions attempt to interpret part of
the target string's "short" string-content as if it was a "long" data
pointer, and attempt to deallocate a garbage value.
This is a serious bug, but code in which it might happen is rare. It
required:
1. the basic_string must be using a custom allocator type which sets the
propagate_on_container_copy_assignment trait to true (thus, it does not
affect the default allocator, nor most custom allocators).
2. the allocator for the target string must compare not equal to the
allocator for the source string (many allocators always compare equal).
3. the source of the copy must currently contain a "long" string, and
the assignment-target must currently contain a "short" string.
Finally, the issue would've typically been innocuous when the bytes
misinterpreted as a pointer were all zero, as deallocating a nullptr is
typically a no-op. This is why existing test cases did not exhibit an
issue: they were all zero-length strings, which do not have data in the
bytes interpreted as a pointer.
This patch is a melting pot of changes picked up from
https://llvm.org/D61878. It adds a few tests checking corner cases of
unordered containers comparison and adds benchmarks for a few
unordered_set operations.
The helper function `__pair_like_explicit_wknd` is only SFINAE-ed with
`tuple_size<remove_cvref_t<_PairLike>>::value == 2`, but its function
body assumes `std::get` being valid.
Fixes#65620
Notice that because Holder<Incomplete> is _possible_ to complete, but
_unsafe_ to complete, that means that Holder<Incomplete>* is basically
not an iterator and it's not even safe to ask if
input_iterator<Holder<Incomplete>*> because that _will_ necessarily
complete the type. So it's totally expected that we still cannot safely
ask e.g.
static_assert(std::indirect_unary_predicate<bool(&)(Holder<Incomplete>&),
Holder<Incomplete>*>);
or even
static_assert(!std::indirect_unary_predicate<int, Holder<Incomplete>*>);
This was originally uploaded as https://reviews.llvm.org/D119029 and I
picked it up here as part of the Github PR transition.
Co-authored-by: Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
When we implemented C++20's P0674R1, we didn't enable the part of
P0674R1 that was resolving LWG2070 as a DR. This patch fixes that and
makes sure that we consistently go through the allocator when
constructing and destroying the underlying object in
std::allocate_shared.
Fixes#54365.
The safe mode is in-between the hardened and the debug modes, extending
the checks contained in the hardened mode with certain checks that are
relatively cheap and prevent common sources of errors but aren't
security-critical. Thus, the safe mode trades off some performance for
a wider set of checks, but unlike the debug mode, it can still be used
in production.
Differential Revision: https://reviews.llvm.org/D158823
Was part of D118114. Unify test cases for `std::map::count` method and
add test case for the comparator that marked `final`
Differential Revision: https://reviews.llvm.org/D118232
[libcxx] <experimental/simd> Added internal storage type for class simd/simd_mask
[libcxx] <experimental/simd> Added all constructors of class simd/simd_mask and related tests
[libcxx] <experimental/simd> Added basic simd reference implementation, subscript operators of class simd/simd_mask and related tests
Reviewed By: #libc, philnik
Differential Revision: https://reviews.llvm.org/D144364
This is to fix an error that occurs when the char type is a class type.
Thanks to Yichen Yan for the patch.
Differential Revision: https://reviews.llvm.org/D100005
The test is hardcoded to fail after passing `test_ill_formed_utf16()`. It passes on 32-bit AIX if we remove this.
Reviewed By: Mordante, #libc, ldionne
Differential Revision: https://reviews.llvm.org/D150273
On GLibc, FreeBSD and macOS systems nl_catd is a pointer type, and
round-tripping this in a variable of ptrdiff_t is not portable.
In fact such a round-trip yields a non-dereferenceable pointer on
CHERI-enabled architectures such as Arm Morello. There pointers (and
therefore intptr_t) are twice the size of ptrdiff_t, which means casting
to ptrdiff_t strips the high (metadata) bits (as well as a hidden pointer
validity bit).
Since catalog is now guaranteed to be the same size or larger than nl_catd,
we can store all return values safely and the shifting workaround from
commit 0c68ed006d4f38c3cdcab6a565aa3e208015895f should not be needed
anymore (this is also not portable to CHERI systems on since shifting a
valid pointer right will create a massively out-of-bounds pointer that
may not be representable).
This can be fixed by using intptr_t which should be the same type as
ptrdiff_t on all currently supported architectures.
See also: https://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2028
Differential Revision: https://reviews.llvm.org/D134420
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
Fixes a conflict with adding the no experimental module build.
Disables some tests that need further investigation, this should fix the
CI runners.
These issues were reported on Discord and in D154282.
This is the first step to implement time zone support in libc++. This
adds the complete tzdb_list class and a minimal tzdb class. The tzdb
class only contains the version, which is used by reload_tzdb.
Next to these classes it contains documentation and build system support
needed for time zone support. The code depends on the IANA Time Zone
Database, which should be available on the platform used or provided by
the libc++ vendors.
The code is labeled as experimental since there will be ABI breaks
during development; the tzdb class needs to have the standard headers.
Implements parts of:
- P0355 Extending <chrono> to Calendars and Time Zones
Addresses:
- LWG3319 Properly reference specification of IANA time zone database
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D154282
This is a followup of D157625. Using the name clang-modules-build makes
it clear this is regarding the clang modules and not the C++23 std or
std.compat module.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D158927
When a handle to an error_category singleton object is used during the
termination phase of a program, the destruction of the error_category
object may have occurred prior to execution of the current destructor
or function registered with atexit, because the singleton object may
have been constructed after the corresponding initialization or call
to atexit. For example, the updated tests from this patch will fail if
using a libc++ built using a compiler that updates the vtable of the
object on destruction.
This patch attempts to avoid the issue by causing the destructor to not
be called in the style of ResourceInitHelper in src/experimental/memory_resource.cpp.
This approach might not work if object lifetime is strictly enforced.
Differential Revision: https://reviews.llvm.org/D65667
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
