Details
- Reviewers
• Quuxplusone ldionne - Group Reviewers
Restricted Project - Commits
- rGf75580681322: Remove __uncvref; use __uncvref_t instead
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Seems fine to me, modulo I expect a bunch of C++03 failures because >>.
libcxx/include/__functional/bind.h | ||
---|---|---|
30 | I suspect here and throughout you'll need > > in place of >>. (Please run the --param std=c++03 tests locally until they pass, since I could envision lots of round-trips to CI here.) | |
libcxx/include/experimental/functional | ||
210–213 | This seems fine; might as well tighten up the ( and ) into ( and ) while you're here. | |
libcxx/include/future | ||
1888 | This could use class = __enable_if_t<!__is_same_uncvref<_Fp, packaged_task>::value>, right? | |
libcxx/include/tuple | ||
1457–1461 | Pre-existing, but as long as you're touching this line, please reformat to match the Pythonesque indentation style of the surrounding code, e.g. using type _LIBCPP_NODEBUG = typename __tuple_cat_type< tuple<_Types...>, typename __make_tuple_types<__uncvref_t<_Tuple0> >::type >::type; | |
libcxx/include/type_traits | ||
1277–1280 | No action required here, but: An interesting followup PR might dig into why __tree uses __unconstref, and whether we can conformingly just use __uncvref instead. |
libcxx/include/future | ||
---|---|---|
1891–1896 | Looks like there's a test that depends on using typename enable_if<...>::type here. Either replace __enable_if_t with enable_if<...>::type, or (AFAIconcerned) just refactor that test libcxx/test/std/thread/futures/futures.task/futures.task.members/ctor2.fail.cpp to be a compile.pass.cpp that simply checks std::is_constructible<std::packaged_task<...>, ...>::value instead of expecting a particular error message from the compiler. |
LGTM mod comments if the CI is green; but please wait for CI to be green, requesting re-review if something new crops up.
libcxx/test/std/thread/futures/futures.task/futures.task.members/ctor2.compile.pass.cpp | ||
---|---|---|
28 | Please expand this test to something like struct A { A(int); }; using PA = std::packaged_task<A(int)>; using PI = std::packaged_task<int(int)>; static_assert(!std::is_constructible<PA, std::allocator_arg_t, std::allocator<A>, const PA&>::value, ""); static_assert(!std::is_constructible<PA, std::allocator_arg_t, std::allocator<A>, const PA&&>::value, ""); static_assert(!std::is_constructible<PA, std::allocator_arg_t, std::allocator<A>, volatile PA&>::value, ""); static_assert(!std::is_constructible<PA, std::allocator_arg_t, std::allocator<A>, volatile PA&&>::value, ""); static_assert( std::is_constructible<PA, std::allocator_arg_t, std::allocator<A>, const PI&>::value, ""); static_assert( std::is_constructible<PA, std::allocator_arg_t, std::allocator<A>, const PI&&>::value, ""); static_assert( std::is_constructible<PA, std::allocator_arg_t, std::allocator<A>, volatile PI&>::value, ""); static_assert( std::is_constructible<PA, std::allocator_arg_t, std::allocator<A>, volatile PI&&>::value, ""); However, cppreference/GCC/MSVC all agree that this ctor was removed entirely in C++17, so we've got a bug here. I've filed it as https://github.com/llvm/llvm-project/issues/53912 — feel free to take a look if it piques your interest. As I said over there, whoever takes it on should dig up the original paper that removed this ctor, because this might be just the tip of the iceberg. |
I suspect here and throughout you'll need > > in place of >>. (Please run the --param std=c++03 tests locally until they pass, since I could envision lots of round-trips to CI here.)