It was missing the cast to `bool` in `bool(__t.empty())`.
It was wrongly using `std::forward` in some places.
Differential Revision: https://reviews.llvm.org/D115312
During the review of D115991 @vitaut pointed out the enum shouldn't
depend on whether or not _LIBCPP_HAS_NO_INT128 is defined. The current
implementation lets the enum's ABI depend on this configuration option
without a good cause.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D116120
These headers have stabilized; we don't expect anyone to be
blindly clang-formatting them anymore.
Leave the comments in `__format/*.h` for Mark to remove at his leisure.
Clang is gaining `auto(x)` support in D113393; sadly there
seems to be no feature-test macro for it. Zhihao is opening
a core issue for that macro.
Use `_LIBCPP_AUTO_CAST` where C++20 specifies we should use `auto(x)`;
stop using `__decay_copy(x)` in those places.
In fact, remove `__decay_copy` entirely. As of C++20, it's purely
a paper specification tool signifying "Return just `x`, but it was
perfect-forwarded, so we understand you're going to have to call
its move-constructor sometimes." I believe there's no reason we'd
ever need to do its operation explicitly in code.
This heisenbugs away a test failure on MinGW; see D112214.
Differential Revision: https://reviews.llvm.org/D115686
As discussed with ldionne. The problem with this static_assert
is that it makes ranges::begin a pitfall for anyone ever to use
inside a constraint or decltype. Many Ranges things, such as ranges::size,
are specified as "Does X if X is well-formed, or else Y if Y is well-formed,
or else `ranges::end(t) - ranges::begin(t)` if that is well-formed, or else..."
And if there's a static_assert hidden inside `ranges::begin(t)`, then you get
a hard error as soon as you ask the question -- even if the answer would have
been "no, that's not well-formed"!
Constraining on `requires { t + 0; }` or `requires { t + N; }` is verboten
because of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103700 . For ranges::begin,
we can just decay to a pointer even in the incomplete-type case. For ranges::end,
we can safely constrain on `sizeof(*t)`. Yes, this means that an array of incomplete
type has a `ranges::begin` but no `ranges::end`... just like an unbounded array of
complete type. This is a valid manifestation of IFNDR.
All of the new libcxx/test/std/ cases are mandatory behavior, as far as I'm aware.
Tests for the IFNDR cases in ranges::begin and ranges::end remain in `libcxx/test/libcxx/`.
The similar tests for ranges::empty and ranges::data were simply wrong, AFAIK.
Differential Revision: https://reviews.llvm.org/D115838
This is similar to the existing setting LIBCXX_ABI_DEFINES, with
the difference that this also allows setting other defines than
ones that start with "_LIBCPP_ABI_", and allows setting defines
to a specific value.
This allows avoiding using LIBCXX_TEST_COMPILER_FLAGS in two
CI configurations.
Differential Revision: https://reviews.llvm.org/D116109
Allow `__move_constexpr` to work with unrelated pointers and `_LIBCPP_ASSERT` that `__copy_constexpr`, `__move_constexpr` and `__assign_constexpr` are only run during constant evaluation
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D115986
When P0883R2 was initially implemented in D103769 #pragma clang deprecated didn't exist yet.
We also forgot to cleanup usages in libc++ itself.
This takes care of both.
Differential Revision: https://reviews.llvm.org/D115995
__transaction is a helper class that allows rolling back code in case an
exception is thrown. The main goal is to reduce the clutter when code
needs to be guarded with `#if _LIBCPP_NO_EXCEPTIONS`.
Differential Revision: https://reviews.llvm.org/D115730
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
The inline keyword is required on those functions because they are defined
in the headers, so we need them to be inline to avoid ODR violations.
While we're at it, slap _LIBCPP_HIDE_FROM_ABI on them because they are
implementation details and we don't want them to be part of our ABI under
any circumstances.
Differential Revision: https://reviews.llvm.org/D115906
GCC currently does not allow `__builtin_strlen()` during constant evaluation. This PR adds a workaround in `std::char_traits<char>::length()`
Reviewed By: Quuxplusone, ldionne, #libc, Mordante
Spies: Mordante, libcxx-commits
Differential Revision: https://reviews.llvm.org/D115795
However, there's a problem on both GCC and Clang: they can't mangle
`__is_same(T,U)` if it appears anywhere that affects mangling. That's
a hard error. And it turns out that GCC puts dependent return types
into the mangling more aggressively than Clang, so for GCC's benefit
we need to avoid using raw `_IsSame` in the return type of
`swap(tuple&, tuple&)`. Therefore, make `__all` into a named type
instead of an alias.
If we ever need to support a compiler without the __is_same builtin,
we can make this an alias template for `is_same<T,U>::type`.
Differential Revision: https://reviews.llvm.org/D115100
Use `_LIBCPP_DEBUG_ASSERT` instead of `_LIBCPP_ASSERT` and guarding it with `LIBCPP_DEBUG_LEVEL == 2`
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D115765
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
As explained in https://stackoverflow.com/a/70339311/627587, the fact
that shrink_to_fit wasn't defined as inline lead to issues when explicitly
instantiating basic_string. While explicit instantiations are always
somewhat brittle, this one was clearly a bug on our end.
Differential Revision: https://reviews.llvm.org/D115656
When `a` was an array type, `__decay_copy(a)` was incorrectly marking itself
noexcept(false), because it is false that `int[10]` is nothrow convertible to `int[10]`
(in fact it is not convertible at all).
We have no tests explicitly for `__decay_copy`, but the new ranges::begin
and ranges::end tests fail before this patch.
Differential Revision: https://reviews.llvm.org/D115658
Just defensive CMake-ing. I pulled this from D115544 and D99484 which
are blocked on some lldb CI failures I don't yet understand. Hoping to land
something smaller in the meantime.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D115566
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
Use `= delete` for member functions that are marked with `// = delete;`
Reviewed By: ldionne, Quuxplusone, #libc
Spies: jloser, libcxx-commits
Differential Revision: https://reviews.llvm.org/D115291
In addition to being more consistent with our approach for helpers, this
solves an actual issue where <cmath> was using numeric_limits but never
including the <limits> header directly. In a normal setup, this is not
an issue because the <math.h> header included by <cmath> does include
<limits>. However, I did stumble upon some code where that didn't work,
most likely because they were placing their own <math.h> header in front
of ours. I didn't bother investigating further.
Differential Revision: https://reviews.llvm.org/D115282
clang has `= default` as an extension in c++03, so just use it.
Reviewed By: ldionne, Quuxplusone, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D115275
Before this patch, the new test's `CountedInvocable<int*, int*>`
would hard-error instead of SFINAEing and cleanly returning false.
Notice that views::counted specifically does NOT work with pipes;
`counted(42)` is ill-formed. This is because `counted`'s first argument
is supposed to be an iterator, not a range.
Also, mark `views::counted(it, n)` as [[nodiscard]], and test that.
(We have a general policy now that range adaptors are consistently
marked [[nodiscard]], so that people don't accidentally think that
they have side effects. This matters mostly for `reverse` and
`transform`, arguably `drop`, and just generally let's be consistent.)
Differential Revision: https://reviews.llvm.org/D115177
I assume nobody ever uses std::string_view::max_size() outside of
testing. However, we should still return a value that is based on
something with a reasonable rationale. Previously, we would forget
to take into account the size of the character type stored in the
string, and this patch takes that into account.
Thanks to @mclow.lists for pointing out this issue.
Differential Revision: https://reviews.llvm.org/D114395
Clang trunk rejects the new test case, but this is a Clang bug
(PR47414, 47509, 50864, 44833).
```
In module 'std' imported from /Users/aodwyer/llvm-project/libcxx/test/std/ranges/range.adaptors/range.transform/general.pass.cpp:17:
/Users/aodwyer/llvm-project/build2/include/c++/v1/__ranges/transform_view.h:85:44: error: constraints not satisfied for alias template 'range_reference_t' [with _Rp = const NonConstView]
regular_invocable<const _Fn&, range_reference_t<const _View>>
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/aodwyer/llvm-project/build2/include/c++/v1/__ranges/transform_view.h:416:25: note: in instantiation of template class 'std::ranges::transform_view<NonConstView, (lambda at /Users/aodwyer/llvm-project/libcxx/test/std/ranges/range.adaptors/range.transform/general.pass.cpp:73:71)>' requested here
-> decltype( transform_view(_VSTD::forward<_Range>(__range), _VSTD::forward<_Fn>(__f)))
^
```
We can work around this by adding a layer of indirection: put the
problematic constraint into a named concept and Clang becomes more
amenable to SFINAE'ing instead of hard-erroring.
Drive-by simplify `range.transform/general.pass.cpp` to make it clearer
what it's actually testing in this area.
Differential Revision: https://reviews.llvm.org/D115116
As discussed on the Discord, 2021-12-01 through 2021-12-05.
Our new consistent style for this is "don't align the right-braces"
(but still align the left-braces, as shown).
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
Implement the exposition-only concepts specified in
`[special.mem.concepts]`. These are all thin wrappers over other
concepts.
Reviewed By: #libc, Quuxplusone, ldionne
Differential Revision: https://reviews.llvm.org/D114761
Implement P1989R2 which adds a range constructor for `string_view`.
Adjust `operator/=` in `path` to avoid atomic constraints caching issue
getting provoked from this PR.
Add defaulted template argument to `string_view`'s "sufficient
overloads" to avoid mangling issues in `clang-cl` builds. It is a
MSVC mangling bug that this works around.
Differential Revision: https://reviews.llvm.org/D113161
`__wrap_iter` is currently only constexpr if it's not a debug built, but it isn't used in a constexpr context currently. Making it always constexpr and disabling the debugging utilities at constant evaluation is more usful since it has to be always constexpr to be used in a constexpr context.
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D114733
Disable the constructors taking `(size_type, const value_type&,
allocator_type)` if `allocator_type` is not a valid allocator.
Otherwise, these constructors are considered when resolving e.g.
`(int*, int*, NotAnAllocator())`, leading to a hard error during
instantiation. A hard error makes the Standard's requirement to not
consider deduction guides of the form `(Iterator, Iterator,
BadAllocator)` during overload resolution essentially non-functional.
The previous approach was to SFINAE away `allocator_traits`. This patch
SFINAEs away the specific constructors instead, for consistency with
`basic_string` -- see [LWG3076](wg21.link/lwg3076) which describes
a very similar problem for strings (note, however, that unlike LWG3076,
no valid constructor call is affected by the bad instantiation).
Differential Revision: https://reviews.llvm.org/D114311
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
Fixes https://llvm.org/PR51520. The problem is that `uniform_int_distribution`
currently uses an unsigned integer with at most 64 bits internally, which
is then casted to the desired result type. If the result type is `int64_t`,
this will produce a negative number if the most significant bit is set,
but if the result type is `__int128_t`, the value remains non-negative
and will be out of bounds for the example in PR#51520. (The reason why
it also seems to work if the upper or lower bound is changed is
because the branch at [1] will then no longer be taken, and proper
rejection sampling takes place.)
The bigger issue here is probably that `uniform_int_distribution` can be
instantiated with `__int128_t` but will silently produce incorrect results
(only the lowest 64 bits can ever be set). libstdc++ also supports `__int128_t`
as a result type, so I have simply extended the maximum width of the
internal intermediate result type.
[1]: https://github.com/llvm/llvm-project/blob/6d28dffb6/libcxx/include/__random/uniform_int_distribution.h#L266-L267
Differential Revision: https://reviews.llvm.org/D114129
We only support Clangs that implement nullptr as an extension in C++03 mode,
and we don't support GCC in C++03 mode. Hence, this patch disables the
use of the std::nullptr_t emulation in C++03 mode by default. Doing that
is technically an ABI break since it changes the mangling for std::nullptr_t.
However:
(1) The only affected users are those compiling in C++03 mode that have
std::nullptr_t as part of their ABI, which should be reasonably rare.
(2) Those users already have a lingering problem in that their code will
be incompatible in C++03 and C++11 modes because of that very ABI break.
Hence, the only users that could really be inconvenienced about this
change is those that planned on compiling in C++03 mode forever - for
other users, we're just breaking them now instead of letting them break
themselves later on when they try to upgrade to C++11.
(3) The ABI break will cause a linker error since the mangling changed,
and will not result in an obscure runtime error.
Furthermore, if anyone is broken by this, they can define the
_LIBCPP_ABI_USE_CXX03_NULLPTR_EMULATION macro to return to the
previous behavior. We will then remove that macro after shipping
this for one release if we haven't seen widespread issues.
Concretely, the motivation for making this change is to make our own ABI
consistent in C++03 and C++11 modes and to remove complexity around the
definition of nullptr.
Furthermore, we could investigate making nullptr a keyword in C++03 mode
as a Clang extension -- I don't think that would break anyone, since
libc++ already defines nullptr as a macro to something else. Only users
that do not use libc++ and compile in C++03 mode could potentially be
broken by that.
Differential Revision: https://reviews.llvm.org/D109459
I encountered this while reviewing an unrelated patch. Will land after
the CI passes.
Reviewed By: #libc, Mordante
Differential Revision: https://reviews.llvm.org/D114673
-Wformat-nonliteral was turned on in https://reviews.llvm.org/D112927,
however we forgot to apply some __format__ attributes in Linux specific
code paths, which led to warnings when building on Linux. This patch
addresses that oversight.
Differential Revision: https://reviews.llvm.org/D113876
This patch implements operator<=> for std::reverse_iterator and
also adds a test that checks that three-way comparison of different
instantiations of std::reverse_iterator works as expected (related to
D113417).
Reviewed By: ldionne, Quuxplusone, #libc
Differential Revision: https://reviews.llvm.org/D113695
Rework `std::filesystem::path::operator==` and friends to avoid overload
resolution and atomic constraint caching issues shown from
https://reviews.llvm.org/D113161.
Always call `__compare(string_view)` from the comparison operators which avoids
overload resolution.
Differential Revision: https://reviews.llvm.org/D114570
The `string_view` constructor taking an iterator/sentinel uses concepts
instead of type traits like the Standard states. Using `same_as` instead
of `is_same_v` should be harmless. Prefer `std::is_same_v` instead which is
cheaper to compile. Replace `convertible_to` with `is_convertible_v` as
well.
This observation came up while working on
https://reviews.llvm.org/D113161
Differential Revision: https://reviews.llvm.org/D114561
According to the C++ standard, the stored pointer and the stored deleter
should be value-initialized.
Differential Revision: https://reviews.llvm.org/D113612
In 1fa27f2a10, we made <filesystem>'s iterator types model concepts
from <ranges>, but we forgot to add the appropriate availability
annotations. This broke back-deployment to platforms that don't have
<filesystem> for which we have availability annotations.
For some reason, this wasn't caught by our back-deployment CI.
I believe this is due to the fact that we use a slightly older
compiler in the CI, and perhaps that compiler does not honour
our `#pragma clang attribute push` properly.
Differential Revision: https://reviews.llvm.org/D114456
This does not include `std::compare_*_fallback`; those are coming later.
There's still an open question of how to implement std::strong_order
for `long double`, which has 80 value bits and 48 padding bits on x86-64,
and which is presumably *not* IEEE 754-compliant on PPC64 and so on.
So that part is left unimplemented.
Differential Revision: https://reviews.llvm.org/D110738
Actually there's one functional change here, which is that users can
no longer depend on <random> to include all of C++20 <concepts>. That
inclusion is so new that we believe nobody should be depending on it
yet, even in the presence of Hyrum's Law. We keep the includes of <vector>,
<algorithm>, etc., so as not to break pre-C++20 Hyrum's Law users.
Differential Revision: https://reviews.llvm.org/D114281
This is not mandated by the standard, so it goes in libcxx/test/libcxx/.
It's certainly arguable that the algorithms changed here
(`is_heap`, `is_sorted`, `min`, `max`) are harmless and we should
just let them copy their comparators once. But at the same time,
it's nice to have all our algorithms be 100% consistent and never
copy a comparator, not even once.
Differential Revision: https://reviews.llvm.org/D114136
We would have been defining it in <utility> instead of <charconv>. For
the time being, this doesn't change anything since we don't implement
the feature test macro anyways.
Also, as a fly-by, this removes obsolete feature test macro tests. There
was a brief time back in the days when we wrote feature test macro tests
manually. In particular, we had test files for __cpp_lib_to_chars and
__cpp_lib_memory_resource. Since we now have a principled way of generating
these tests with scripts, this commit removes the obsolete (and empty)
tests for these two feature test macros.
Differential Revision: https://reviews.llvm.org/D114243
std::atomic is, for the most part, just a thin veneer on top of compiler
builtins. Hence, it should be available even when threads are not available
on the system, and in fact there has been requests for such support.
This patch:
- Moves __libcpp_thread_poll_with_backoff to its own header so it can
be used in <atomic> when threads are disabled.
- Adds a dummy backoff policy for atomic polling that doesn't know about
threads.
- Adjusts the <atomic> feature-test macros so they are provided even when
threads are disabled.
- Runs the <atomic> tests when threads are disabled.
rdar://77873569
Differential Revision: https://reviews.llvm.org/D114109
We've stopped doing it in libc++ for a while now because these names
would end up rotting as we move things around and copy/paste stuff.
This cleans up all the existing files so as to stop the spreading
as people copy-paste headers around.
- Replace irrelevant synopsis by a comment
- Use a .verify.cpp test instead of .compile.fail.cpp
- Remove unnecessary includes in one of the tests (was a copy-paste error)
Differential Revision: https://reviews.llvm.org/D114094
This effort is dedicated to deflake the tests of the users which depend
on the unspecified behavior of algorithms and containers. This also
might help updating the sorting algorithm in libcxx which has the
quadratic worst case in the future or at least create a new one under
flag.
For detailed design, please see the design doc I provide in the patch.
Differential Revision: https://reviews.llvm.org/D96946
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
The return type of the deleted functions doesn't match the synopsis in
the standard.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D114000
Places `format_to_n_result` to its own file. While working on D112361 it
turns out the type will be used outside the format header.
Reviewed By: #libc, Quuxplusone, Mordante
Differential Revision: https://reviews.llvm.org/D113831
This patch fixes the warnings which shows up when libcxx library started to be compiled in 32-bit mode on z/OS.
More specifically, the assignment from unsigned int to time_t aka long was flags as follows:
```
libcxx/include/c++/v1/__support/ibm/nanosleep.h:31:11: warning: implicit conversion changes signedness: 'unsigned int' to 'time_t' (aka 'long') [-Wsign-conversion]
__sec = sleep(static_cast<unsigned int>(__sec));
~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
libcxx/include/c++/v1/__support/ibm/nanosleep.h:36:36: warning: implicit conversion changes signedness: 'unsigned int' to 'long' [-Wsign-conversion]
__rem->tv_nsec = __micro_sec * 1000;
~ ~~~~~~~~~~~~^~~~~~
libcxx/include/c++/v1/__support/ibm/nanosleep.h:47:36: warning: implicit conversion changes signedness: 'unsigned int' to 'long' [-Wsign-conversion]
__rem->tv_nsec = __micro_sec * 1000;
~ ~~~~~~~~~~~~^~~~~~
3 warnings generated.
```
Here is a small test case illustrating the issue:
```
typedef long time_t ;
unsigned int sleep(unsigned int );
int main() {
time_t sec = 0;
#ifdef FIX
sec = static_cast<time_t>(sleep(static_cast<unsigned int>(sec)));
#else
sec = sleep(static_cast<unsigned int>(sec));
#endif
}
```
clang++ -c -Wsign-conversion -m32 t.C
```
t.C:8:9: warning: implicit conversion changes signedness: 'unsigned int' to 'time_t' (aka 'long') [-Wsign-conversion]
sec = sleep(static_cast<unsigned int>(sec));
~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Reviewed By: ldionne, #libc, Quuxplusone, Mordante
Differential Revision: https://reviews.llvm.org/D112837
Since coroutine is merged in C++ standard and the support for coroutine
seems relatively stable. It's the time to move the implementation of
coroutine out of the experimental directory and the std::experimental
namespace. This patch creates header <coroutine> with conformed
implementation with C++ standard. To avoid breaking user's code too
fast, the <experimental/coroutine> header is remained. Note that
<experimental/coroutine> is deprecated and it would be removed in
LLVM15.
Reviewed By: Quuxplusone, ldionne
Differential Revision: https://reviews.llvm.org/D109433
The template std::is_assignable<T, U> checks that T is assignable from
U. Hence, the order of operands in the instantiation of
std::is_assignable in the std::reverse_iterator::operator= condition
should be reversed.
This issue remained unnoticed because std::reverse_iterator has an
implicit conversion constructor. This patch adds a test to check that
the assignment operator is used directly, without any implicit
conversions. The patch also adds a similar test for
std::move_iterator.
Reviewed By: Quuxplusone, ldionne, #libc
Differential Revision: https://reviews.llvm.org/D113417
Right now we drop the char_traits template argument, which presumes that
string<_CharT, _Traits> and string<_CharT> are interchangeable.
Reviewed By: Mordante, #libc, Quuxplusone
Differential Revision: https://reviews.llvm.org/D112017
This addresses the usage of `operator&` in `<list>`.
(Note there are still more headers with the same issue.)
Reviewed By: #libc, Quuxplusone, ldionne
Differential Revision: https://reviews.llvm.org/D112654
Arthur O'Dwyer