Those were spotted when a project unintentionally started exporting
these symbols from its ABI just by using the libc++ headers.
Differential Revision: https://reviews.llvm.org/D126496
While looking at D113413 I noticed that __log2i could perhaps be
improved to be both slightly smaller and faster.
projects/libcxx/benchmarks/sort.libcxx.out --benchmark_filter=BM_Sort_uint32_QuickSortAdversary*
suggests this is performance neutral, but it shaves a few bytes off the
benchmark binary, and even more off a Chromium build.
Differential revision: https://reviews.llvm.org/D125958
This commit ensures that we can include all libc++ headers with modules
enabled. It adds a test to ensure that this doesn't regress, which is
necessary because our modules CI job does not build in all Standard modes.
Differential Revision: https://reviews.llvm.org/D125331
Abseil benchmarks suggest that the conditional checks result in faster code (4-5x)
as they are compiled into conditional move instructions (cmov on x86).
Reviewed By: #libc, philnik, Mordante
Spies: pengfei, Mordante, philnik, libcxx-commits
Differential Revision: https://reviews.llvm.org/D125329
This fixes incorrect handling of non-moveable types, adding tests for this case.
See [issue 55346](https://github.com/llvm/llvm-project/issues/55346).
The current implementation is based on is_convertible, which is
[defined](https://timsong-cpp.github.io/cppwp/n4659/meta.rel#5) in terms of
validity of the following function:
```
To test() {
return declval<From>();
}
```
But this doesn't work if To and From are both some non-moveable type, which the
[definition](https://timsong-cpp.github.io/cppwp/n4659/conv#3) of implicit
conversions says should work due to guaranteed copy elision:
```
To to = E; // E has type From
```
It is this latter definition that is used in the
[definition](https://timsong-cpp.github.io/cppwp/n4659/function.objects#func.require-2)
of INVOKE<R>. Make __invokable_r use __is_core_convertible, which
captures the ability to use guaranteed copy elision, making the
definition correct for non-moveable types.
Fixesllvm/llvm-project#55346.
Reviewed By: #libc, philnik, EricWF
Spies: EricWF, jloser, ldionne, philnik, libcxx-commits
Differential Revision: https://reviews.llvm.org/D125300
All compilers that libc++ supports support `push_macro` and `pop_macro`. So let's remove it.
Reviewed By: ldionne, #libc
Spies: libcxx-commits, mgorny
Differential Revision: https://reviews.llvm.org/D126073
`<type_traits>` is quite a large header, so I'll granularize it in a few steps.
Reviewed By: ldionne, #libc
Spies: libcxx-commits, mgorny
Differential Revision: https://reviews.llvm.org/D124755
We should not surface CMake-level options like LIBCXX_ENABLE_FILESYSTEM
to our users, since they don't know what it means. Instead, use a slightly
more general wording.
Also, add an error in <ios> to improve the quality of errors for people
trying to use <iostream> when localization is disabled.
Differential Revision: https://reviews.llvm.org/D125910
We require move semantics in C++03 anyways, so let's enable them for the containers.
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D123802
Use a specialized buffer wrapper to limit the number of insertions in the
buffer. After the limit has been reached the buffer only needs to count
the number of insertions to return the buffer size required to store the
entire output.
Depends on D110498
Reviewed By: #libc, Mordante
Differential Revision: https://reviews.llvm.org/D110499
This optimizes the __format_arg_store type to allow a more efficient
storage of the basic_format_args.
It stores the data in two arrays:
- A struct with the tag of the exposition only variant's type and the
offset of the element in the data array. Since this array only depends
on the type information it's calculated at compile time and can be
shared by different instances of this class.
- The arguments converted to the types used in the exposition only
variant of basic_format_arg. This means the packed data can be
directly copied to an element of this variant.
The new code uses rvalue reference arguments in preparation for P2418.
The handle class also has some changes to prepare for P2418. The real
changed for P2418 will be done separately, but these parts make it
easier to implement that paper.
Some parts of existing test code are removed since they were no longer
valid after the changes, but new tests have been added.
Implements parts of:
- P2418 Add support for std::generator-like types to std::format
Completes:
- LWG3473 Normative encouragement in non-normative note
Depends on D121138
Reviewed By: #libc, vitaut, Mordante
Differential Revision: https://reviews.llvm.org/D121514
This formatter isn't in the list of required formatters in
[format.formatter.spec]/2.2
For each charT, the string type specializations
template<> struct formatter<charT*, charT>;
template<> struct formatter<const charT*, charT>;
template<size_t N> struct formatter<const charT[N], charT>;
template<class traits, class Allocator>
struct formatter<basic_string<charT, traits, Allocator>, charT>;
template<class traits>
struct formatter<basic_string_view<charT, traits>, charT>;
Since remove_cvref_t<const charT[N]> is charT[N] the formatter is
required by
[format.functions]/25
Preconditions: formatter<remove_cvref_t<Ti>, charT> meets the
BasicFormatter requirements ([formatter.requirements]) for each Ti in
Args.
Depends on D120921
Reviewed By: #libc, Mordante
Differential Revision: https://reviews.llvm.org/D121138
The concept is based on P2286R2 Formatting Ranges. It will be used to
optimise the storage of __format_arg_store as required by LWG-3473.
Depends on D120916
Reviewed By: #libc, Mordante
Differential Revision: https://reviews.llvm.org/D120921
As mentionned in D97044, it is fine if users include <atomic> and then
include <stdatomic.h> -- we don't need to error out for that case.
Differential Revision: https://reviews.llvm.org/D125579
This simplifies the string structs a bit more and the normal layout should not contain any undefined behaviour anymore. I don't think there is a way to achieve this in the alternate string mode without breaking the ABI.
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D125496
This patch overhauls how we pick up the ABI library. Instead of setting
ad-hoc flags, it creates interface targets that can be linked against by
the rest of the build, which is easier to follow and extend to support
new ABI libraries.
This is intended to be a NFC change, however there are some additional
simplifications and improvements we can make in the future that would
require a slight behavior change.
Differential Revision: https://reviews.llvm.org/D120727
I guess this is an ABI break for the 32 bit AIX configuration, but I'm
not sure if that one is meant to be ABI stable yet or not.
Previously, this used int32_t for this type on linux, but int64_t
on all other platforms. This was added in D68480 /
54fa9ecd30, but I don't really see
any discussion around this detail there.
Switching this to 32 bit on 32 bit AIX silences these libcxx build
warnings:
```
In file included from /scratch/powerllvm/cpap8006/llvm-project/libcxx-ci/libcxx/src/atomic.cpp:12:
/scratch/powerllvm/cpap8006/llvm-project/libcxx-ci/build/aix/include/c++/v1/atomic:1005:12: warning: large atomic operation may incur significant performance penalty; the access size (8 bytes) exceeds the max lock-free size (4 bytes) [-Watomic-alignment]
return __c11_atomic_fetch_add(&__a->__a_value, __delta, static_cast<__memory_order_underlying_t>(__order));
^
/scratch/powerllvm/cpap8006/llvm-project/libcxx-ci/build/aix/include/c++/v1/atomic:948:12: warning: large atomic operation may incur significant performance penalty; the access size (8 bytes) exceeds the max lock-free size (4 bytes) [-Watomic-alignment]
return __c11_atomic_load(const_cast<__ptr_type>(&__a->__a_value), static_cast<__memory_order_underlying_t>(__order));
^
/scratch/powerllvm/cpap8006/llvm-project/libcxx-ci/build/aix/include/c++/v1/atomic:1000:12: warning: large atomic operation may incur significant performance penalty; the access size (8 bytes) exceeds the max lock-free size (4 bytes) [-Watomic-alignment]
return __c11_atomic_fetch_add(&__a->__a_value, __delta, static_cast<__memory_order_underlying_t>(__order));
^
/scratch/powerllvm/cpap8006/llvm-project/libcxx-ci/build/aix/include/c++/v1/atomic:1022:12: warning: large atomic operation may incur significant performance penalty; the access size (8 bytes) exceeds the max lock-free size (4 bytes) [-Watomic-alignment]
return __c11_atomic_fetch_sub(&__a->__a_value, __delta, static_cast<__memory_order_underlying_t>(__order));
^
4 warnings generated.
```
Differential Revision: https://reviews.llvm.org/D124519
After feedback from D122861, do the same thing with some of the other headers. Try to move the
headers so they have a similar style and way of doing things.
Reviewed By: ldionne, daltenty
Differential Revision: https://reviews.llvm.org/D124227
This only adds the customization point object (which isn't pipeable),
the view itself has already been implemented previously.
Differential Revision: https://reviews.llvm.org/D124978
[libcxx] Reject month 0 in get_date/__get_month
This fixes#47663.
Months in dates should be >= 1 and <= 12.
We parse up to two digits then minus one, because
we want to store this as "months since January"
(0-11).
However we didn't check that the result of that
was not -1. For example if you had (MM/DD/YYYY)
00/21/2022.
Added tests for:
* Failing if month is 0
* Failing if month is 13
* Allowing a leading zero in month e.g. "01"
Note that libc++ and libstdc++ return different
values on parsing failure, and MSVC STL returns
end of stream instead.
Handle the first two by checking for defines, MSVC STL
expects these tests to fail for other reasons already:
https://github.com/microsoft/STL/blob/main/tests/libcxx/expected_results.txt#L372
so not handling that case here.
Reviewed By: #libc, Mordante
Differential Revision: https://reviews.llvm.org/D124175
There are many more instances of this pattern, but I chose to limit this change to .rst files (docs), anything in libcxx/include, and string literals. These have the highest chance of being seen by end users.
Reviewed By: #libc, Mordante, martong, ldionne
Differential Revision: https://reviews.llvm.org/D124708
Several helper functions specify preconditions as comments, but we never
check them. I ran across a bug report (without a reproducer) in this code,
and I thought that having these assertions in place would make it easier
to troubleshoot.
Differential Revision: https://reviews.llvm.org/D124477
Nikolas Klauser