Also:
- refactor out `__voidify`;
- use the `destroy` algorithm internally;
- refactor out helper classes used in tests for `uninitialized_*`
algorithms.
Differential Revision: https://reviews.llvm.org/D115626
There is no need to check the counters on `Counted` after destroying
elements in the range because these tests are not testing `destroy`.
Differential Revision: https://reviews.llvm.org/D115839
Defined in [`specialized.algorithms`](wg21.link/specialized.algorithms).
Also:
- refactor the existing non-range implementation so that most of it
can be shared between the range-based and non-range-based algorithms;
- remove an existing test for the non-range version of
`uninitialized_default_construct{,_n}` that likely triggered undefined
behavior (it read the values of built-ins after default-initializing
them, essentially reading uninitialized memory).
Reviewed By: #libc, Quuxplusone, ldionne
Differential Revision: https://reviews.llvm.org/D115315
Microsoft would like to contribute its implementation of floating-point to_chars to libc++. This uses the impossibly fast Ryu and Ryu Printf algorithms invented by Ulf Adams at Google. Upstream repos: https://github.com/microsoft/STL and https://github.com/ulfjack/ryu .
Licensing notes: MSVC's STL is available under the Apache License v2.0 with LLVM Exception, intentionally chosen to match libc++. We've used Ryu under the Boost Software License.
This patch contains minor changes from Jorg Brown at Google, to adapt the code to libc++. He verified that it works in Google's Linux-based environment, but then I applied more changes on top of his, so any compiler errors are my fault. (I haven't tried to build and test libc++ yet.) Please tell me if we need to do anything else in order to follow https://llvm.org/docs/DeveloperPolicy.html#attribution-of-changes .
Notes:
* libc++'s integer charconv is unchanged (except for a small refactoring). MSVC's integer charconv hasn't been tuned for performance yet, so you're not missing anything.
* Floating-point from_chars isn't part of this patch because Jorg found that MSVC's implementation (derived from our CRT's strtod) was slower than Abseil's. If you're unable to use Abseil or another implementation due to licensing or technical considerations, Microsoft would be delighted if you used MSVC's from_chars (and you can just take it, or ask us to provide a patch like this). Ulf is also working on a novel algorithm for from_chars.
* This assumes that float is IEEE 32-bit, double is IEEE 64-bit, and long double is also IEEE 64-bit.
* I have added MSVC's charconv tests (the whole thing: integer/floating from_chars/to_chars), but haven't adapted them to libcxx's harness at all. (These tests will be available in the microsoft/STL repo soon.)
* Jorg added int128 codepaths. These were originally present in upstream Ryu, and I removed them from microsoft/STL purely for performance reasons (MSVC doesn't support int128; Clang on Windows does, but I found that x64 intrinsics were slightly faster).
* The implementation is split into 3 headers. In MSVC's STL, charconv contains only Microsoft-written code. xcharconv_ryu.h contains code derived from Ryu (with significant modifications and additions). xcharconv_ryu_tables.h contains Ryu's large lookup tables (they were sufficiently large to make editing inconvenient, hence the separate file). The xmeow.h convention is MSVC's for internal headers; you may wish to rename them.
* You should consider separately compiling the lookup tables (see https://github.com/microsoft/STL/issues/172 ) for compiler throughput and reduced object file size.
* See https://github.com/StephanTLavavej/llvm-project/commits/charconv for fine-grained history. (If necessary, I can perform some rebase surgery to show you what Jorg changed relative to the microsoft/STL repo; currently that's all fused into the first commit.)
Differential Revision: https://reviews.llvm.org/D70631
Microsoft would like to contribute its implementation of floating-point to_chars to libc++. This uses the impossibly fast Ryu and Ryu Printf algorithms invented by Ulf Adams at Google. Upstream repos: https://github.com/microsoft/STL and https://github.com/ulfjack/ryu .
Licensing notes: MSVC's STL is available under the Apache License v2.0 with LLVM Exception, intentionally chosen to match libc++. We've used Ryu under the Boost Software License.
This patch contains minor changes from Jorg Brown at Google, to adapt the code to libc++. He verified that it works in Google's Linux-based environment, but then I applied more changes on top of his, so any compiler errors are my fault. (I haven't tried to build and test libc++ yet.) Please tell me if we need to do anything else in order to follow https://llvm.org/docs/DeveloperPolicy.html#attribution-of-changes .
Notes:
* libc++'s integer charconv is unchanged (except for a small refactoring). MSVC's integer charconv hasn't been tuned for performance yet, so you're not missing anything.
* Floating-point from_chars isn't part of this patch because Jorg found that MSVC's implementation (derived from our CRT's strtod) was slower than Abseil's. If you're unable to use Abseil or another implementation due to licensing or technical considerations, Microsoft would be delighted if you used MSVC's from_chars (and you can just take it, or ask us to provide a patch like this). Ulf is also working on a novel algorithm for from_chars.
* This assumes that float is IEEE 32-bit, double is IEEE 64-bit, and long double is also IEEE 64-bit.
* I have added MSVC's charconv tests (the whole thing: integer/floating from_chars/to_chars), but haven't adapted them to libcxx's harness at all. (These tests will be available in the microsoft/STL repo soon.)
* Jorg added int128 codepaths. These were originally present in upstream Ryu, and I removed them from microsoft/STL purely for performance reasons (MSVC doesn't support int128; Clang on Windows does, but I found that x64 intrinsics were slightly faster).
* The implementation is split into 3 headers. In MSVC's STL, charconv contains only Microsoft-written code. xcharconv_ryu.h contains code derived from Ryu (with significant modifications and additions). xcharconv_ryu_tables.h contains Ryu's large lookup tables (they were sufficiently large to make editing inconvenient, hence the separate file). The xmeow.h convention is MSVC's for internal headers; you may wish to rename them.
* You should consider separately compiling the lookup tables (see https://github.com/microsoft/STL/issues/172 ) for compiler throughput and reduced object file size.
* See https://github.com/StephanTLavavej/llvm-project/commits/charconv for fine-grained history. (If necessary, I can perform some rebase surgery to show you what Jorg changed relative to the microsoft/STL repo; currently that's all fused into the first commit.)
Differential Revision: https://reviews.llvm.org/D70631
This patch removes the ability to build the runtimes in the 32 bit
multilib configuration, i.e. using -m32. Instead of doing this, one
should cross-compile the runtimes for the appropriate target triple,
like we do for all other triples.
As it stands, -m32 has several issues, which all seem to be related to
the fact that it's not well supported by the operating systems that
libc++ support. The simplest path towards fixing this is to remove
support for the configuration, which is also the best course of action
if there is little interest for keeping that configuration. If there
is a desire to keep this configuration around, we'll need to do some
work to figure out the underlying issues and fix them.
Differential Revision: https://reviews.llvm.org/D114473
This removes the `format_args_t` from `<format>` and adjusts the type of
the `format_args` for the `vformat_to` overloads.
The `format_context` uses a `back_insert_iterator<string>` therefore the
new `output_iterator` function uses a `string` as its temporary storage
buffer. This isn't ideal. The next patches in this series will improve
this. These improvements make it easy to also improve `format_to_n` and
`formatted_size`.
This addresses P2216 `6. Binary size`.
P2216 `5. Compile-time checks` are not part of this change.
Implements parts of:
- P2216 std::format improvements
Depends on D103670
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D110494
According to the C++ standard, the stored pointer and the stored deleter
should be value-initialized.
Differential Revision: https://reviews.llvm.org/D113612
At this point, every supported compiler that claims a -std=c++17 mode
should also support these features.
Differential Revision: https://reviews.llvm.org/D113436
However, whether applications rely on the std::bad_function_call vtable
being in the dylib is still controlled by the ABI macro, since changing
that would be an ABI break.
Also separate preprocessor definitions for whether to use a key function
and whether to use a `bad_function_call`-specific `what` message
(`what` message is mandated by [LWG2233](http://wg21.link/LWG2233)).
Differential Revision: https://reviews.llvm.org/D92397
This implements the following changes:
* AutoType retains sugared deduced-as-type.
* Template argument deduction machinery analyses the sugared type all the way
down. It would previously lose the sugar on first recursion.
* Undeduced AutoType will be properly canonicalized, including the constraint
template arguments.
* Remove the decltype node created from the decltype(auto) deduction.
As a result, we start seeing sugared types in a lot more test cases,
including some which showed very unfriendly `type-parameter-*-*` types.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Reviewed By: rsmith, #libc, ldionne
Differential Revision: https://reviews.llvm.org/D110216
This implements the following changes:
* AutoType retains sugared deduced-as-type.
* Template argument deduction machinery analyses the sugared type all the way
down. It would previously lose the sugar on first recursion.
* Undeduced AutoType will be properly canonicalized, including the constraint
template arguments.
* Remove the decltype node created from the decltype(auto) deduction.
As a result, we start seeing sugared types in a lot more test cases,
including some which showed very unfriendly `type-parameter-*-*` types.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Reviewed By: rsmith
Differential Revision: https://reviews.llvm.org/D110216
The ASAN build failed due to using pointers to a temporary whose
lifetime had expired.
Updating the libc++ Docker image to Ubuntu Focal caused some breakage.
This was temporary disabled in D112737. This re-enables two of these
tests.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D113137
The tests fails in debug mode since it manipulates an iterator to a
`std::string` returned from the dylib. This is a known issue for the
debug iterators.
Updating the libc++ Docker image to Ubuntu Focal caused some breakage.
This was temporary disabled in D112737. This re-enables one of these
tests.
Reviewed By: ldionne, #libc, Quuxplusone
Differential Revision: https://reviews.llvm.org/D113139
Deduction guides for containers should not participate in overload
resolution when called with certain incorrect types (e.g. when called
with a template argument in place of an `InputIterator` that doesn't
qualify as an input iterator). Similarly, class template argument
deduction should not select `unique_ptr` constructors that take a
a pointer.
The tests try out every possible incorrect parameter (but never more
than one incorrect parameter in the same invocation).
Also add deduction guides to the synopsis for associative and unordered
containers (this was accidentally omitted from [D112510](https://reviews.llvm.org/D112510)).
Differential Revision: https://reviews.llvm.org/D112904
This changes adds the pipeline config for both 32-bit and 64-bit AIX targets. As well, we add a lit feature `LIBCXX-AIX-FIXME` which is used to mark the failing tests which remain to be investigated on AIX, so that the CI produces a clean build.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D111359
Make test_allocator etc. constexpr-friendly so they can be used to test constexpr string and possibly constexpr vector
Reviewed By: Quuxplusone, #libc, ldionne
Differential Revision: https://reviews.llvm.org/D110994
Since we no longer officially support Clang 11 remove the work-arounds
for this version.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D112727
`libc++` has had the guarantee of the default constructor of `tuple<>` being
trivial since 405570dc7a. Now, the
standard mandates it as of LWG3211. So, move the file out of
`libcxx/test/libcxx` and into `libcxx/test/std` since it's no longer
`libc++`-specific. Rename it to be `.compile.pass.cpp` instead of
`.pass.cpp` while we're at it.
Reviewed By: ldionne, Quuxplusone, Mordante, #libc
Differential Revision: https://reviews.llvm.org/D112743
After recent changes to the Docker image, all hell broke loose and the
CI started failing. This patch marks a few tests as unsupported until
we can figure out what the issues are and fix them.
In the future, it would be ideal if the nodes could pick up the Dockerfile
present in the revision being tested, which would allow us to test changes
to the Dockerfile in the CI, like we do for all other code changes.
Differential Revision: https://reviews.llvm.org/D112737
Add deduction guides to `valarray` and `scoped_allocator_adaptor`. This largely
finishes implementation of the paper:
* deduction guides for other classes mentioned in the paper were
implemented previously (see the list below);
* deduction guides for several classes contained in the proposal
(`reference_wrapper`, `lock_guard`, `scoped_lock`, `unique_lock`,
`shared_lock`) were removed by [LWG2981](https://wg21.link/LWG2981).
Also add deduction guides to the synopsis for the few classes (e.g. `pair`)
where they were missing.
The only part of the paper that isn't fully implemented after this patch is
making sure certain deduction guides don't participate in overload resolution
when given incorrect template parameters.
List of significant commits implementing the other parts of P0433 (omitting some
minor fixes):
* [pair](af65856eec)
* [basic_string](6d9f750dec)
* [array](0ca8c0895c)
* [deque](dbb6f8a817)
* [forward_list](e076700b77)
* [list](4a227e582b)
* [vector](df8f754792)
* [queue/stack/priority_queue](5b8b8b5dce)
* [basic_regex](edd5e29cfe)
* [optional](f35b4bc395)
* [map/multimap](edfe8525de)
* [set/multiset](e20865c387)
* [unordered_set/unordered_multiset](296a80102a)
* [unordered_map/unordered_multimap](dfcd4384cb)
* [function](e1eabcdfad)
* [tuple](1308011e1b)
* [shared_ptr/weak_ptr](83564056d4)
Additional notes:
* It was revision 2 of the paper that was voted into the Standard.
P0433R3 is a separate paper that is not part of the Standard.
* The paper also mandates removing several `make_*_searcher` functions
(e.g. `make_boyer_moore_searcher`) which are currently not implemented
(except in `experimental/`).
* The `__cpp_lib_deduction_guides` feature test macro from the paper was
accidentally omitted from the Standard.
Differential Revision: https://reviews.llvm.org/D112510
Also fix a few places in the `shared_ptr` implementation where
`element_type` was passed to the `__is_compatible` helper. This could
result in `remove_extent` being applied twice to the pointer's template
type (first by the definition of `element_type` and then by the helper),
potentially leading to somewhat less readable error messages for some
incorrect code.
Differential Revision: https://reviews.llvm.org/D112092
Based on post-commit review discussion on
2bd8493847 with Richard Smith.
Other uses of forcing HasEmptyPlaceHolder to false seem OK to me -
they're all around pointer/reference types where the pointer/reference
token will appear at the rightmost side of the left side of the type
name, so they make nested types (eg: the "int" in "int *") behave as
though there is a non-empty placeholder (because the "*" is essentially
the placeholder as far as the "int" is concerned).
This was originally committed in 277623f4d5
Reverted in f9ad1d1c77 due to breakages
outside of clang - lldb seems to have some strange/strong dependence on
"char [N]" versus "char[N]" when printing strings (not due to that name
appearing in DWARF, but probably due to using clang to stringify type
names) that'll need to be addressed, plus a few other odds and ends in
other subprojects (clang-tools-extra, compiler-rt, etc).
Those creep up from time to time. We need to use `int main(int, char**)`
because in freestanding mode, `main` doesn't get special treatment and
special mangling, so we setup a symbol alias from the mangled version of
`main(int, char**)` to `extern "C" main`. That only works if all the tests
are consistent about how they define their main function.
The only possible kind of a conversion in initialization of a shared
pointer to an array is a qualification conversion (i.e., adding
cv-qualifiers). This patch adds tests for converting from `A[]` to
`const A[]` to the following functions:
```
template<class Y> explicit shared_ptr(Y* p);
template<class Y> shared_ptr(const shared_ptr<Y>& r);
template<class Y> shared_ptr(shared_ptr<Y>&& r);
template<class Y> shared_ptr& operator=(const shared_ptr<Y>& r);
template<class Y> shared_ptr& operator=(shared_ptr<Y>&& r);
template<class Y> void reset(Y* p);
template<class Y, class D> void reset(Y* p, D d);
template<class Y, class D, class A> void reset(Y* p, D d, A a);
```
Similar tests for converting functions that involve a `weak_ptr` should
be added once LWG issue [3001](https://cplusplus.github.io/LWG/issue3001)
is implemented.
Differential Revision: https://reviews.llvm.org/D112048
Currently the member functions std::allocator<T>::allocate,
std::experimental::pmr::polymorphic_allocator::allocate and
std::resource_adaptor<T>::do_allocate throw an exception of type
std::length_error when the requested size exceeds the maximum size.
According to the C++ standard ([allocator.members]/4,
[mem.poly.allocator.mem]/1), std::allocator<T>::allocate and
std::pmr::polymorphic_allocator::allocate must throw a
std::bad_array_new_length exception in this case.
The patch fixes the issue with std::allocator<T>::allocate and changes
the type the exception thrown by
std::experimental::pmr::resource_adaptor<T>::do_allocate to
std::bad_array_new_length as well for consistency.
The patch resolves LWG 3237, LWG 3038 and LWG 3190.
Reviewed By: ldionne, #libc, Quuxplusone
Differential Revision: https://reviews.llvm.org/D110846
Some embedded platforms do not wish to support the C library functionality
for handling wchar_t because they have no use for it. It makes sense for
libc++ to work properly on those platforms, so this commit adds a carve-out
of functionality for wchar_t.
Unfortunately, unlike some other carve-outs (e.g. random device), this
patch touches several parts of the library. However, despite the wide
impact of this patch, I still think it is important to support this
configuration since it makes it much simpler to port libc++ to some
embedded platforms.
Differential Revision: https://reviews.llvm.org/D111265
Implement P2401 which adds a `noexcept` specification to
`std::exchange`. Treated as a defect fix which is the motivation for
applying this change to all standards mode rather than just C++23 or
later as the paper suggests.
Reviewed By: Quuxplusone, Mordante, #libc
Differential Revision: https://reviews.llvm.org/D111481
Replace `TEST_NOEXCEPT_FALSE` directly with `noexcept(false)` in
optional hash test which is only run in C++17 or later.
`TEST_NOEXCEPT_FALSE` is only useful in C++03 context where `noexcept`
isn't supported by clang. `TEST_NOEXCEPT_FALSE` now only has one remaining use
in `hash_unique_ptr.pass.cpp`.
Implement parts of P1614, including three-way comparison for tuples, and expand testing.
Reviewed By: ldionne, Mordante, #libc
Differential Revision: https://reviews.llvm.org/D108250
Implements the formatter for Boolean types.
[format.formatter.spec]/2.3
For each charT, for each cv-unqualified arithmetic type ArithmeticT other
than char, wchar_t, char8_t, char16_t, or char32_t, a specialization
```
template<> struct formatter<ArithmeticT, charT>;
```
This removes the stub implemented in D96664.
Implements parts of:
- P0645 Text Formatting
- P1652 Printf corner cases in std::format
Completes:
- P1868 width: clarifying units of width and precision in std::format
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D103670
Implements the formatter for all fundamental integer types.
[format.formatter.spec]/2.1
The specializations
```
template<> struct formatter<char, char>;
template<> struct formatter<char, wchar_t>;
template<> struct formatter<wchar_t, wchar_t>;
```
This removes the stub implemented in D96664.
Implements parts of:
- P0645 Text Formatting
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D103466
Implements the formatter for all fundamental integer types
(except `char`, `wchar_t`, and `bool`).
[format.formatter.spec]/2.3
For each charT, for each cv-unqualified arithmetic type ArithmeticT other
than char, wchar_t, char8_t, char16_t, or char32_t, a specialization
```
template<> struct formatter<ArithmeticT, charT>;
```
This removes the stub implemented in D96664.
As an extension it adds partial support for 128-bit integer types.
Implements parts of:
- P0645 Text Formatting
- P1652 Printf corner cases in std::format
Completes:
- LWG-3248 #b, #B, #o, #x, and #X presentation types misformat negative numbers
Reviewed By: #libc, ldionne, vitaut
Differential Revision: https://reviews.llvm.org/D103433
Implements the formatter for all string types.
[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>;
```
This removes the stub implemented in D96664.
Implements parts of:
- P0645 Text Formatting
- P1868 width: clarifying units of width and precision in std::format
Reviewed By: #libc, ldionne, vitaut
Differential Revision: https://reviews.llvm.org/D103425
Some tests repeat the definition of `DELETE_FUNCTION` macro locally.
However, it's not even requred to guard against in the C++03 case since
Clang supports `= delete;` in C++03 mode. A warning is issued but
`libc++` tests run with `-Wno-c++11-extensions`, so this isn't an issue.
Since we don't support other compilers in C++03 mode, `= delete;` is
always available for use. As such, inline all calls of `DELETE_FUNCTION`
to use `= delete;`.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D111148
Konstantin Varlamov