This is an archive of the discontinued LLVM Phabricator instance.

Remove __uncvref; use __uncvref_t instead
ClosedPublic

Authored by philnik on Feb 16 2022, 10:26 AM.

Details

Reviewers
Quuxplusone
ldionne
Group Reviewers
Restricted Project
Commits
rGf75580681322: Remove __uncvref; use __uncvref_t instead

Diff Detail

Event Timeline

philnik requested review of this revision.Feb 16 2022, 10:26 AM
philnik created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptFeb 16 2022, 10:26 AM
Herald added a reviewer: Restricted Project. · View Herald Transcript

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.
(Ah, I see you did what I'm asking for on line 361 already, too.)

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.

philnik updated this revision to Diff 409431.Feb 16 2022, 3:13 PM
philnik marked 5 inline comments as done.
  • Address comments
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.

philnik updated this revision to Diff 409737.Feb 17 2022, 11:41 AM
philnik marked an inline comment as done.
  • Refactor test
Quuxplusone accepted this revision.Feb 17 2022, 12:08 PM

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
https://godbolt.org/z/4n9c8cTK7

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.

This revision is now accepted and ready to land.Feb 17 2022, 12:08 PM
This revision was automatically updated to reflect the committed changes.