Requirements on character-like types are updated unconditionally,
because `basic_string` does requires the default-constructibility. It
might be possible to make `basic_string_view` support classes with
non-public trivial default constructor, but this doesn't seem sensible.
libcxxabi's `ItaniumDemangle.h` is also updated to avoid deprecated
features.
This macro isn't required if we define all the functions inline. In
fact, quite a few of the marked functions have already been inlined.
This patch basically only moves code around and adds
`_LIBCPP_HIDE_FROM_ABI` to the places where it's been missing so far.
This also removes inlining hints, since it dropps `inline` in some
places, but that shouldn't make much of a difference. The functions tend
to be either really small, so should be inlined anyways, or are big
enough that they shouldn't be inlined even with an inlinehint.
When attempting to instantiate `std::atomic` with a non trivially
copyable type, one gets errors from instantiating internals before the
actual static assertion that check the template parameter type
requirements.
The `verify` test for it had a `// ADDITIONAL_COMPILE_FLAGS: -Xclang
-verify-ignore-unexpected=error` directive to work around this issue.
The changes I propose enable us to drop that directive.
As I understand it, the `verify` test was misplaced so I moved it to
`test/{std -> libcxx}/atomics`.
(I ran into this while working on #121414 in which we would add another
static assertion in `__check_atomic_mandates`)
# Overview
As a disclaimer, this is my first PR to LLVM and while I've tried to
ensure I've followed the LLVM and libc++ contributing guidelines,
there's probably a good chance I missed something. If I have, just let
me know and I'll try to correct it as soon as I can.
This PR implements `std::ranges::iota` and
`std::ranges::out_value_result` outlined in
[P2440r1](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2440r1.html).
As outlined in the paper above, I've:
- Implemented `out_value_result` and added to `<algorithm>`
- Added `out_value_result`, `iota_result`, and two overloads of `iota`
to `std::ranges` in `<numeric>`
- Updated the version macro `__cpp_lib_ranges_iota` in `<version>`
I've also added tests for `ranges::iota` and `ranges::out_value_result`.
Lastly, I added those structs to the appropriate module files.
Partially implements #105184
EDIT: Forgot to mention in the original post, thanks to @hawkinsw for
taking a look at a preliminary version of this PR!
# TODOs
- [x] Updating the range [status
doc](https://github.com/jamesETsmith/llvm-project/blob/main/libcxx/docs/Status/RangesMajorFeatures.csv)
- [x] Ensure all comments from https://reviews.llvm.org/D121436 are
addressed here
- [X] EDIT (I'll do this in a separate PR). ~~I'm open to implementing
the rest of P2440r1 (`ranges::shift_left` and `ranges::shift_right`) if
that's ok, I just wanted to get feedback on `ranges::iota` first~~
- [x] I've been having trouble building the modules locally and want to
make sure that's working properly
Closes: #134060
When I introduced the various `_LIBCPP_INTRODUCED_IN_LLVM_XY_ATTRIBUTE`
macros in 182f5e9b2f03, I tried to correlate them to the right OS
versions, but it seems that I made a few mistakes. This wasn't caught in
the CI because we don't test back-deployment that far.
rdar://148405946
There were some remaining headers that were not guarded with
_LIBCPP_HAS_LOCALIZATION, leading to errors when trying to use modules
on platforms that don't support localization (since all the headers get
pulled in when building the 'std' module). This patch brings these
headers in line with what we do for every other header that depends on
localization.
This patch also requires including <picolibc.h> from
<__configuration/platform.h> in order to define _NEWLIB_VERSION. In the
long term, we should use a better approach for doing that, such as
defining a macro in the __config_site header.
This allows us to remove the need for `_LIBCPP_TEMPLATE_VIS` and fixes a
bunch of missing annotations for RTTI when used across dylib boundaries.
`_LIBCPP_TEMPLATE_VIS` itself will be removed in a separate patch, since
it touches a lot of code.
This patch is a no-op for Clang. Only GCC is affected.
We only use `_LIBCPP_DISABLE_EXTENSION_WARNINGS` in a single place while
we use extensions all over the place. The warnings are already disabled,
since libc++'s headers are system headers, so this shouldn't be in any
way observable by users.
This macro is only ever used inside the definiton for the various
visibility macros on windows. There, it's defined in multiple places
with different expansions, which makes it more confusing than helpful
when trying to figure out what macro expands to what.
Using the C++11 attribute syntax makes it more strict where attributes
can be applied, reducing the number of possible positions an attribute
can appear in.
Unlike `flat_map` and `flat_multimap`, The two function template
overloads `flat_set::insert`'s wording strongly suggest we should use
the transparent comparator
https://eel.is/c++draft/flat.set#modifiers-1
Both the code and the tests were not using the transparent comparator,
which needs to be fixed
Instead, make the few functions `map` relies on public. This makes it
more clear what is private to `__tree` and what is part of the
library-internal interface.
Most of the dylib functions inside `<__filesystem/operations.h>` are at
the top of the file. There are a few spread out in the file for some
reason, which this patch fixes.
Previously, ranges::min_element delegated to ranges::__min_element_impl, which
duplicated the definition of std::__min_element. This patch updates
ranges::min_element to directly call std::__min_element, which allows
removing the redundant code in ranges::__min_element_impl.
Upon removal of ranges::__min_element_impl, the other ranges algorithms
ranges::{min,max,max_element}, which previously delegated to ranges::__min_element_impl,
have been updated to call std::__min_element instead.
This refactoring unifies the implementation across these algorithms,
ensuring that future optimizations or maintenance work only need to be
applied in one place.
This has multiple benefits:
- There is a single instance of our hash function, reducing object file
size
- The hash implementation isn't instantiated in every TU anymore,
reducing compile times
- Behind an ABI configuration macro it would be possible to salt the
hash
We've started using `_LIBCPP_BEGIN_NAMESPACE_STD` and
`_LIBCPP_END_NAMESPACE_STD` for more than just the namespace for a while
now. For example, we're using it to add visibility annotations to types.
This works very well and avoids a bunch of annotations, but doesn't work
for the few places where we have an unversioned namespace. This adds
`_LIBCPP_BEGIN_UNVERSIONED_NAMESPACE_STD` and
`_LIBCPP_END_UNVERSIONED_NAMESPACE_STD` to make it simpler to add new
annotations consistently across the library as well as making it more
explicit that the unversioned namespace is indeed intended.
Per [range.view]/6, a `view_interface` isn't a base class of itself, so
`enable_view` should report `false`. Also, current implementation
strategy handles `const` but not `volatile`, IIUC cv-qualifiers should
be consistent handled.
In `enable_view.compile.pass.cpp`, coverage for (`const`) `volatile`
types are added.
Drive-by: Remove one unnessary `test_macro.h` inclusion in a test.
Fixes#132577.
The PR removes the unnecessary division and modulo operations in the
one-word specialization `__bitset<1, _Size>`. The reason is that for the
one-word specialization, we have `__pos < __bits_per_word` (as
`__bitset<1, _Size>` is an implementation detail only used by the public
`bitset`). So `__pos / __bits_per_word == 0` and `__pos / __pos %
__bits_per_word == __pos`.
1013fe3c0cfd7582e94ef2d4bfd79da7ea1a1289 used to implement LWG2770, but
cb0d4df97490ec2d2b1cdf7574d26b1bc4063599 made LWG2770 unimplemented
again because of CWG2386.
This patch re-implements LWG2770, while keeping the libc++-specific
implementation strategy (which is controversial as noted in LWG4040).
Drive-by:
- Make the test coverage for the controversial part noted in LWG4040
libc++-only.
- Add the previously missed entry for LWG2770 to the documentation.
Previously, const and ref qualification on an operation would cause
__desugars_to to report false, which would lead to unnecessary
pessimizations. The same holds for reference_wrapper.
In practice, const and ref qualifications on the operation itself are
not relevant to determining whether an operation desugars to something
else or not, so can be ignored.
We are not stripping volatile qualifiers from operations in this patch
because we feel that this requires additional discussion.
Fixes#129312
That header is generated via CMake, but it is nonetheless present in the
final installation, so it should be covered by the modulemap.
rdar://131418726
The `__is_referenceable` builtin has been removed from Clang, since all
its uses have been replaced by builtins themselves. This trait only
exists for GCC compatibility and to word around some issues in the other
traits. The non-builtin implementation has been refactored to use
variable templates instead, making the implementation much simpler.
We'e specialized `std::signbit` for signed and unsigned integral types
seperately, even though the optimizer can trivially figure out that
`unsigned_value < 0` always false is. This patch removes the
specialization, since there is really not much of a benefit to it.
For certain time_points there are specializations of __convert_to_tm.
This means the non-specialized version is never called. This means some
of the `if constexpr` will never be true. These are removed.
Since there is a `static_assert` accidental removal of the
specialization will make the code ill-formed.
Drive-by changes:
- Consistently mark `std::__inplace_merge::__inplace_merge_impl`
`_LIBCPP_CONSTEXPR_SINCE_CXX26`.
- This function template is only called by other functions that becomes
constexpr since C++26, and it itself calls `std::__inplace_merge` that
is constexpr since C++26.
- Unblock related test coverage in constant evaluation for
`stable_partition`, `ranges::stable_sort`, `std::stable_sort`,
`std::stable_partition`, and `std::inplace_merge`.
When an allocator-aware container already defines a member type alias
`__alloc_traits` for `std::allocator_traits<allocator_type>`, we should
consistently use `__alloc_traits`. Mixing the usage of both
`__alloc_traits` and `std::allocator_traits` can lead to inconsistencies
and confusion.
This patch fixes an issue in libc++ where `std::copy_backward` and
`ranges::copy_backward` incorrectly copy `std::vector<bool>` with small
storage types (e.g., `uint8_t`, `uint16_t`). The problem arises from
flawed bit mask computations involving integral promotions and sign-bit
extension, leading to unintended zeroing of bits. This patch corrects
the bitwise operations to ensure correct bit-level copying.
Fixes#131718.
