[all-commits] [llvm/llvm-project] 17f2d1: [libc++] Fix QoI bug with construction of std::tup...

[Louis Dionne via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 17f2d1cb9b93d336d4187cd14307bef1ab535808
      https://github.com/llvm/llvm-project/commit/17f2d1cb9b93d336d4187cd14307bef1ab535808
  Author: Louis Dionne <ldionne.2 at gmail.com>
  Date:   2021-05-04 (Tue, 04 May 2021)

  Changed paths:
    M libcxx/include/tuple
    A libcxx/test/std/utilities/tuple/tuple.tuple/tuple.cnstr/cnstr_with_any.compile.pass.cpp

  Log Message:
  -----------
  [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