[v3 PATCH] Make the perfect-forwarding constructor of a two-element tuple sfinae away when the first argument is an allocator_arg.

[v3 PATCH] Make the perfect-forwarding constructor of a two-element tuple sfinae away when the first argument is an allocator_arg.

[Ville Voutilainen]

[-- Attachment #1: Type: text/plain, Size: 675 bytes --]

Andrzej Krzemienski pointed this out in a discussion related to any and tags.
Our two-element tuple specialization doesn't make the perfect-forwarding
constructor and the allocator constructor properly mutually exclusive; this
patch fixes that.

Tested on Linux-x64, ok for trunk, gcc-6 and gcc-5?

2016-12-18  Ville Voutilainen  <ville.voutilainen@gmail.com>

    Make the perfect-forwarding constructor of a two-element tuple
    sfinae away when the first argument is an allocator_arg.
    * include/std/tuple (tuple(_U1&&, _U2&&)): Constrain.
    * testsuite/20_util/tuple/cons/allocator_with_any.cc: New.
    * testsuite/20_util/tuple/element_access/get_neg.cc: Adjust.

[-- Attachment #2: tuple_alloc_any.diff --]
[-- Type: text/plain, Size: 3384 bytes --]

diff --git a/libstdc++-v3/include/std/tuple b/libstdc++-v3/include/std/tuple
index 13e0bf8..9dbdd8d 100644
--- a/libstdc++-v3/include/std/tuple
+++ b/libstdc++-v3/include/std/tuple
@@ -951,7 +951,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
         enable_if<_TMC::template
                     _MoveConstructibleTuple<_U1, _U2>()
                   && _TMC::template
-                    _ImplicitlyMoveConvertibleTuple<_U1, _U2>(),
+                    _ImplicitlyMoveConvertibleTuple<_U1, _U2>()
+	          && !is_same<typename decay<_U1>::type,
+			      allocator_arg_t>::value,
 	bool>::type = true>
         constexpr tuple(_U1&& __a1, _U2&& __a2)
 	: _Inherited(std::forward<_U1>(__a1), std::forward<_U2>(__a2)) { }
@@ -960,7 +962,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
         enable_if<_TMC::template
                     _MoveConstructibleTuple<_U1, _U2>()
                   && !_TMC::template
-                    _ImplicitlyMoveConvertibleTuple<_U1, _U2>(),
+                    _ImplicitlyMoveConvertibleTuple<_U1, _U2>()
+	          && !is_same<typename decay<_U1>::type,
+			      allocator_arg_t>::value,
 	bool>::type = false>
         explicit constexpr tuple(_U1&& __a1, _U2&& __a2)
 	: _Inherited(std::forward<_U1>(__a1), std::forward<_U2>(__a2)) { }
diff --git a/libstdc++-v3/testsuite/20_util/tuple/cons/allocator_with_any.cc b/libstdc++-v3/testsuite/20_util/tuple/cons/allocator_with_any.cc
new file mode 100644
index 0000000..9f86c93
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/tuple/cons/allocator_with_any.cc
@@ -0,0 +1,42 @@
+// { dg-do run { target c++14 } }
+
+// Copyright (C) 2016 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// <http://www.gnu.org/licenses/>.
+
+
+// NOTE: This makes use of the fact that we know how moveable
+// is implemented on tuple.  If the implementation changed
+// this test may begin to fail.
+
+#include <tuple>
+#include <experimental/any>
+#include <testsuite_hooks.h>
+
+using std::experimental::any;
+
+void test01()
+{
+    std::tuple<any, any> t(std::allocator_arg,
+			   std::allocator<any>{});
+    VERIFY(std::get<0>(t).empty());
+    VERIFY(std::get<1>(t).empty());
+}
+
+int main()
+{
+    test01();
+}
diff --git a/libstdc++-v3/testsuite/20_util/tuple/element_access/get_neg.cc b/libstdc++-v3/testsuite/20_util/tuple/element_access/get_neg.cc
index 5bcf576..7da61e5 100644
--- a/libstdc++-v3/testsuite/20_util/tuple/element_access/get_neg.cc
+++ b/libstdc++-v3/testsuite/20_util/tuple/element_access/get_neg.cc
@@ -17,7 +17,7 @@
 
 // { dg-options "-fno-show-column" }
 // { dg-do compile { target c++14 } }
-// { dg-error "in range" "" { target *-*-* } 1280 }
+// { dg-error "in range" "" { target *-*-* } 1284 }
 
 #include <tuple>
 

Re: [v3 PATCH] Make the perfect-forwarding constructor of a two-element tuple sfinae away when the first argument is an allocator_arg.

[Jonathan Wakely]

On 18/12/16 13:33 +0200, Ville Voutilainen wrote:
>Andrzej Krzemienski pointed this out in a discussion related to any and tags.
>Our two-element tuple specialization doesn't make the perfect-forwarding
>constructor and the allocator constructor properly mutually exclusive; this
>patch fixes that.
>
>Tested on Linux-x64, ok for trunk, gcc-6 and gcc-5?

gcc-6-branch is frozen, so not there.

OK for trunk and gcc-5-branch.

Should this be reported as a defect in the standard?

Re: [v3 PATCH] Make the perfect-forwarding constructor of a two-element tuple sfinae away when the first argument is an allocator_arg.

[Ville Voutilainen]

On 19 December 2016 at 12:19, Jonathan Wakely <jwakely@redhat.com> wrote:
> On 18/12/16 13:33 +0200, Ville Voutilainen wrote:
>>
>> Andrzej Krzemienski pointed this out in a discussion related to any and
>> tags.
>> Our two-element tuple specialization doesn't make the perfect-forwarding
>> constructor and the allocator constructor properly mutually exclusive;
>> this
>> patch fixes that.
>>
>> Tested on Linux-x64, ok for trunk, gcc-6 and gcc-5?
>
>
> gcc-6-branch is frozen, so not there.

Not now, but when that branch reopens, presumably then?

> Should this be reported as a defect in the standard?

I don't think so, the standard doesn't specify a two-argument
specialization and the variadic
signature specified doesn't run into this problem. We can certainly
give the other vendors a heads-up
in case their implementations suffer from the same problem but the
standard itself is not defective.

Re: [v3 PATCH] Make the perfect-forwarding constructor of a two-element tuple sfinae away when the first argument is an allocator_arg.

[Jonathan Wakely]

On 19/12/16 14:34 +0200, Ville Voutilainen wrote:
>On 19 December 2016 at 12:19, Jonathan Wakely <jwakely@redhat.com> wrote:
>> On 18/12/16 13:33 +0200, Ville Voutilainen wrote:
>>>
>>> Andrzej Krzemienski pointed this out in a discussion related to any and
>>> tags.
>>> Our two-element tuple specialization doesn't make the perfect-forwarding
>>> constructor and the allocator constructor properly mutually exclusive;
>>> this
>>> patch fixes that.
>>>
>>> Tested on Linux-x64, ok for trunk, gcc-6 and gcc-5?
>>
>>
>> gcc-6-branch is frozen, so not there.
>
>Not now, but when that branch reopens, presumably then?

Yes please, for the 6.4 release.

>> Should this be reported as a defect in the standard?
>
>I don't think so, the standard doesn't specify a two-argument
>specialization and the variadic
>signature specified doesn't run into this problem. We can certainly
>give the other vendors a heads-up
>in case their implementations suffer from the same problem but the
>standard itself is not defective.

Ah of course, the 2-argument specialization is only implied by the
"only if sizeof...(Types) == 2" comments but not actually specified.