This patch removes the non compliant constructor of std::future_error
and adds the standards compliant constructor in C++17 instead.
Note that we can't support the constructor as an extension in all
standard modes because it uses delegating constructors, which require
C++11. We could in theory support the constructor as an extension in
C++11 and C++14 only, however I believe it is acceptable not to do that
since I expect the breakage from this patch will be minimal.
If it turns out that more code than we expect is broken by this, we can
reconsider that decision.
This was found during D99515.
Differential Revision: https://reviews.llvm.org/D99567
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
We were incorrectly deducing the return type of size() because we were
not using ternary operators in the implementation (as the spec says).
Instead of deducing the common type of the expressions in the spec, we
would deduce potentially different return types and fail to compile.
Fixes#67551
The _LIBCPP_PSTL_CUSTOMIZATION_POINT macro was assuming that the policy
was called _RawPolicy and referencing it by name. It happened to always
work but this was definitely accidental and an oversight in the original
implementation. This patch fixes that by passing the policy to the macro
explicitly. Noticed while reviewing #66968.
Credits: this change is based on analysis and a proof of concept by
gerbens@google.com.
Before, the compiler loses track of end as 'this' and other references
possibly escape beyond the compiler's scope. This can be see in the
generated assembly:
16.28 │200c80: mov %r15d,(%rax)
60.87 │200c83: add $0x4,%rax
│200c87: mov %rax,-0x38(%rbp)
0.03 │200c8b: → jmpq 200d4e
...
...
1.69 │200d4e: cmp %r15d,%r12d
│200d51: → je 200c40
16.34 │200d57: inc %r15d
0.05 │200d5a: mov -0x38(%rbp),%rax
3.27 │200d5e: mov -0x30(%rbp),%r13
1.47 │200d62: cmp %r13,%rax
│200d65: → jne 200c80
We fix this by always explicitly storing the loaded local and pointer
back at the end of push back. This generates some slight source 'noise',
but creates nice and compact fast path code, i.e.:
32.64 │200760: mov %r14d,(%r12)
9.97 │200764: add $0x4,%r12
6.97 │200768: mov %r12,-0x38(%rbp)
32.17 │20076c: add $0x1,%r14d
2.36 │200770: cmp %r14d,%ebx
│200773: → je 200730
8.98 │200775: mov -0x30(%rbp),%r13
6.75 │200779: cmp %r13,%r12
│20077c: → jne 200760
Now there is a single store for the push_back value (as before), and a
single store for the end without a reload (dependency).
For fully local vectors, (i.e., not referenced elsewhere), the capacity
load and store inside the loop could also be removed, but this requires
more substantial refactoring inside vector.
Differential Revision: https://reviews.llvm.org/D80588
The tests were a bit of a mess -- the testing coverage wasn't bad but it
was extremely difficult to see what was being tested and where. I split
up the tests to make them easier to audit for completeness and did such
an audit, adding a few missing tests (e.g. the conditional noexcept-ness
of std::cbegin and std::cend). I also audited the synopsis and adjusted
it where it needed to be adjusted.
This patch is in preparation of fixing #67471.
This patch makes clang diagnose extensive cases of consteval if and is_constant_evaluated usage that are tautologically true or false.
This introduces a new IsRuntimeEvaluated boolean flag to Sema::ExpressionEvaluationContextRecord that means the immediate appearance of if consteval or is_constant_evaluated are tautologically false(e.g. inside if !consteval {} block or non-constexpr-qualified function definition body)
This patch also pushes new expression evaluation context when parsing the condition of if constexpr and initializer of constexpr variables so that Sema can be aware that the use of consteval if and is_consteval are tautologically true in if constexpr condition and constexpr variable initializers.
BEFORE this patch, the warning for is_constant_evaluated was emitted from constant evaluator. This patch moves the warning logic to Sema in order to diagnose tautological use of is_constant_evaluated in the same way as consteval if.
This patch separates initializer evaluation context from InitializerScopeRAII.
This fixes a bug that was happening when user takes address of function address in initializers of non-local variables.
Fixes https://github.com/llvm/llvm-project/issues/43760
Fixes https://github.com/llvm/llvm-project/issues/51567
Reviewed By: cor3ntin, ldionne
Differential Revision: https://reviews.llvm.org/D155064
This reduces the number of instantiations and also avoid blowing up
past the fold-expression limit of Clang.
This is NOT a general statement that we should strive to stay within
Clang's (sometimes way too small) limits, however in this case the
change will reduce the number of template instantiations while at the
same time doing that, which is good.
Differential Revision: https://reviews.llvm.org/D132509
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.
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 makes it obvious that libc++ is used in an unsupported configuration,
and the compiler probably has to be updated. It often happens that people
try to use libc++ and don't realize that their compiler is too old.
Differential Revision: https://reviews.llvm.org/D158214
Since we are defining these typedefs inside namespace std, we need to
refer to ::once_flag (the C Standard Library version). Otherwise
'once_flag' refers to 'std::once_flag', and that's not something we can
pass to the C Standard Library '::call_once()' function later on.
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
Thanks to Giuseppe D'Angelo for pointing this out on the cpplang Slack!
The example implementation in https://eel.is/c++draft/string.view.comparison#example-1
was necessary when it was written, in C++17, but in C++20 we don't need that
complexity anymore, because of the reversed candidates that are
synthesized by the compiler.
This removes a lot of code duplication, makes the code simpler and
prepares the terrain for https://reviews.llvm.org/D101206, which will
fix some UB in the node-based containers.
This also allows removing the dependency of list and forward_list on
unique_ptr by using __allocation_guard instead.
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.
This partially reverts commit e30a148b09, which removed the base
template for std::char_traits. That base template had been marked as
deprecated since LLVM 16 and we were planning to remove it in LLVM 18.
However, as explained in the post-commit comments in
https://reviews.llvm.org/D157058, the deprecation mechanism didn't work
as expected. Basically, the deprecation warnings were never shown to
users since libc++ headers are system headers and Clang doesn't show
warnings in system headers.
As a result, this removal came with basically no lead time as far as
users are concerned, which is a poor experience. For this reason, I am
re-introducing the deprecated char_traits specialization until we have a
proper way of phasing it out in a way that is not a surprise for users.
Since we use C++20 to build the dylib, we can use a lambda to do the
first-time initialization instead of emulating std::bind. This should
not change the behavior of the code at all, it merely simplifies it.
This removes a symbol from the dylib, however that symbol was only ever
used inside the dylib so it shouldn't break the ABI for anyone. I
confirmed that by searching for that symbol on the ABI boundary of a
large number of programs and couldn't find any references to that
function.
This "bug" was probably not noticed because it doesn't affect any integer
type we currently support. It requires integers with more than 2x the
size of `unsigned long long`. However, with such types, the algorithm
used to break down the large integer into groups of size `unsigned long long`
didn't work because we rotated in the wrong direction.
For example, the 256 bit number (1 << 255) would yield the wrong answer
when used with the algorithm before this patch.
In particular, note that the current rotation happens to work for 128 bit
integers because it just swaps the halves in this case.
Differential Revision: https://reviews.llvm.org/D134625
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
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
[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
It's important that the arch directory be included first so that
its header files which interpose on the default include dir
be included instead of the default ones. The clang driver [1] does
this when not building with -nostdinc, the libcxx build should
do the same.
We found this after https://reviews.llvm.org/D154282 when cross
compiling from non Linux to Linux. If the host machine was not
Linux, _LIBCPP_HAS_NO_TIME_ZONE_DATABASE would be defined in
the default include dir __config_site, while it was undefined
in the arch specific one causing build failures.
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 0c68ed006d 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>
After many years of using the really old std::pair ABI which did not yet
have a trivial copy constructor, FreeBSD 14 and later will finally get
rid of it. Only use the old ABI for FreeBSD 13 and earlier.
Note: on the FreeBSD side, we will bump our libc++.so version for this,
and keep an old compatibility library in a separate package.
Differential Revision: https://reviews.llvm.org/D126462
