Completes:
- LWG3359 <chrono> leap second support should allow for negative leap
seconds
- P1361R2 Integration of chrono with text formatting
Implements parts of:
- P0355 Extending <chrono> to Calendars and Time Zones
Fixes: #100432Fixes: #100014
This patch separates the destroy algorithms from the primitive
construct_at and destroy_at operations, which are conceptually not
algorithms. This makes it easier to start using these destroy algorithms
from upcoming relocation facilities.
As part of this, it also implements `std::destroy_at` for arrays without
relying on the `std::destroy` algorithm, which is conceptually a
higher-level facility.
Implements parts of:
- P0355 Extending <chrono> to Calendars and Time Zones
- P1361 Integration of chrono with text formatting
- LWG3359 <chrono> leap second support should allow for negative leap
seconds
This changes the __output_buffer to a new structure. This improves the
performace of std::format, std::format_to, std::format_to_n, and
std::formatted_size.
While implementing this feature and its associated LWG issues it turns
out
- LWG3316 Correctly define epoch for utc_clock / utc_timepoint only
added non-normative wording to the standard.
Implements parts of:
- P0355 Extending <chrono> to Calendars and Time Zones
- P1361 Integration of chrono with text formatting
- LWG3359 <chrono> leap second support should allow for negative leap
seconds
Implementing `constexpr std::stable_sort`. This is part of P2562R1,
tracked via issue #105360.
Closes#119394
Co-authored-by: A. Jiang <de34@live.cn>
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
This follows the same path we've been doing for all platforms so far,
moving away from the old definition of the locale base API.
Co-authored-by: Daniel Thornburgh <mysterymath@gmail.com>
Currently, places where we call __libcpp_allocate must drop type
information on the ground even when they actually have such information
available. That is unfortunate since some toolchains and system
allocators are able to provide improved security when they know what
type is being allocated.
This is the purpose of http://wg21.link/p2719, where we introduce a new
variant of `operator new` which takes a type in its interface. A
different but related issue is that `std::allocator` does not honor any
in-class `T::operator new` since it is specified to call the global
`::operator new` instead.
This patch closes the gap to make it trivial for implementations that
provide typed memory allocators to actually benefit from that
information in more contexts, and also makes libc++ forward-compatible
with future proposals that would fix the existing defects in
`std::allocator`. It also makes the internal allocation API higher level
by operating on objects instead of operating on bytes of memory.
Since this is a widely-used function and making this a template could
have an impact on debug info sizes, I tried minimizing the number of
templated layers by removing `__do_deallocate_handle_size`, which was
easy to replace with a macro (and IMO this leads to cleaner code).
Instead of requiring `uselocale()` as part of the base locale API,
define __locale_guard in the few places that need it directly, without
making __locale_guard part of the base API.
In practice, most mainstream platforms never used __locale_guard, so
they also didn't need to define uselocale(), and after this patch they
actually don't define it anymore.
This change has a long history. It was first attempted naively in
https://reviews.llvm.org/D131425, which didn't work because we broke the
ability for code to include e.g. <stdio.h> multiple times and get
different definitions based on the pre-defined macros.
However, in #86843 we managed to simplify <stddef.h> by including the
underlying system header outside of any include guards, which worked.
This patch applies the same simplification we did to <stddef.h> to the
other headers that currently mention __need_FOO macros explicitly.
This patch reimplements the locale base support for Windows flavors in a
way that is more modules-friendly and without defining non-internal
names.
Since this changes the name of some types and entry points in the built
library, this is effectively an ABI break on Windows (which is
acceptable after checking with the Windows/libc++ maintainers).
This disentangles the code which previously had a mix of many #ifdefs, a
non-versioned namespace and a versioned namespace. It also makes it
clearer which parts of <new> are implemented on Windows by including <new.h>.
This patch documents the underlying API for implementing atomics on a
platform.
This doesn't change the operations that std::atomic is based on, but it
reorganizes the C11 / GCC implementation split to make it clearer what's
the base support layer and what's not.
This simplifies the implementation a bit, since we don't need a lot of
the `__has_x` classes anymore. We just need two template aliases to
implement the `allocator_traits` aliases now.
The __atomic_base base class is only useful to conditionalize the
operations we provide inside std::atomic. It shouldn't be used directly
from other places in the library which can use std::atomic directly
instead.
Since we've granularized our includes, using std::atomic directly should
not make much of a difference compile-time wise.
This patch starts using std::atomic directly from other classes like
std::barrier and std::latch. Changing this shouldn't be an ABI break
since both classes have the same size and layout.
The benefits of this patch are isolating other parts of the code base
from implementation details of std::atomic and simplifying the mental
model for std::atomic's layers of implementation by making it clear that
__atomic_base is only an implementation detail of std::atomic.
`__shared_count` is used in a few places where `shared_ptr` isn't. This
avoids a bunch of transitive includes needed for the implementation of
`shared_ptr` in these places.
This introduces a new `__scope_guard` without any fancy features. The
scope guard is used in `<string>` to simplify some of the ASan
annotations (especially by making it harder to forget them where
exceptions are thrown).
Instead of going through the old locale entry points, define the base
localization API for BSD-like platforms (Apple and FreeBSD) from
scratch, using <xlocale.h> as a basis. This doesn't actually change how
that functionality is implemented, it only avoids going through a maze
to do so.
This clean new support is implemented in a separate __locale_dir/support
directory, which mirrors what we do for the threading support API.
Eventually, everything under __locale_dir/locale_base_api will go away.
rdar://131476632
This patch introduces a new kind of bounded iterator that knows the size
of its valid range at compile-time, as in std::array. This allows computing
the end of the range from the start of the range and the size, which requires
storing only the start of the range in the iterator instead of both the start
and the size (or start and end). The iterator wrapper is otherwise identical
in design to the existing __bounded_iter.
Since this requires changing the type of the iterators returned by
std::array, this new bounded iterator is controlled by an ABI flag.
As a drive-by, centralize the tests for std::array::operator[] and add
missing tests for OOB operator[] on non-empty arrays.
Fixes#70864
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>
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.
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.
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
These headers are not doing anything beyond the system or compiler
provided equivalent headers, so there's no real reason to keep them
around. Reducing the number of C headers we provide in libc++ simplifies
our header layering and reduces the potential for confusion when headers
are layered incorrectly.
This is a re-application of bc6bd3bc1e which was reverted in
f11abac652 because it broke the Clang pre-commit CI.
Original commit message:
This patch rewrites the modulemap to have fewer top-level modules.
Previously, our modulemap had one top level module for each header in
the library, including private headers. This had the well-known problem
of making compilation times terrible, in addition to being somewhat
against the design principles of Clang modules.
This patch provides almost an order of magnitude compilation time
improvement when building modularized code (certainly subject to
variations). For example, including <ccomplex> without a module cache
went from 22.4 seconds to 1.6 seconds, a 14x improvement.
To achieve this, one might be tempted to simply put all the headers in a
single top-level module. Unfortunately, this doesn't work because libc++
provides C compatibility headers (e.g. stdlib.h) which create cycles
when the C Standard Library headers are modularized too. This is
especially tricky since base systems are usually not modularized: as far
as I know, only Xcode 16 beta contains a modularized SDK that makes this
issue visible. To understand it, imagine we have the following setup:
// in libc++'s include/c++/v1/module.modulemap
module std {
header stddef.h
header stdlib.h
}
// in the C library's include/module.modulemap
module clib {
header stddef.h
header stdlib.h
}
Now, imagine that the C library's <stdlib.h> includes <stddef.h>,
perhaps as an implementation detail. When building the `std` module,
libc++'s <stdlib.h> header does `#include_next <stdlib.h>` to get the C
library's <stdlib.h>, so libc++ depends on the `clib` module.
However, remember that the C library's <stdlib.h> header includes
<stddef.h> as an implementation detail. Since the header search paths
for libc++ are (and must be) before the search paths for the C library,
the C library ends up including libc++'s <stddef.h>, which means it
depends on the `std` module. That's a cycle.
To solve this issue, this patch creates one top-level module for each C
compatibility header. The rest of the libc++ headers are located in a
single top-level `std` module, with two main exceptions. First, the
module containing configuration headers (e.g. <__config>) has its own
top-level module too, because those headers are included by the C
compatibility headers.
Second, we create a top-level std_core module that contains several
dependency-free utilities used (directly or indirectly) from the __math
subdirectory. This is needed because __math pulls in a bunch of stuff,
and __math is used from the C compatibility header <math.h>.
As a direct benefit of this change, we don't need to generate an
artificial __std_clang_module header anymore to provide a monolithic
`std` module, since our modulemap does it naturally by construction.
A next step after this change would be to look into whether math.h
really needs to include the contents of __math, and if so, whether
libc++'s math.h truly needs to include the C library's math.h header.
Removing either dependency would break this annoying cycle.
Thanks to Eric Fiselier for pointing out this approach during a recent
meeting. This wasn't viable before some recent refactoring, but wrapping
everything (except the C headers) in a large module is by far the
simplest and the most effective way of doing this.
Fixes#86193
Instead of changing the cast sequence to implicit conversion in
_`voidify`_, I think it is better to totally remove `__voidify` and use
`static_cast` to `void*`, which has equivalent effects.
Test coverage for const iterators are removed.
Now most affected algorithms are underconstrained, for which I submitted
[LWG3888](https://cplusplus.github.io/LWG/issue3888). I'm not sure
whether we should speculatively implement it at this moment, and thus
haven't added any `*.verify.cpp`.
In some control block types and `optional`, the stored objects are
changed to have cv-unqualified type.
Fixes#105119.
This allows catching OOB accesses inside `unique_ptr<T[]>` when the size
of the allocation is known. The size of the allocation can be known when
the unique_ptr has been created with make_unique & friends or when the
type necessitates an array cookie before the allocation.
This is a re-aplpication of 45a09d181 which had been reverted in
f11abac6 due to unrelated CI failures.
This follows the pattern we use consistently for ranges algorithms.
This is a re-application of 24bc3244d4 which had been reverted in
f11abac65 due to unrelated failures.
