Our current locale base API is a mix of non-reserved system names that
we incorrectly (re)define and internal functions and macros starting
with __libcpp. This patch introduces a function-based internal interface
to isolate the rest of the code base from that mess, so that we can work
on refactoring how each platform implements the base API in subsequent
patches. This makes it possible to refactor how each platform implements
the base localization API without impacting the rest of the code base.
Prior to aa7f377c96, we only did an #include_next of those system
headers if they existed. After removing those headers from libc++, we
started assuming that the system provided the headers because we
unconditionally started including them. This patch fixes that.
We can define some of these aliases without having to include the system
<stddef.h> and there doesn't seem to be much of a reason we shouldn't do
it this way.
`<string>` doesn't seem to be required at all and `flat_map` doesn't
support `vector<bool>`, so we can include just `vector<T>`. This cuts
the include time in half on my system.
We're checking quite a few things that are either trivially true or
trivially false. These cases became trivial when we changed `reserve()`
to never shrink.
The main template of `aligned_storage` is only ever used when we have
extremely overaligned types (> 16384), so we effectively only ever use
the specializations currently. This means that we only instantiate the
main template for overaligned types. Instead of doing this dance, we can
just define the main template to use `_ALIGNAS`, just like the
specializations. This makes the implementation of `aligned_storage`
significantly less confusing.
This helps with readability since the reader doesn't need to jump around
a bunch of times only to read functions that are implemented in 1 or 2
lines of code.
This PR refactors the `__split_buffer` class to eliminate code
duplication in the `push_back` and `push_front` member functions.
**Motivation:**
The lvalue and rvalue reference overloads of `push_back` share identical
logic, which coincides with that of `emplace_back`. Similarly, the
overloads of `push_front` also share identical logic but lack an
`emplace_front` member function, leading to an inconsistency. These
identical internal logics lead to significant code duplication, making
future maintenance more difficult.
**Summary of Refactor:**
This PR reduces code redundancy by:
1. Modifying both overloads of `push_back` to call `emplace_back`.
2. Introducing a new `emplace_front` member function that encapsulates
the logic of `push_front`, allowing both overloads of `push_front` to
call it (The addition of `emplace_front` also avoids the inconsistency
regarding the absence of `emplace_front`).
The refactoring results in reduced code duplication, improved
maintainability, and enhanced readability.
This improves the diagnostics a bit by using `enable_if_t` which clang
is aware of, instead of a custom SFINAE class, as well as writing the
functions in a more canonical style.
As a drive-by this also makes `__is_{,un}bounded_array` variable
templates instead of class templates.
We were using macros instead of functions, leading to the inability to
properly qualify calls to those symbols inside <locale>. This is also a
step towards making the locale API modules-correct.
The implementation of std::hash for unsigned long makes the (correct)
assumption that size_t is at least as large as unsigned long. If that
were not the case on a platform, the implementation of std::hash for
unsigned long would be absolutely terrible. Add a static assertion to
document that assumption.
This reverts commit ef44e4659878f2. The patch was originally reverted
because it was
deemed to introduce a performance regression for small inputs, however
it also fixed
a previous performance regression for larger inputs. So overall, this
patch is desirable.
This PR deprecates `<ccomplex>`, `<cstdbool>`, `<ctgmath>`, and
`<ciso646>` in C++17 and "removes" them in C++20 by special deprecation
warnings.
`<cstdalign>` is previously missing. This PR also tries to add them, and
then deprecates and "removes" `<cstdalign>`.
Papers:
- https://wg21.link/P0063R3
- https://wg21.link/P0619R4Closes#99985.
---------
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
Fixes#109858.
The changes in #81379 broke some 3rd party library code that expected
usability of `std::complex<NonFloatingPoint>`. Although such code isn't
portable per [complex.numbers.general]/2, it might be better to make
these additional overloads not to interfere overload resolution too
much.
---------
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
Added exception guard to the `vector(n, x, a)` constructor to enhance
exception safety. This change ensures that the `vector(n, x, a)`
constructor is consistent with other constructors, such as `vector(n)`,
`vector(n, x)`, `vector(n, a)`, in terms of exception safety.
This implements a warning that's similar to what GCC does in that
context: both memcpy and memset require their first and second operand
to be trivially copyable, let's warn if that's not the case.
Around half of the tests are based on the tests Arthur O'Dwyer's
original implementation of std::flat_map, with modifications and
removals.
partially implement #105190
For now these headers don't provide much benefit, however as we refactor
the locale base API they will provide a location to specify the
localization interface on these platforms.
In C++20 mode, `__cpp_lib_optional` and `__cpp_lib_variant` should be
`202106L` due to DR P2231R1.
In C++26 mode, `__cpp_lib_variant` should be bumped to `202306L` due to
P2637R3.
- Clang 16/17 shouldn't get this bumping (as member `visit` requires
explicit object parameters), but it's very tricky to make the bumping
conditionally enabled. I _hope_ unconditionally bumping in C++26 will be
OK for LLVM 20 when the support for Clang 17 is dropped.
Related PRs:
- https://reviews.llvm.org/D102119
- #83335
- #76447
The solaris header file doesn't even exist, so that's definitely dead
code. The newlib header is empty, which means that localization can't
work on that platform. If someone is using libc++ with Newlib, they must
be providing LIBCXX_HAS_NO_LOCALIZATION today for anything to work, so
that header is basically dead code as well.
Rename __libcpp_locale_guard to just __locale_guard, since there's no
reason for it to have __libcpp_ in its name -- it's just an internal
utility.
Also, define __locale_guard unconditionally of
_LIBCPP_LOCALE__L_EXTENSIONS, since that header is only used on Windows
(where it has a custom definition) or from bsd_locale_fallbacks.h, which
is only included when the L extensions are not provided.
Identifiers `clang` and `noescape` are not reserved by the C++ standard,
so perhaps we need to use the equivalent reserved forms.
Also changes the occurrences of that attribute to a macro, following the
convention for `[[_Clang::__lifetimebound__]]`.
Addresses
https://github.com/llvm/llvm-project/pull/91651#discussion_r1807852646.
This removes some duplicate code. I suspect this was originally written
that way because vector::emplace didn't exist in C++03 mode, which
stopped being relevant when Clang implemented rvalue references in
C++03.
`-fvisibility-global-new-delete` has been added in Clang 18, so there is
no more need to specify the visibility of new/delete via libc++-internal
macros.
Some people used a custom new/delete, which requires them to have
default visibility, but didn't want to leak any symbols otherwise. Since
the new/delete visibility can now be controlled by a compiler flag,
there is no reason to set it with out macro.
https://reviews.llvm.org/D128007 originally tried to remove the option
to override the macro, but was partially reverted because people
actually set this specific macro.
This reverts commit 68c04b0ae62d8431d72d8b47fc13008002ee4387.
This disables the IWYU mapping that caused the failure, since
the headers aren't reachable for now.
This is the first part of the "Freezing C++03 headers" proposal
explained in
https://discourse.llvm.org/t/rfc-freezing-c-03-headers-in-libc/77319/58.
This patch mechanically copies the headers as of the LLVM 19.1 release
into a subdirectory of libc++ so that we can start using these headers
when building in C++03 mode. We are going to be backporting important
changes to that copy of the headers until the LLVM 21 release. After the
LLVM 21 release, only critical bugfixes will be fixed in the C++03 copy
of the headers.
This patch only performs a copy of the headers -- these headers are
still unused by the rest of the codebase.
The std::prev function appeared to work on non Cpp17BidirectionalIterators, however it
behaved strangely by being the identity function. That was extremely misleading and
potentially dangerous, since several recent iterators that are C++20 bidirectional_iterators
don't satisfy the Cpp17BidirectionalIterator named requirement. For example:
auto zv = std::views::zip(vec1, vec2);
auto it = zv.begin() + 5;
auto it2 = std::prev(it); // "it2" will be the same as "it", instead of the previous one
Here, zip_view::iterator is a c++20 random_access_iterator, but it only satisfies the
Cpp17InputIterator named requirement because its reference type is a proxy type. Hence
`std::prev` would silently accept that iterator but it would do a no-op instead of going
to the previous position.
This patch changes `std::prev(it)` to produce an error at compile-time when instantiated
with a type that is not a Cpp17BidirectionalIterator.
Fixes#109456
This PR refactors the std::vector's initializer_list constructors to
reduce code duplication. The constructors now call `__init_with_size`
directly, reducing code duplication and improving readability and
maintainability.
Implements std::from_chars for float and double.
The implementation uses LLVM-libc to do the real parsing. Since this is
the first time libc++
uses LLVM-libc there is a bit of additional infrastructure code. The
patch is based on the
[RFC] Project Hand In Hand (LLVM-libc/libc++ code sharing)
https://discourse.llvm.org/t/rfc-project-hand-in-hand-llvm-libc-libc-code-sharing/77701
