Fix condition for std::variant to be copy constructible
authorJonathan Wakely <jwakely@redhat.com>
Wed, 17 Apr 2019 19:27:27 +0000 (20:27 +0100)
committerJonathan Wakely <redi@gcc.gnu.org>
Wed, 17 Apr 2019 19:27:27 +0000 (20:27 +0100)
commit5f00d0d5c2a43a37e505941c16df52ef12179d41
treeb9c620ef77a1d247c02bf749316317648c4f6c99
parent990666d05a36fffbe5414c461025c3c4739333cc
Fix condition for std::variant to be copy constructible

The standard says the std::variant copy constructor is defined as
deleted unless all alternative types are copy constructible, but we were
making it also depend on move constructible. Fix the condition and
enhance the tests to check the semantics with pathological copy-only
types (i.e. supporting copying but having deleted moves).

The enhanced tests revealed a regression in copy assignment for
non-trivial alternative types, where the assignment would not be
performed because the condition in the _Copy_assign_base visitor is
false: is_same_v<remove_reference_t<T&>, remove_reference_t<const T&>>.

* include/std/variant (__detail::__variant::_Traits::_S_copy_assign):
Do not depend on whether all alternative types are move constructible.
(__detail::__variant::_Copy_assign_base::operator=): Remove cv-quals
from the operand when deciding whether to perform the assignment.
* testsuite/20_util/variant/compile.cc (DeletedMoves): Define type
with deleted move constructor and deleted move assignment operator.
(default_ctor, copy_ctor, move_ctor, copy_assign, move_assign): Check
behaviour of variants with DeletedMoves as an alternative.
* testsuite/20_util/variant/run.cc (DeletedMoves): Define same type.
(move_ctor, move_assign): Check that moving a variant with a
DeletedMoves alternative falls back to copying instead of moving.

From-SVN: r270425
libstdc++-v3/ChangeLog
libstdc++-v3/include/std/variant
libstdc++-v3/testsuite/20_util/variant/compile.cc
libstdc++-v3/testsuite/20_util/variant/run.cc