[libc++] Fix QoI bug with construction of std::tuple involving std::any
authorLouis Dionne <ldionne.2@gmail.com>
Mon, 3 May 2021 16:21:13 +0000 (12:21 -0400)
committerLouis Dionne <ldionne.2@gmail.com>
Tue, 4 May 2021 20:42:36 +0000 (16:42 -0400)
commit17f2d1cb9b93d336d4187cd14307bef1ab535808
treef950101fc97b6043168d0e34a69ec6f6596274cf
parent7b1e1fccb02af234cca44d84bfb045faef9e21c8
[libc++] Fix QoI bug with construction of std::tuple involving std::any

In std::tuple, we should try to avoid calling std::is_copy_constructible
whenever we can to avoid surprising interactions with (I believe) compiler
builtins. This bug was reported in https://reviews.llvm.org/D96523#2730953.

The issue was that when tuple<_Up...> was the same as tuple<_Tp...>, we
would short-circuit the _Or (because sizeof...(_Tp) != 1) and go evaluate
the following `is_constructible<_Tp, const _Up&>...`. That shouldn't
actually be a problem, but see the analysis in https://reviews.llvm.org/D101770#2736470
for why it is with Clang and GCC.

Instead, after this patch, we check whether the constructed-from tuple
is the same as the current tuple regardless of the number of elements,
since we should always prefer the normal copy constructor in that case
anyway.

Differential Revision: https://reviews.llvm.org/D101770
libcxx/include/tuple
libcxx/test/std/utilities/tuple/tuple.tuple/tuple.cnstr/cnstr_with_any.compile.pass.cpp [new file with mode: 0644]