summaryrefslogtreecommitdiffstats
path: root/llvm/lib/DebugInfo/DWARF/DWARFUnit.cpp
diff options
context:
space:
mode:
authorEric Fiselier <eric@efcs.ca>2016-12-14 22:22:38 +0000
committerEric Fiselier <eric@efcs.ca>2016-12-14 22:22:38 +0000
commitf8136d08c6b1e1d7b922d12b202736f38e21f33c (patch)
tree759c7cce2a61ed6b0535890912b74d76de1b104c /llvm/lib/DebugInfo/DWARF/DWARFUnit.cpp
parentb677fe00fb3d5e9d384ad12030494aa9bf9b3fb7 (diff)
downloadbcm5719-llvm-f8136d08c6b1e1d7b922d12b202736f38e21f33c.tar.gz
bcm5719-llvm-f8136d08c6b1e1d7b922d12b202736f38e21f33c.zip
[libcxx] Fix tuple construction/assignment from types derived from tuple/pair/array.
Summary: The standard requires tuple have the following constructors: ``` tuple(tuple<OtherTypes...> const&); tuple(tuple<OtherTypes...> &&); tuple(pair<T1, T2> const&); tuple(pair<T1, T2> &&); tuple(array<T, N> const&); tuple(array<T, N> &&); ``` However libc++ implements these as a single constructor with the signature: ``` template <class TupleLike, enable_if_t<__is_tuple_like<TupleLike>::value>> tuple(TupleLike&&); ``` This causes the constructor to reject types derived from tuple-like types; Unlike if we had all of the concrete overloads, because they cause the derived->base conversion in the signature. This patch fixes this issue by detecting derived types and the tuple-like base they are derived from. It does this by creating an overloaded function with signatures for each of tuple/pair/array and checking if the possibly derived type can convert to any of them. This patch fixes [PR17550]( https://llvm.org/bugs/show_bug.cgi?id=17550) This patch Reviewers: mclow.lists, K-ballo, mpark, EricWF Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D27606 llvm-svn: 289727
Diffstat (limited to 'llvm/lib/DebugInfo/DWARF/DWARFUnit.cpp')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud