aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/Frontend/CompilerInvocation.cpp
diff options
context:
space:
mode:
authorLouis Dionne <ldionne@apple.com>2018-07-31 11:56:20 -0400
committerLouis Dionne <ldionne.2@gmail.com>2021-02-22 14:52:18 -0500
commita0839b14df6de99fe29bee7cdfff182d50de665d (patch)
tree62981fc220b5fcd6a0c461a00c249037c549a819 /clang/lib/Frontend/CompilerInvocation.cpp
parent946a09945f02427c7b2075ae72ea4d77bb1a2a1d (diff)
downloadllvm-a0839b14df6de99fe29bee7cdfff182d50de665d.zip
llvm-a0839b14df6de99fe29bee7cdfff182d50de665d.tar.gz
llvm-a0839b14df6de99fe29bee7cdfff182d50de665d.tar.bz2
[libc++] Fix tuple assignment from types derived from a tuple-like
The implementation of tuple's constructors and assignment operators currently diverges from the way the Standard specifies them, which leads to subtle cases where the behavior is not as specified. In particular, a class derived from a tuple-like type (e.g. pair) can't be assigned to a tuple with corresponding members, when it should. This commit re-implements the assignment operators (BUT NOT THE CONSTRUCTORS) in a way much closer to the specification to get rid of this bug. Most of the tests have been stolen from Eric's patch https://reviews.llvm.org/D27606. As a fly-by improvement, tests for noexcept correctness have been added to all overloads of operator=. We should tackle the same issue for the tuple constructors in a future patch - I'm just trying to make progress on fixing this long-standing bug. PR17550 rdar://15837420 Differential Revision: https://reviews.llvm.org/D50106
Diffstat (limited to 'clang/lib/Frontend/CompilerInvocation.cpp')
0 files changed, 0 insertions, 0 deletions