KKonstantin Varlamov[libc++][ranges] Finish LWG issues directly related to the One Ranges Proposal.
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[libc++][ranges] Finish LWG issues directly related to the One Ranges Proposal. - 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 | 3 年前 | |
[libc++] P2321R2 section [tuple.tuple]. Adding C++23 constructors, assignment operators and swaps to tuple 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 | 3 年前 | |
[libc++][CI] Updates GCC to version 12. Reviewed By: ldionne, philnik, #libc, #libc_abi Differential Revision: https://reviews.llvm.org/D126667 | 3 年前 | |
[libc++] Always enable the ranges concepts The ranges concepts were already available in libc++13, so we shouldn't guard them with _LIBCPP_HAS_NO_INCOMPLETE_RANGES. Fixes https://github.com/llvm/llvm-project/issues/54765 Reviewed By: #libc, ldionne Spies: ldionne, libcxx-commits Differential Revision: https://reviews.llvm.org/D124011 | 4 年前 | |
[libc++] Replace _LIBCPP_HAS_NO_CONCEPTS with _LIBCPP_STD_VER > 17. NFCI. All supported compilers that support C++20 now support concepts. So, remove _LIB_LIBCPP_HAS_NO_CONCEPTS in favor of _LIBCPP_STD_VER > 17. Similarly in the tests, remove // UNSUPPORTED: libcpp-no-concepts. Differential Revision: https://reviews.llvm.org/D121528 | 4 年前 |