This paper was accepted during the last plenary and is intended to be
backported to LLVM 15. When backporting the release notes in the branch
should be updated too.
Note the feature-test macro isn't updated since this will change; three
papers have updated the same macro in the same plenary.
Implements:
- P2508R1 Exposing std::basic-format-string
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D130643
I went over the output of the following mess of a command:
`(ulimit -m 2000000; ulimit -v 2000000; git ls-files -z | parallel --xargs -0 cat | aspell list --mode=none --ignore-case | grep -E '^[A-Za-z][a-z]*$' | sort | uniq -c | sort -n | grep -vE '.{25}' | aspell pipe -W3 | grep : | cut -d' ' -f2 | less)`
and proceeded to spend a few days looking at it to find probable typos
and fixed a few hundred of them in all of the llvm project (note, the
ones I found are not anywhere near all of them, but it seems like a
good start).
Reviewed By: #libc, philnik
Spies: philnik, libcxx-commits, mgorny, arichardson
Differential Revision: https://reviews.llvm.org/D130905
This patch rewords the static assert diagnostic output. Failing a
_Static_assert in C should not report that static_assert failed. This
changes the wording to be more like GCC and uses "static assertion"
when possible instead of hard coding the name. This also changes some
instances of 'static_assert' to instead be based on the token in the
source code.
Differential Revision: https://reviews.llvm.org/D129048
Looks like we again are going to have problems with libcxx tests that
are overly specific in their dependency on clang's diagnostics.
This reverts commit 6542cb55a3.
This patch is basically the rewording of the static assert statement's
output(error) on screen after failing. Failing a _Static_assert in C
should not report that static_assert failed. It’d probably be better to
reword the diagnostic to be more like GCC and say “static assertion”
failed in both C and C++.
consider a c file having code
_Static_assert(0, "oh no!");
In clang the output is like:
<source>:1:1: error: static_assert failed: oh no!
_Static_assert(0, "oh no!");
^ ~
1 error generated.
Compiler returned: 1
Thus here the "static_assert" is not much good, it will be better to
reword it to the "static assertion failed" to more generic. as the gcc
prints as:
<source>:1:1: error: static assertion failed: "oh no!"
1 | _Static_assert(0, "oh no!");
| ^~~~~~~~~~~~~~
Compiler returned: 1
The above can also be seen here. This patch is about rewording
the static_assert to static assertion.
Differential Revision: https://reviews.llvm.org/D129048
This implements the Grapheme clustering as required by
P1868R2 width: clarifying units of width and precision in std::format
This was omitted in the initial patch, but the paper was marked as completed. This really completes the paper.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D126971
This implements a not accepted LWG issue. Not doing so would require
integral types to use the handle class instead of being directly stored
in the basic_format_arg.
The previous code used `std::forward` in places where it wasn't required
by the Standard. These are now removed.
Implements:
- P2418R2 Add support for std::generator-like types to std::format
- LWG 3631 basic_format_arg(T&&) should use remove_cvref_t<T> throughout
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D127570
With to_chars supporting 128-bit it's possible to support the full
128-bit range in format. This only removes the previous restrictions
and updates the tests to validate proper support.
Depends on D128929.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D129007
This is required by the Standard and makes it possible to add full
128-bit support to format.
The patch also fixes 128-bit from_chars "support". One unit test
required a too large value, this failed on 128-bit; the fix was to add
more characters to the input.
Note only base 10 has been optimized. Other bases can be optimized.
Note the 128-bit lookup table could be made smaller. This will be done later. I
really want to get 128-bit working in to_chars and format in the upcomming
LLVM 15 release, these optimizations aren't critical.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D128929
Display 'static_assert failed: message' instead of
'static_assert failed "message"' to be consistent
with other implementations and be slightly more
readable.
Reviewed By: #libc, aaron.ballman, philnik, Mordante
Differential Revision: https://reviews.llvm.org/D128844
Otherwise, this breaks freestanding builds, where `main()` isn't mangled
specially and we need to assume that we have a `int main(int, char**)`
entry point in each test for things to work.
- P1252 ("Ranges Design Cleanup") -- deprecate
`move_iterator::operator->` starting from C++20; add range comparisons
to the `<functional>` synopsis. This restores
`move_iterator::operator->` that was incorrectly deleted in D117656;
it's still defined in the latest draft, see
http://eel.is/c++draft/depr.move.iter.elem. Note that changes to
`*_result` types from 6.1 in the paper are no longer relevant now that
these types are aliases;
- P2106 ("Alternative wording for GB315 and GB316") -- add a few
`*_result` types to the synopsis in `<algorithm>` (some algorithms are
not implemented yet and thus some of the proposal still cannot be
marked as done);
Also mark already done issues as done (or as nothing to do):
- P2091 ("Fixing Issues With Range Access CPOs") was already implemented
(this patch adds tests for some ill-formed cases);
- LWG 3247 ("`ranges::iter_move` should perform ADL-only lookup of
`iter_move`") was already implemented;
- LWG 3300 ("Non-array ssize overload is underconstrained") doesn't
affect the implementation;
- LWG 3335 ("Resolve C++20 NB comments US 273 and GB 274") was already
implemented;
- LWG 3355 ("The memory algorithms should support move-only input
iterators introduced by P1207") was already implemented (except for
testing).
Differential Revision: https://reviews.llvm.org/D126053
1. for constructors that takes cvref variation of tuple<UTypes...>, there
used to be two SFINAE helper _EnableCopyFromOtherTuple,
_EnableMoveFromOtherTuple. And the implementations of these two helpers
seem to slightly differ from the spec. But now, we need 4 variations.
Instead of adding another two, this change refactored it to a single one
_EnableCtrFromUTypesTuple, which directly maps to the spec without
changing the C++11 behaviour. However, we need the helper __copy_cvref_t
to get the type of std::get<i>(cvref tuple<Utypes...>) for different
cvref, so I made __copy_cvref_t to be available in C++11.
2. for constructors that takes variations of std::pair, there used to be
four helpers _EnableExplicitCopyFromPair, _EnableImplicitCopyFromPair,
_EnableImplicitMoveFromPair, _EnableExplicitMoveFromPair. Instead of
adding another four, this change refactored into two helper
_EnableCtrFromPair and _BothImplicitlyConvertible. This also removes the
need to use _nat
3. for const member assignment operator, since the requirement is very
simple, I haven't refactored the old code but instead directly adding
the new c++23 code.
4. for const swap, I pretty much copy pasted the non-const version to make
these overloads look consistent
5. while doing these change, I found two of the old constructors wasn't
marked constexpr for C++20 but they should. fixed them and added unit
tests
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D116621
When merging the changes of <type_traits> header with the commits on
this header over the last month, several conflicts were mistaken
resolved and the wrong branch was picked while resolving conflicts,
which leads to CI failure. In order to resolve the conflicts properly
with qualification CI job, this change is reverted.
This reverts commit 95733a55b9.
1. for constructors that takes cvref variation of tuple<UTypes...>, there
used to be two SFINAE helper _EnableCopyFromOtherTuple,
_EnableMoveFromOtherTuple. And the implementations of these two helpers
seem to slightly differ from the spec. But now, we need 4 variations.
Instead of adding another two, this change refactored it to a single one
_EnableCtrFromUTypesTuple, which directly maps to the spec without
changing the C++11 behaviour. However, we need the helper __copy_cvref_t
to get the type of std::get<i>(cvref tuple<Utypes...>) for different
cvref, so I made __copy_cvref_t to be available in C++11.
2. for constructors that takes variations of std::pair, there used to be
four helpers _EnableExplicitCopyFromPair, _EnableImplicitCopyFromPair,
_EnableImplicitMoveFromPair, _EnableExplicitMoveFromPair. Instead of
adding another four, this change refactored into two helper
_EnableCtrFromPair and _BothImplicitlyConvertible. This also removes the
need to use _nat
3. for const member assignment operator, since the requirement is very
simple, I haven't refactored the old code but instead directly adding
the new c++23 code.
4. for const swap, I pretty much copy pasted the non-const version to make
these overloads look consistent
5. while doing these change, I found two of the old constructors wasn't
marked constexpr for C++20 but they should. fixed them and added unit
tests
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D116621
`std::function` has been deprecated for a few releases now. Remove it with an option to opt-back-in with a note that this option will be removed in LLVM 16.
Reviewed By: ldionne, #libc
Spies: #libc_vendors, EricWF, jloser, libcxx-commits
Differential Revision: https://reviews.llvm.org/D127908
A formatter using a handle only needs to satisfy the BasicFormatter
requirements. The current test allowed more than that minimum. Changed
it to the minimum to make sure it works.
This was due to a post-commit review comment of @vitaut in D121530.
Reviewed By: ldionne, vitaut, #libc
Differential Revision: https://reviews.llvm.org/D127767
This mostly copys the `<experimental/functional>` stuff and updates the code to current libc++ style.
Reviewed By: ldionne, #libc
Spies: nlopes, adamdebreceni, arichardson, libcxx-commits, mgorny
Differential Revision: https://reviews.llvm.org/D121074
This removes all "TODO: remove these headers" comments from our headers.
Note there seem to be more headers that can be removed, that will be
done in separate commits.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D127592
The compilers clang-11, clang-12, and apple-clang-12 are no longer
supported, so remove their annotations in the tests.
Reviewed By: #libc, philnik
Differential Revision: https://reviews.llvm.org/D127588
There is only compile-time tests in `dtor.pass.cpp`, so it could be made a
`dtor.compile.pass.cpp`. Instead, add a runtime test for testing the trivial
destructor behavior for `tuple`.
Differential Revision: https://reviews.llvm.org/D109298
The debug mode has been broken pretty much ever since it was shipped
because it was possible to enable the debug mode in user code without
actually enabling it in the dylib, leading to ODR violations that
caused various kinds of failures.
This commit makes the debug mode a knob that is configured when
building the library and which can't be changed afterwards. This is
less flexible for users, however it will actually work as intended
and it will allow us, in the future, to add various kinds of checks
that do not assume the same ABI as the normal library. Furthermore,
this will make the debug mode more robust, which means that vendors
might be more tempted to support it properly, which hasn't been the
case with the current debug mode.
This patch shouldn't break any user code, except folks who are building
against a library that doesn't have the debug mode enabled and who try
to enable the debug mode in their code. Such users will get a compile-time
error explaining that this configuration isn't supported anymore.
In the future, we should further increase the granularity of the debug
mode checks so that we can cherry-pick which checks to enable, like we
do for unspecified behavior randomization.
Differential Revision: https://reviews.llvm.org/D122941
After moving the std::to_chars base 10 implementation from the dylib to
the header the integral overloads of std::to_chars are available on all
platforms.
Remove the _LIBCPP_AVAILABILITY_TO_CHARS availability macro and update
the tests.
Depends on D125704
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D125745
Formatting a string-literal had an off-by-one issue where the NUL
terminator became part of the formatted output.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D126665
Clang 3.7 and below is not actively used or supported in the test suite now, so
remove the workaround in the test.
Differential Revision: https://reviews.llvm.org/D126603
Since those features are general properties of the environment, it makes
sense to use them from libc++abi too, and so the name libcpp-has-no-xxx
doesn't make sense.
Differential Revision: https://reviews.llvm.org/D126482
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
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
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
This test only fails on x86_64 clang-cl, not for i386.
(The root cause is still not explored, thus the FIXME is still
relevant.)
Differential Revision: https://reviews.llvm.org/D124994
The GCC failures were partly fixed in D124103.
The format functions tests are fixed on GCC but they require a huge
amount of RAM (>10 GB). This fails with parallel testing in the CI. It
can be solved by splitting the test, but GCC-12 will be released shortly
and might fix the memory usage in these tests. Therefore these tests
remain disabled.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D124335
This is extended to all `std::` functions that take a reference to a
value and return a reference (or pointer) to that same value: `move`,
`forward`, `move_if_noexcept`, `as_const`, `addressof`, and the
libstdc++-specific function `__addressof`.
We still require these functions to be declared before they can be used,
but don't instantiate their definitions unless their addresses are
taken. Instead, code generation, constant evaluation, and static
analysis are given direct knowledge of their effect.
This change aims to reduce various costs associated with these functions
-- per-instantiation memory costs, compile time and memory costs due to
creating out-of-line copies and inlining them, code size at -O0, and so
on -- so that they are not substantially more expensive than a cast.
Most of these improvements are very small, but I measured a 3% decrease
in -O0 object file size for a simple C++ source file using the standard
library after this change.
We now automatically infer the `const` and `nothrow` attributes on these
now-builtin functions, in particular meaning that we get a warning for
an unused call to one of these functions.
In C++20 onwards, we disallow taking the addresses of these functions,
per the C++20 "addressable function" rule. In earlier language modes, a
compatibility warning is produced but the address can still be taken.
The same infrastructure is extended to the existing MSVC builtin
`__GetExceptionInfo`, which is now only recognized in namespace `std`
like it always should have been.
This is a re-commit of
fc30901096,
a571f82a50,
64c045e25b, and
de6ddaeef3,
and reverts aa643f455a.
This change also includes a workaround for users using libc++ 3.1 and
earlier (!!), as apparently happens on AIX, where std::move sometimes
returns by value.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D123345
Revert "Fixup D123950 to address revert of D123345"
This reverts commit aa643f455a.
Igor Zhukov