Instead of using individual macros to turn off missing C library
features, we use the using_if_exists attribute now. This patch removes
the _LIBCPP_HAS_NO_FGETPOS_FSETPOS macro used to workaround missing
fgetpos and fsetpos on older versions of Android -- using_if_exists
should take care of those in the headers and we should add appropriate
XFAILs to the tests instead of using TEST_HAS_NO_FGETPOS_FSETPOS.
This commit removes checks like `_LIBCPP_CLANG_VER >= 1600` related to
ASan annotations. As only 2 previous versions are supported, it's a TODO
for LLVM 18.
1. Instead of using individual "boolean" macros, have an "enum" macro
`_LIBCPP_HARDENING_MODE`. This avoids issues with macros being
mutually exclusive and makes overriding the hardening mode within a TU
more straightforward.
2. Rename the safe mode to debug-lite.
This brings the code in line with the RFC:
https://discourse.llvm.org/t/rfc-hardening-in-libc/73925Fixes#65101
This patch implements `std::basic_syncbuf` and `std::basic_osyncstream` as specified in paper p0053r7. ~~For ease of reviewing I am submitting this patch before submitting a patch for `std::basic_osyncstream`. ~~
~~Please note, this patch is not 100% complete. I plan on adding more tests (see comments), specifically I plan on adding tests for multithreading and synchronization.~~
Edit: I decided that it would be far easier for me to keep track of this and make changes that affect both `std::basic_syncbuf` and `std::basic_osyncstream` if both were in one patch.
The patch was originally written by @zoecarver
Implements
- P0053R7 - C++ Synchronized Buffered Ostream
- LWG-3127 basic_osyncstream::rdbuf needs a const_cast
- LWG-3334 basic_osyncstream move assignment and destruction calls basic_syncbuf::emit() twice
- LWG-3570 basic_osyncstream::emit should be an unformatted output function
- LWG-3867 Should std::basic_osyncstream's move assignment operator be noexcept?
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D67086
Before this patch, we would fail to implicitly convert the result of
predicates to bool, which means we'd potentially perform a copy or move
construction of the boolean-testable, which isn't allowed. The same
holds true for comparing iterators against sentinels, which is allowed
to return a boolean-testable type.
We already had tests aiming to ensure correct handling of these types,
but they failed to provide appropriate coverage in several cases due to
guaranteed RVO. This patch fixes the tests, adds tests for missing
algorithms and views, and fixes the actual problems in the code.
Fixes#69074
There's no reason for them to be public AFAICT. I came across this while
auditing the code bases for places where we'd be using
[[no_unique_address]] incorrectly. Since one of these members is marked
as [[no_unique_address]], this is an extra reason to keep this private
to ensure the member isn't escaped anywhere.
According to https://developer.apple.com/support/xcode/, quite a few of
our availability macros don't do anything anymore, so we might as well
remove them to clean up the code a bit.
There is no reason to use `alignment_of<T>` instead of `alignof(T)` or
`_LIBCPP_ALIGNOF(T)`. It only makes the code more verbose and results in
slightly worse compile times.
The calls to std::construct_at might overwrite the previously set
__has_value_ flag in the case where the flag is overlapping with
the actual value or error being stored (since we use [[no_unique_address]]).
To fix this issue, this patch ensures that we initialize the
__has_value_ flag after we call std::construct_at.
Fixes#68552
This patch fixes an ASAN-found issue in std::basic_filebuf where we'd
check the wrong size before proceeding to set our internal buffer to
the externally-provided buffer, leading to the library trying to read
from the incorrect buffer in underflow().
Thanks to Andrey Semin for the patch.
Differential Revision: https://reviews.llvm.org/D154514
We did not mark std::begin/std::end as noexcept for C-style arrays, we
did not have conditional noexcept on cbegin/cend, and we did not mark
array cbegin/cend as constexpr in all Standard modes. Since this is a
LWG issue, we should implement it as a DR in all Standard modes as
usual.
This patch fixes these issues and adds test coverage. Fixes#67471.
Resolves Issue #69083
The `_CopySegment` helper for `ranges::copy(join_view, out)` is not
`constexpr` causing rejection in `libc++` in a static assertion context
as in the issue snippet.
If we know that index is larger than SSO size, we know that we can't be
in SSO case, and should access the pointer. This removes extra check
from operator[] for inputs known at compile time to be larger than SSO.
This is an implementation detail for `move_only_function` (and potentially other type-erasing classes).
Reviewed By: #libc, ldionne
Spies: Mordante, ldionne, EricWF, libcxx-commits
Differential Revision: https://reviews.llvm.org/D140259
As explained in `__config`, we have an ABI tag that we use to ensure
that we don't run into ODR issues when mixing different versions of
libc++ in multiple TUs. However, the reasoning behind that extends not
only to different versions of libc++, but also to different
configurations of the same version of libc++. In fact, we've been aware
of this for a while but never really bothered to make the change because
ODR issues are often thought to be benign.
Well, it turns out that I just spent over an hour banging my head
against an issue that boils down to our lack of encoding of some ODR
properties in the ABI tag, so here's the patch we should have done a
long time ago.
For now, the ODR properties we encode in the ABI tag are:
- library version
- exceptions vs no-exceptions
- hardening mode
Those are all things that we support different values for on a per-TU
basis and they definitely affect ODR in a meaningful way. We can add
more properties later as we see fit.
This implements layout_stride for C++23 and with that completes the
implementation of the C++23 mdspan header. The feature test macro is
added, and the status pages updated.
Co-authored-by: Damien L-G <dalg24@gmail.com>
Differential Revision: https://reviews.llvm.org/D157171
If an iterator passed to std::uninitialized_copy & friends provided an
unconstrained comparison operator, we would trigger an ambiguous
overload resolution because we used to compare against
__unreachable_sentinel in our implementation.
This patch fixes that by only comparing the output iterator when it is
actually required, i.e. in the <ranges> versions of the algorithms.
Fixes#69334
std::atomic is implemented with the following (confusing!) hierarchy of
types:
std::atomic<T> : std::__atomic_base<T> { ... };
std::__atomic_base<T> {
std::__cxx_atomic_impl<T> __impl;
};
std::__cxx_atomic_impl<T> {
_Atomic(T) __val;
};
Inside std::__atomic_base, we implement the is_lock_free() and
is_always_lock_free() functions. However, we used to implement them
inconsistently:
- is_always_lock_free() is based on whether __cxx_atomic_impl<T> is
always lock free (using the builtin), which means that we include any
potential padding added by _Atomic(T) into the determination.
- is_lock_free() was based on whether T is lock free (using the
builtin), which meant that we did not take into account any potential
padding added by _Atomic(T).
It is important to note that the padding added by _Atomic(T) can turn a
type that wouldn't be lock free into a lock free type, for example by
making its size become a power of two.
The inconsistency of how the two functions were implemented could lead
to cases where is_always_lock_free() would return true, but
is_lock_free() would then return false. This is the case for example of
the following type, which is always lock free on arm64 but was
incorrectly reported as !is_lock_free() before this patch:
struct Foo { float x[3]; };
This patch switches the determination of is_lock_free() to be based on
__cxx_atomic_impl<T> instead to match how we determine
is_always_lock_free().
rdar://115324353
This PR addresses a smaller detail discussed in the code review for
https://github.com/llvm/llvm-project/pull/66968. Currently, some
functions in the `libc++` PSTL CPU backend have been appended with a
digit to indicate the number of input iterator arguments. However, there
is no need to change the name for each version as overloading can be
used instead. This PR will make the naming more consistent in the the
CPU and the proposed OpenMP backend.
This allows smaller allocations to occur, closer to the actual
std::string's required size. This is particularly effective in
decreasing the allocation size upon initial construction (where
__recommend is called to determine the size).
Although the memory savings per-string are never more than 8 bytes per
string initially, this quickly adds up. And has lead to not insigficant
memory savings at Google.
Unfortunately, this change is ABI breaking because it changes the value
returned by max_size. So it has to be guarded.
This patch removes undefined behavior in list and forward_list and __hash_table
caused by improperly beginning and ending the lifetime of the various node
classes. It allows removing the _LIBCPP_STANDALONE_DEBUG macro from
these node types since we now properly begin and end their lifetime,
meaning that we won't trip up constructor homing.
See https://reviews.llvm.org/D98750 for more information on what prompted
this patch.
This commit re-applies 0687e4d9f3, which had been reverted in b935882bdc
because it broke the LLDB build. LLDB folks tell me I can go ahead and
re-commit this now.
Differential Revision: https://reviews.llvm.org/D101206
Co-authored-by: Amy Kwan <amy.kwan1@ibm.com>
This updates the clang-format we use in libc++ to 17. This is necessary
to start running the generated-files checks in GitHub Actions (in
#68920). In fact this is a pre-existing issue regardless of #68920 --
right now our ignore_format.txt job disagrees with the LLVM-wide
clang-format job.
extents CTAD was requiring default constructibility of the extent
arguments due to the way we implemented a pack expansion. This
requirement is not in the standard.
Reported in issue #68671https://github.com/llvm/llvm-project/issues/68671 by @hewillk.
Fixes#68671
