This patch is the rebase and squash of three earlier patches.
It supersedes all three of them.
- D47111: experimental monotonic_buffer_resource.
- D47358: experimental pool resources.
- D47360: Copy std::experimental::pmr to std::pmr.
The significant difference between this patch and the-sum-of-those-three
is that this patch does not add `std::experimental::pmr::monotonic_buffer_resource`
and so on. This patch simply adds the C++17 standard facilities, and
leaves the `std::experimental` namespace entirely alone.
Differential Revision: https://reviews.llvm.org/D89057
Implementing the paper
P2291R3 Add Constexpr Modifiers to Functions to_chars and from_chars for
Integral Types in <charconv> Header
Gives issues in language versions prior to C++17. As suggested in
D131855 disable the code prior to C++17. This removes libc++'s
extension.
Reviewed By: ldionne, #libc_vendors, #libc, philnik
Differential Revision: https://reviews.llvm.org/D133216
implement `std::ranges::basic_istream_view` and `std::views::istream`. Although the view itself is constexpr,
the constructor argument is a base class std::istream where its ctor/dtor are not constexpr. So no tests are performed in
constexpr
Differential Revision: https://reviews.llvm.org/D133317
As PR56606 stated, the current implementation of CityHash in libc++
would drop some bits unintentionally. Cast the 32bit int to the 64bit
int to avoid this happened.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D134124
This concept is introduced in P2286, but was implemented in libc++
before. This implementation was used in the library internally. This
implementation lacked the resolution of LWG3636. The original formatter
had a non-const member function that wasn't trivial to make a const
member. The recent parser improvements made this member a const member
in preparation of LWG3636.
Note LWG3636 isn't voted in. Its status is Ready. P2286's concept has
been written as-if LWG3636 is accepted and refers to that LWG issue.
Updates some tests make format a const member function and removes a
tests that's mainly a duplicate of the formattable concept test.
Implements
- LWG3636 formatter<T>::format should be const-qualified
Implements parts of
- P2286R8 Formatting Ranges
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D134110
This adds support for the new code points in the Extended Grapheme
Cluster algorithm. The algorithm itself has remained unchanged.
The width estimation still follows the rules of the Standard.
@cor3ntin filed
LWG3780 format's width estimation is too approximate and not forward compatible
to improve the estimate.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D134106
There are a handful of standard library types that are intended
to support CTAD but don't need any explicit deduction guides to
do so.
This patch adds a dummy deduction guide to those types to suppress
-Wctad-maybe-unsupported (which gets emitted in user code).
This is a re-application of the original patch by Eric Fiselier in
fcd549a7d8 which had been reverted due to reasons lost at this point.
I also added the macro to a few more types. Reviving this patch was
prompted by the discussion on https://llvm.org/D133425.
Differential Revision: https://reviews.llvm.org/D133535
Instead of using `reverse_iterator`, share the optimization between the 4 algorithms. The key observation here that `memmove` applies to both `copy` and `move` identically, and to their `_backward` versions very similarly. All algorithms now follow the same pattern along the lines of:
```
if constexpr (can_memmove<InIter, OutIter>) {
memmove(first, last, out);
} else {
naive_implementation(first, last, out);
}
```
A follow-up will delete `unconstrained_reverse_iterator`.
This patch removes duplication and divergence between `std::copy`, `std::move` and `std::move_backward`. It also improves testing:
- the test for whether the optimization is used only applied to `std::copy` and, more importantly, was essentially a no-op because it would still pass if the optimization was not used;
- there were no tests to make sure the optimization is not used when the effect would be visible.
Differential Revision: https://reviews.llvm.org/D130695
Implement LWG 3629, by making lookup for make_error_code and
make_error_condition only consider names found by ADL. This is achieved
by adding a block scope using-declaration for a function that will be
found by unqualified lookup, preventing unqualified lookup from
continuing to enclosing scopes (the class scope, then enclosing
namespaces). The function named by the using declaration is not
viable, so overload resolution must select a candidate found by ADL.
This fixes https://github.com/llvm/llvm-project/issues/57614
Differential Revision: https://reviews.llvm.org/D134943
By default, Clang does not include headers that are skipped due to
the include guard optimization in the --trace-includes output, which
breaks the use case that we were trying to use it for.
However, Clang does support the -fshow-skipped-includes flag, which
does exactly what we need and will result in an accurate include
graph.
As a fly-by fix, make sure that our includes don't differ between
-fexceptions and -fno-exceptions.
Differential Revision: https://reviews.llvm.org/D134829
If a C source file includes the libc++ stdatomic.h, compilation will
break because (a) the C++ standard check will fail (which is expected),
and (b) `_LIBCPP_COMPILER_CLANG_BASED` won't be defined because the
logic defining it in `__config` is guarded by a `__cplusplus` check, so
we'll end up with a blank header. Move the detection logic outside of
the `__cplusplus` check to make the second check pass even in a C context
when you're using Clang. Note that `_LIBCPP_STD_VER` is not defined when
in C mode, hence stdatomic.h needs to check if in C++ mode before using
that macro to avoid a warning.
In an ideal world, a C source file wouldn't be including the libc++
header directory in its search path, so we'd never have this issue.
Unfortunately, certain build environments make this hard to guarantee,
and in this case it's easy to tweak this header to make it work in a C
context, so I'm hoping this is acceptable.
Fixes https://github.com/llvm/llvm-project/issues/57710.
Differential Revision: https://reviews.llvm.org/D134591
In the implementation of `std::views::take`, it uses `subrange<Iter>` as part of the return type. But in case of input iterator, `subrange<Iter>` can be ill-formed
Differential Revision: https://reviews.llvm.org/D133220
The new version is a lot simpler and has less option which were not
used. This uses the CSV files as generated by D133127 as input data.
The current Python script has more features but uses a simple "grep"
making the output less accurate:
- Conditionally included header are always included. This is an issue
since part of our includes are unneeded transitive includes. Based on
the language version they may be omitted. The script however always
includes them.
- Includes in comments are processed as-if they are includes. This is an
issue when comments explain how certain data is generated; of course
there are digraphs which the script omits.
This implementation uses Clang's --trace-includes to generate the includes
per header. This means the input of the generation script always has the
real list of includes.
Libc++ is moving from large monolithic Standard headers to more fine
grained headers. For example, algorithm includes every header in
`__algorithm`. Adding all these detail headers in the graph makes the
output unusable. Instead it only shows the Standard headers. The
transitive includes of the detail headers are parsed and "attributed" to
the Standard header including them. This gives an accurate include graph
without the unneeded clutter. Note that this graph is still big.
This changes fixes the cyclic dependency issue with the previous version
of the tool so the markers and its documentation is removed.
Since the input has no cycles the CI test is removed.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D134188
While testing a test failure of C++17 with Clang ToT it was noticed the
paper
P0602R4 variant and optional should propagate copy/move triviality
was not applied as a DR in libc++.
This was discovered while investigating the issue "caused by" D131479.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D133326
Switch to the new granular format_functions header. Since the chrono's
format dependency in C++20 hasn't been in a release it's save to remove
it.
Depends on D133665
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D133796
It's been one and a half months now and nobody said anything, so I guess this code can be removed.
Reviewed By: ldionne, #libc
Spies: Mordante, libcxx-commits, mgorny, mstorsjo
Differential Revision: https://reviews.llvm.org/D132943
Using the `enable_if_t<..., int> = 0` style has the benefit that it works in all cases and makes function declarations easier to read because the function arguments and return type and SFINAE are separated. Unifying the style also makes it easier for people not super familiar with SFINAE to make sense of the code.
Reviewed By: Mordante, var-const, #libc, huixie90
Spies: huixie90, libcxx-commits
Differential Revision: https://reviews.llvm.org/D131868
In https://llvm.org/D56913, we added an emulation for the __atomic_always_lock_free
compiler builtin when compiling in Freestanding mode. However, the emulation
did (and could not) give exactly the same answer as the compiler builtin,
which led to a potential ABI break for e.g. enum classes.
After speaking to the original author of D56913, we agree that the correct
behavior is to instead always use the compiler builtin, since that provides
a more accurate answer, and __atomic_always_lock_free is a purely front-end
builtin which doesn't require any runtime support. Furthermore, it is
available regardless of the Standard mode (see https://godbolt.org/z/cazf3ssYY).
However, this patch does constitute an ABI break. As shown by https://godbolt.org/z/1eoex6zdK:
- In LLVM <= 11.0.1, an atomic<enum class with 1 byte> would not contain a lock byte.
- In LLVM >= 12.0.0, an atomic<enum class with 1 byte> would contain a lock byte.
This patch breaks the ABI again to bring it back to 1 byte, which seems
like the correct thing to do.
Fixes#57440
Differential Revision: https://reviews.llvm.org/D133377
compressed_pair is widely used in the library, but most of the uses don't use the tuple parts. To avoid including <tuple> everywhere, use the forward declaration instead in compressed_pair.h
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D133331
This removes a lot of boilerplate code.
Reviewed By: ldionne, #libc
Spies: EricWF, libcxx-commits
Differential Revision: https://reviews.llvm.org/D128081
As the comment suggests, `_LIBCPP_HAS_NO_PLATFORM_WAIT` is not documented or
defined anywhere internally in the build system. It's a direct define in terms
of `_LIBCPP_HAS_NO_THREADS`. So, remove `_LIBCPP_HAS_NO_PLATFORM_WAIT` and use
`_LIBCPP_HAS_NO_THREADS` instead to control the desired behavior.
Differential Revision: https://reviews.llvm.org/D132715
This change correct a configuration check that relies on the glibc __GLIBC_USE
macro being defined. Previously, the function-like macro was expanded without
ensuring it was actually defined. This resulted in compilation failures for
glibc versions prior to 2.25 (the glibc version in which the macro was added).
Differential Revision: https://reviews.llvm.org/D130946
It seems these includes are still provided by the sub headers, so it only
removes the duplicates.
There is no change in the list of includes, but the change affects the
modular build. By not having the includes in the top-level header the
module map has changed. This uncovers missing includes in the tests
and missing exports in the module map. This causes the huge amount of
changes in the patch.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D133252
This change implements the C library dependent portions of P0482R6
(char8_t: A type for UTF-8 characters and strings (Revision 6)) by
declaring std::c8rtomb() and std::mbrtoc8() in the <cuchar> header
when implementations are provided by the C library as specified by
WG14 N2653 (char8_t: A type for UTF-8 characters and strings
(Revision 1)) as adopted for C23.
A _LIBCPP_HAS_NO_C8RTOMB_MBRTOC8 macro is defined by the libc++ __config
header unless it is known that the C library provides these functions
in the current compilation mode. This macro is used for testing purposes
and may be of use to libc++ users. At present, the only C library known
to implement these functions is GNU libc as of its 2.36 release.
Reviewed By: ldionne
Differential Revision: https://reviews.llvm.org/D130946
We've decided to use `_LIBCPP_STD_VER >= xy` while discussing to change the constexpr macros, so let's finally bump the version macro to match that.
Reviewed By: ldionne, Mordante, huixie90, #libc, avogelsgesang
Spies: avogelsgesang, libcxx-commits
Differential Revision: https://reviews.llvm.org/D133323
Instead of mentioning tm directly in the definition of __convert_to_tm,
take it as a template argument. As a fly-by also fix incorrect Lit feature
(should have been no-localization instead of libcpp-has-no-localization).
Differential Revision: https://reviews.llvm.org/D133490
During the discussion on the SG-10 mailinglist regarding the format
feature-test macros voted in during the last plenary it turns out libc++
can't mark the format feature-test macro as implemented.
According to
https://isocpp.org/std/standing-documents/sd-6-sg10-feature-test-recommendations#__cpp_lib_format
the not yet implemented paper
P1361R2 Integration of chrono with text formatting
affects the feature test macro.
Note that P1361R2 doesn't mention the feature-test macro nor is there an
LWG-issue to address the issue. The reporter of the issue didn't recall
where this requirement exactly has been decided.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D133271
We require rvalue support anyways, so let's use it.
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D133013
