The __insertion_sort_move helper function is only used in partial_sort.h,
so it makes sense to define it there.
Differential Revision: https://reviews.llvm.org/D147080
AppleClang 1403 has some bugs that prevent std::source_location from
working properly on it. Consequently, we XFAILed the unit test for
source_location with that compiler. However, we should also avoid
advertising that the feature is supported on that compiler, otherwise
our feature-test macros lie. This was noticed to break Boost.Asio
when building with a recent libc++ and AppleClang 14.0.3.
rdar://106863087
Differential Revision: https://reviews.llvm.org/D146837
Building with -DLIBCXX_ENABLE_THREADS=OFF -DLIBCXXABI_ENABLE_THREADS=OFF
(like e.g. for wasm) fails after D146228 because of a misplaced std
namespace begin/end.
Reviewed By: philnik, #libc
Differential Revision: https://reviews.llvm.org/D146682
std::format is currently experimental, so there is technically no
deployment target requirement for it (since the only symbols required
for it are in `libc++experimental.a`).
However, some parts of std::format depend indirectly on the floating
point std::to_chars implementation, which does have deployment target
requirements.
This patch removes all the availability format for std::format and
updates the XFAILs in the tests to properly explain why they fail
on old deployment targets, when they do. It also changes a couple
of tests to avoid depending on floating-point std::to_chars when
it isn't fundamental to the test.
Finally, some tests are marked as XFAIL but I added a comment saying
TODO FMT This test should not require std::to_chars(floating-point)
These tests do not fundamentally depend on floating-point std::to_chars,
however they end up failing because calling std::format even without a
floating-point argument to format will end up requiring floating-point
std::to_chars. I believe this is an implementation artifact that could
be avoided in all cases where we know the format string at compile-time.
In the tests, I added the TODO comment only to the places where we could
do better and actually avoid relying on floating-point std::to_chars
because we know the format string at compile-time.
Differential Revision: https://reviews.llvm.org/D134598
This also updates the moved code to the current style. (i.e. `_VSTD` -> `std`, `_LIBCPP_INLINE_VISIBILITY` -> `_LIBCPP_HIDE_FROM_ABI`, clang-format).
Reviewed By: Mordante, #libc, EricWF
Spies: arichardson, libcxx-commits, mikhail.ramalho
Differential Revision: https://reviews.llvm.org/D146228
Internal linkages fails when building libc++ with modules. Using
internal linkage is headers seems questionable to change the linkage.
Reviewed By: #libc, philnik
Differential Revision: https://reviews.llvm.org/D146384
This allows the compiler to inline the constructors.
Reviewed By: ldionne, #libc
Spies: mikhail.ramalho, libcxx-commits
Differential Revision: https://reviews.llvm.org/D144580
As explained in the release note, libc++ used to provide various
global variables as an extension in C++03 mode. Unfortunately, that
made our definition non-conforming in all standard modes. This was
never a big problem until recently, since we are trying to support
C++20 Modules in libc++, and that requires cleaning up the definition
of these variables.
This change is the first in a series of changes to achieve our end goal.
This patch removes the ability for users to rely on the (incorrect)
definition of those global variables inside the shared library. The
plan is to then remove those definitions from the shared library
(which is an ABI break but I don't think it will have impact), and
finally to make our definition of those variables conforming in all
standard modes.
Differential Revision: https://reviews.llvm.org/D145422
This changes all `__enable_if`s inside `<string>` to a common pattern. Specifically, it's always inside the `template <>` and uses the `, int> = 0` style.
Reviewed By: ldionne, #libc
Spies: mikhail.ramalho, EricWF, libcxx-commits
Differential Revision: https://reviews.llvm.org/D144568
Having the header granularized makes it possible to remove the
dependency on this header in <format>. This <format> header gets
included in more headers due to more usage of std::formatter in the
library. This should reduce the number of transitive includes.
Note formatting the new headers will be done in a followup patch.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D145590
Implements parts of P1614R2: `operator<=>` for `map` and `multimap`
Reviewed By: #libc, philnik
Spies: philnik, libcxx-commits, yaxunl
Differential Revision: https://reviews.llvm.org/D145976
This results in proper error messages instead of just an abort.
Reviewed By: ldionne, Mordante, #libc
Spies: #libc_vendors, smeenai, libcxx-commits
Differential Revision: https://reviews.llvm.org/D141222
While implementing the tests for LWG3720 I noticed the std::format
errors for non-formattable types are not user friendly (and thus hard to
write a .verify test too).
The issue stems from using a deleted function for invalid types. By
using a function that returns an invalid value the diagnostics become a
lot better. Before this change the existing "invalid value"
static_assert could never trigger. Now it can be triggered by user
code, therefore a diagnostic message has been added.
Before this change using a non-formattable type resulted in list of
error messages along the line of
.../include/c++/v1/__format/format_arg_store.h:167:29: error: call to deleted function '__determine_arg_t'
constexpr __arg_t __arg = __determine_arg_t<_Context, remove_cvref_t<_Tp>>();
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.../include/c++/v1/__format/format_arg_store.h:210:54: note: in instantiation of function template specialization 'std::__format::__create_format_arg<std::format_context, char16_t &>' requested here
basic_format_arg<_Context> __arg = __format::__create_format_arg<_Context>(__args);
^
.../include/c++/v1/__format/format_arg_store.h:246:19: note: in instantiation of function template specialization 'std::__format::__create_packed_storage<std::format_context, int &, char16_t &>' requested here
__format::__create_packed_storage(__storage.__types_, __storage.__values_, __args...);
^
.../include/c++/v1/__format/format_functions.h:73:10: note: in instantiation of member function 'std::__format_arg_store<std::format_context, int &, char16_t &>::__format_arg_store' requested here
return _VSTD::__format_arg_store<_Context, _Args...>(__args...);
^
.../include/c++/v1/__config:664:17: note: expanded from macro '_VSTD'
# define _VSTD std
^
.../libcxx/test/std/utilities/format/format.string/format.string.std/lwg3720_arg_id_width_precision_allowed_types.pass.cpp:46:50: note: in instantiation of function template specialization 'std::make_format_args<std::format_context, int &, char16_t &>' requested here
TEST_IGNORE_NODISCARD std::vformat(fmt, std::make_format_args<context_t<CharT>>(args...));
^
.../libcxx/test/std/utilities/format/format.string/format.string.std/lwg3720_arg_id_width_precision_allowed_types.pass.cpp:69:3: note: in instantiation of function template specialization 'test_exception<char, int, char16_t>' requested here
test_exception(SV("{:{}}"), 42, u'0');
^
.../libcxx/test/std/utilities/format/format.string/format.string.std/lwg3720_arg_id_width_precision_allowed_types.pass.cpp:97:3: note: in instantiation of function template specialization 'test<char>' requested here
test<char>();
^
.../include/c++/v1/__format/format_arg_store.h:154:19: note: candidate function [with _Context = std::format_context, _Tp = char16_t] has been explicitly deleted
consteval __arg_t __determine_arg_t()
^
.../include/c++/v1/__format/format_arg_store.h:148:19: note: candidate function [with _Context = std::format_context, _Tp = char16_t]
consteval __arg_t __determine_arg_t() {
<more errors omitted>
.../include/c++/v1/__format/format_arg_store.h:185:22: note: initializer of '__arg' is not a constant expression
.../include/c++/v1/__format/format_arg_store.h:167:21: note: declared here
constexpr __arg_t __arg = __determine_arg_t<_Context, remove_cvref_t<_Tp>>();
^
.../build/include/c++/v1/__format/format_arg_store.h:194:73: error: member reference base type 'char16_t' is not a structure or union
__arg, basic_string_view<typename _Context::char_type>{__value.data(), __value.size()}};
~~~~~~~^~~~~
11 errors generated.
After the change using the same non-formmatable type gives the following
diagnostics
.../include/c++/v1/__format/format_arg_store.h:168:3: error: static assertion failed due to requirement '__arg != __arg_t::__none': the supplied type is not formattable
static_assert(__arg != __arg_t::__none, "the supplied type is not formattable");
^ ~~~~~~~~~~~~~~~~~~~~~~~~
.../include/c++/v1/__format/format_arg_store.h:210:54: note: in instantiation of function template specialization 'std::__format::__create_format_arg<std::format_context, char16_t &>' requested here
basic_format_arg<_Context> __arg = __format::__create_format_arg<_Context>(__args);
^
.../include/c++/v1/__format/format_arg_store.h:246:19: note: in instantiation of function template specialization 'std::__format::__create_packed_storage<std::format_context, int &, char16_t &>' requested here
__format::__create_packed_storage(__storage.__types_, __storage.__values_, __args...);
^
.../include/c++/v1/__format/format_functions.h:73:10: note: in instantiation of member function 'std::__format_arg_store<std::format_context, int &, char16_t &>::__format_arg_store' requested here
return _VSTD::__format_arg_store<_Context, _Args...>(__args...);
^
.../include/c++/v1/__config:664:17: note: expanded from macro '_VSTD'
# define _VSTD std
^
.../libcxx/test/std/utilities/format/format.string/format.string.std/lwg3720_arg_id_width_precision_allowed_types.pass.cpp:46:50: note: in instantiation of function template specialization 'std::make_format_args<std::format_context, int &, char16_t &>' requested here
TEST_IGNORE_NODISCARD std::vformat(fmt, std::make_format_args<context_t<CharT>>(args...));
^
.../libcxx/test/std/utilities/format/format.string/format.string.std/lwg3720_arg_id_width_precision_allowed_types.pass.cpp:69:3: note: in instantiation of function template specialization 'test_exception<char, int, char16_t>' requested here
test_exception(SV("{:{}}"), 42, u'0');
^
.../libcxx/test/std/utilities/format/format.string/format.string.std/lwg3720_arg_id_width_precision_allowed_types.pass.cpp:97:3: note: in instantiation of function template specialization 'test<char>' requested here
test<char>();
^
.../include/c++/v1/__format/format_arg_store.h:168:23: note: expression evaluates to '0 != 0'
static_assert(__arg != __arg_t::__none, "the supplied type is not formattable");
~~~~~~^~~~~~~~~~~~~~~~~~
1 error generated.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D144325
This patch also updates the moved code to the new style (i.e. formatted, replaced marcos and typedefs)
Reviewed By: ldionne, #libc
Spies: arichardson, libcxx-commits
Differential Revision: https://reviews.llvm.org/D145095
Don't forward to `min_element` for small types that are trivially copyable, and instead use a naive loop that keeps track of the smallest element (as opposed to an iterator to the smallest element). This allows the compiler to vectorize the loop in some cases.
Reviewed By: #libc, ldionne
Spies: ldionne, libcxx-commits
Differential Revision: https://reviews.llvm.org/D143596
This one is easy -- Clang supports rvalue references in C++03 mode, so
we should be able to remove that conditional.
As a fly-by fix, turn a few static_casts to std::forward.
Differential Revision: https://reviews.llvm.org/D145701
It was only used in one place, and it seems entirely valid to use
constexpr unconditionally in that location.
Note that a different change was attempted, i.e. using consteval
unconditionally. However, this led to http://llvm.org/PR60709.
Differential Revision: https://reviews.llvm.org/D145700
After commit 0a4aa8a122 we see failures
like:
optional:722:7: error: missing '#include <__type_traits/conjunction.h>';
'_And' must be declared before it is used
and:
optional:683:46: error: missing '#include
<__type_traits/disjunction.h>'; '_Or' must be declared before it is used
using __check_constructible_from_opt = _Or<
Adding these here fixes that.
I'm not familiar with the libcxx codebase, will ask the author to take a
look too.
During the implementation of P2286 a second Unicode decoder was added.
The original decoder was only used for the width estimation. Changing
an ill-formed Unicode sequence to the replacement character, works
properly for this use case. For P2286 an ill-formed Unicode sequence
needs to be formatted as a sequence of code units. The exact wording in
the Standard as a bit unclear and there was odd example in the WP. This
made it hard to use the same decoder. SG16 determined the odd example in
the WP was a bug and this has been fixed in the WP.
This made it possible to combine the two decoders. The P2286 decoder
kept track of the size of the ill-formed sequence. However this was not
needed since the output algorithm needs to keep track of size of a
well-formed and an ill-formed sequence. So this feature has been
removed.
The error status remains since it's needed for P2286, the grapheme
clustering can ignore this unneeded value. (In general, grapheme
clustering is only has specified behaviour for Unicode. When the string
is in a non-Unicode encoding there are no requirements. Ill-formed
Unicode is a non-Unicode encoding. Still libc++ does a best effort
estimation.)
There UTF-8 decoder accepted several ill-formed sequences:
- Values in the surrogate range U+D800..U+DFFF.
- Values encoded in more code units than required, for example 0+0020
in theory can be encoded using 1, 2, 3, or 4 were accepted. This is
not allowed by the Unicode Standard.
- Values larger than U+10FFFF were not always rejected.
Reviewed By: #libc, ldionne, tahonermann, Mordante
Differential Revision: https://reviews.llvm.org/D144346
The AIX linker does not support linking against libc++ if it exports symbols are redefined within compiled code.
Differential Revision: https://reviews.llvm.org/D140675
Clang wants to enable this flag by default, but libc++ isn't working with it yet.
Reviewed By: Mordante, #libc, #libc_abi, EricWF
Spies: libcxx-commits, arichardson
Differential Revision: https://reviews.llvm.org/D144667
This check flags code which uses `_LIBCPP_STD_VER` the wrong way, or tries to use `__cplusplus`. It flags cases where we use `_LIBCPP_STD_VER >` instead of `_LIBCPP_STD_VER >=` and where wrong values are used (e.g. `_LIBCPP_STD_VER >= 24`).
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D144261
LWG3358 §[span.cons] is mistaken that to_address can throw
Since last - first has to throw tests are added to make sure this always
happens.
Depends on D142808
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D142843
LWG3839 range_formatter's set_separator, set_brackets, and
underlying functions should be noexcept
Adds tests for:
template<ranges::input_range R, class charT>
struct range-default-formatter<range_format::sequence, R, charT>
These were missing, the format functions tests for the sequences
are already present.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D144286
Avoids using operator& in basic_string since an evil char-like type can
hijack this operator. Added some more evil operators, this found a place
where equality was compared directly and not via the traits.
This adds a helper test string. This is now only used in a few tests,
but the intention is to use this in more tests for basic_string.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D145257
The m type in a range formatter may only be used when a pair or a tuple
with two elements is used. This was not correctly validated as reported
in llvm.org/PR60995.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D145309
Fixes llvm.org/PR58714 reported by @jwakely and a similar issue
reported privately by @vitaut.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D145306
Formatting a const qualified vector<bool> fails to work on libc++. This
is due to our non-conforming type for vector<bool>::const_reference. The
type is a __bit_const_reference<vector> instead of a bool. (This is
fixed in ABI v2.)
This fixes this formatter and enables the test written for it.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D144279
