This patch adds std::extents. extents is one of the core classes used by std::mdspan. It describes a multi-dimensional index space with a mix of compile time and runtime sizes. Furthermore, it is templated on the index type used to describe the multi-dimensional index space.
The class is designed to be highly optimizable in performance critical code sections, and is fully useable in constant expressions contexts.
Testing of this class tends to be somewhat combinatorical, due to the large number of possible corner cases involved in situations where we have both runtime and compile time extents. To add to this, the class is designed to be interoperable (in particular constructible) from arguments which only need to be convertible to the index_type, but are otherwise arbitrary user types. For a larger discussion on the design of this class refer to: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p0009r18.html
Co-authored-by: Damien L-G <dalg24@gmail.com>
Reviewed By: ldionne, #libc
Spies: libcxx-commits, H-G-Hristov, tschuett, philnik, arichardson, Mordante, crtrott
Differential Revision: https://reviews.llvm.org/D148067
- add the `from_range_t` constructors and the related deduction guides;
- add the `insert_range`/`assign_range`/etc. member functions.
(Note: this patch is split from https://reviews.llvm.org/D142335)
Differential Revision: https://reviews.llvm.org/D149826
As obvious from the paper's title this is an LWG issue and thus retroactively
applied to C++20. This change may the output for certain code points:
1 Considers 8477 extra codepoints as having a width 2 (as of Unicode 15)
(mostly Tangut Ideographs)
2 Change the width of 85 unassigned code points from 2 to 1
3 Change the width of 8 codepoints (in the range U+3248 CIRCLED NUMBER
TEN ON BLACK SQUARE ... U+324F CIRCLED NUMBER EIGHTY ON BLACK
SQUARE) from 2 to 1, because it seems questionable to make an exception
for those without input from Unicode
Note that libc++ already uses Unicode 15, while the Standard requires Unicode 12.
(The last time I checked MSVC STL used Unicode 14.)
So in practice the only notable change is item 3.
Implements
P2675 LWG3780: The Paper
format's width estimation is too approximate and not forward compatible
Benchmark before these changes
--------------------------------------------------------------------
Benchmark Time CPU Iterations
--------------------------------------------------------------------
BM_ascii_text<char> 3928 ns 3928 ns 178131
BM_unicode_text<char> 75231 ns 75230 ns 9158
BM_cyrillic_text<char> 59837 ns 59834 ns 11529
BM_japanese_text<char> 39842 ns 39832 ns 17501
BM_emoji_text<char> 3931 ns 3930 ns 177750
BM_ascii_text<wchar_t> 4024 ns 4024 ns 174190
BM_unicode_text<wchar_t> 63756 ns 63751 ns 11136
BM_cyrillic_text<wchar_t> 44639 ns 44638 ns 15597
BM_japanese_text<wchar_t> 34425 ns 34424 ns 20283
BM_emoji_text<wchar_t> 3937 ns 3937 ns 177684
Benchmark after these changes
--------------------------------------------------------------------
Benchmark Time CPU Iterations
--------------------------------------------------------------------
BM_ascii_text<char> 3914 ns 3913 ns 178814
BM_unicode_text<char> 70380 ns 70378 ns 9694
BM_cyrillic_text<char> 51889 ns 51877 ns 13488
BM_japanese_text<char> 41707 ns 41705 ns 16723
BM_emoji_text<char> 3908 ns 3907 ns 177912
BM_ascii_text<wchar_t> 3949 ns 3948 ns 177525
BM_unicode_text<wchar_t> 64591 ns 64587 ns 10649
BM_cyrillic_text<wchar_t> 44089 ns 44078 ns 15721
BM_japanese_text<wchar_t> 39369 ns 39367 ns 17779
BM_emoji_text<wchar_t> 3936 ns 3934 ns 177821
Benchmarks without "if(__code_point < (__entries[0] >> 14))"
--------------------------------------------------------------------
Benchmark Time CPU Iterations
--------------------------------------------------------------------
BM_ascii_text<char> 3922 ns 3922 ns 178587
BM_unicode_text<char> 94474 ns 94474 ns 7351
BM_cyrillic_text<char> 69202 ns 69200 ns 10157
BM_japanese_text<char> 42735 ns 42692 ns 16382
BM_emoji_text<char> 3920 ns 3919 ns 178704
BM_ascii_text<wchar_t> 3951 ns 3950 ns 177224
BM_unicode_text<wchar_t> 81003 ns 80988 ns 8668
BM_cyrillic_text<wchar_t> 57020 ns 57018 ns 12048
BM_japanese_text<wchar_t> 39695 ns 39687 ns 17582
BM_emoji_text<wchar_t> 3977 ns 3976 ns 176479
This optimization does carry its weight for the Unicode and Cyrillic
test. For the Japanese tests the gains are minor and for emoji it seems
to have no effect.
Reviewed By: ldionne, tahonermann, #libc
Differential Revision: https://reviews.llvm.org/D144499
The __cpp_lib_format_ranges feature-test macro only depends on P2286R8
and P2585R0. Note since LWG3750 only affects these two C++23 papers
there is nothing to do for older language versions.
(The __cpp_lib_format feature-test macro depends on the incomplete
formatting for chrono. So this part can't be marked as complete yet.)
This completes
- P2286R8 Formatting ranges
- P2585R0 Improving default container formatting
This partly implements
- LWG3750 Too many papers bump __cpp_lib_format
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D147880
Since stacktrace header is WIP and it's not sure that will be done
before LLVM17 update the documentation. When the header is implemented
implementing the formatter is trivial, so that can be done quickly
afterwards.
Implements parts of:
- P2693R1 Formatting thread::id and stacktrace
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D144331
The paper
- P2286R8 Formatting ranges
is fully implemented modulo its feature test macro. This macro has been
revised by
- LWG3750 Too many papers bump __cpp_lib_format
The new macro depends on
- P2585R0 Improving default container formatting
This paper revises parts of P2286R8 and adds new formatter
specializations. The specialization for debug strings has some wording
issues, which is addresses in this paper
- P2733R0 Fix handling of empty specifiers in std::format
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D142153
There are no tests for the aliases because clang doesn't diagnose deprecated template aliases currently.
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D127678
This is a preparation for the upcoming LLVM 17 release.
Reviewed By: ldionne, philnik, avogelsgesang, jloser, #libc
Differential Revision: https://reviews.llvm.org/D141304
Focus on the not-yet-implemented features: remove most details about the
already-implemented C++20 stuff, list out the major C++23 additions.
Differential Revision: https://reviews.llvm.org/D136657
This doesn't affect our ABI because `std::string::substr()` isn't in the dylib and the mangling of `substr() const` and `substr() const&` are different.
Reviewed By: ldionne, Mordante, var-const, avogelsgesang, #libc
Spies: arphaman, huixie90, libcxx-commits
Differential Revision: https://reviews.llvm.org/D131668
Implements:
- P2291R3 Add Constexpr Modifiers to Functions to_chars and from_chars for
Integral Types in <charconv> Header
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D131317
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
Adds the papers and LWG issues voted in during the July 2022 plenary.
Note the updating of the project based statuses is left to the active
contributors of these projects.
Reviewed By: #libc, huixie90, philnik
Differential Revision: https://reviews.llvm.org/D130595
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
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
Several of our C++20 and C++2b papers were missing the actual revision
number that was voted in to the Standard. The revision number is quite
important because in a few cases, a paper has a revision *after* the
one that is voted into the Standard, which isn't voted into the Standard.
Hence, if we simply followed the wg21.link blindly and implemented that,
we'd end up implementing the latest revision of the paper, which might
not have been voted.
As a fly-by fix, I found out that P1664 had been withdrawn from the
straw polls and had never been voted into the Standard. This commit
removes that entry from our list.
Differential Revision: https://reviews.llvm.org/D112339
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
Implement P2251 which requires `span` and `basic_string_view` to be
trivially copyable. They already are - this just adds tests to bind that
behavior.
Reviewed By: ldionne, Quuxplusone, Mordante, #libc
Differential Revision: https://reviews.llvm.org/D111197
Update the status with the approved papers and LWG-issues in the October 2021 plenary.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D111166
