From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 4BEB93860C2D for ; Fri, 12 Jan 2024 21:36:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4BEB93860C2D Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 4BEB93860C2D Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705095374; cv=none; b=J7Txfq58Mb60dVZpjoPjhWuKPiZXChokN0o5i8DwST2tU41U6REHRJoVBRj25qO62sjN68ceufrYKRjFD95CyRkhFs8sUw5/dtxTTeruL6XiNLXvMvfn+ic7KZf1/Hv2DLA5I6CXWxfFoXkW2wopxzlfLIUYVOkRH+kTQocpnZc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705095374; c=relaxed/simple; bh=3pv5c+vE+Vn/pl8VZUsU9rSsN3IYGHjsLPtu1YqwnTs=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=FY7m/htdob/pnuUR+hnvNl7NCXeSjOdxsnMrnp1az1Rgu4F0RbMD7lCzr4/85o4csUcbFhiViYMLhgPFM0hP0dm32fKaxm+V/J4llaD2WQxppNQok8tj+Y6zbUw0WZVCKJ53R3oODBGfswxfSQUHwCdN+6W+RjtrBSFJqz6hix4= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1705095372; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Nj4Uv6KTSfbbrHnYPHfoWhKtvNJOIneKM2x1FPfQgi0=; b=LvA/i4nx5ayIbEr/ffaQc4LOP9GQB7x6UxGU8K1EOxv+1rQTjkBNCGFxdvqIFzgB5KhKOC uOOgdMVdbSipcfqsPtrbKO43psov0967OAEbxe9LwSdLFDXLP6bev2Gi/1C4qcnXqiJssq biyX6oHDBQ36xvYP8898kehOcVcZT/M= Received: from mail-yw1-f199.google.com (mail-yw1-f199.google.com [209.85.128.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-532-aK38hfHZPyqcVpc-5kEWeA-1; Fri, 12 Jan 2024 16:36:10 -0500 X-MC-Unique: aK38hfHZPyqcVpc-5kEWeA-1 Received: by mail-yw1-f199.google.com with SMTP id 00721157ae682-5eba564eb3fso129667157b3.1 for ; Fri, 12 Jan 2024 13:36:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705095369; x=1705700169; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Nj4Uv6KTSfbbrHnYPHfoWhKtvNJOIneKM2x1FPfQgi0=; b=XrXB1UPZoNixwO1LJu/VLmTfukTwXmX7xHpiNYIO+iHvhy0/OQMlZqBxvf+aahdZNb m/6sI7bR+CSgePycYBpu5C/w2slVGv6sQn1ZnHRF98JW9rV1rpb0L2DwFV9i6i4GDybb Iy6Y/ATU9LpLoZ+xSG9R5RLM1rZxLSdtfVddqUkMV8PzCxCeoWczk9cpmrQHK7W+W69r 2SjSizGZisoe3Boebzw438rvOQpTpQh/M650Rte5vbzgZivNP0lYYov+zl/NrY/t8/Ib C6x19GSv90LAdzTGErfCUdesAgr1MjN7IsiZZpKQOrJaCa62DW5ohXEm9zcaUDFgY3wR xdIA== X-Gm-Message-State: AOJu0YwmmuxthgPNynn3HaGlcLa75kY22wP1q8cr+nqcq027sXaQXwdh jN8biBXkOBSqRO+iTgi8/M4FsqH+cAiGNTNEihljE9Emi8wQkrQcw33Fx9GXZ2HsP1XIkAnjXaZ 6gflk9qOWXY3j+H/fks/ByDetPEd+yURp+KarBe4= X-Received: by 2002:a81:b385:0:b0:5fc:112d:a4ad with SMTP id r127-20020a81b385000000b005fc112da4admr1097676ywh.96.1705095369517; Fri, 12 Jan 2024 13:36:09 -0800 (PST) X-Google-Smtp-Source: AGHT+IHmosbe5GAiMDH860UiZafjFRSjMNHBi1p2zSXaBPy7wNk99/c49LQlXRPunVAsNliQIMKu7eyIb4nRHcKa30M= X-Received: by 2002:a81:b385:0:b0:5fc:112d:a4ad with SMTP id r127-20020a81b385000000b005fc112da4admr1097668ywh.96.1705095369237; Fri, 12 Jan 2024 13:36:09 -0800 (PST) MIME-Version: 1.0 References: <20240111221651.585639-1-jwakely@redhat.com> <0794ea99-d839-1bce-17a7-57038ef8c7a3@idea> <6844cd06-3f0c-66f3-a9ab-1ffe1dc674c3@idea> In-Reply-To: <6844cd06-3f0c-66f3-a9ab-1ffe1dc674c3@idea> From: Jonathan Wakely Date: Fri, 12 Jan 2024 21:35:53 +0000 Message-ID: Subject: Re: [PATCH] libstdc++: Implement P2255R2 dangling checks for std::tuple [PR108822] To: Patrick Palka Cc: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org, Ville Voutilainen X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-13.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,KAM_SHORT,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Fri, 12 Jan 2024 at 18:33, Patrick Palka wrote: > > On Fri, 12 Jan 2024, Jonathan Wakely wrote: > > > On Fri, 12 Jan 2024 at 17:55, Patrick Palka wrote: > > > > > > On Thu, 11 Jan 2024, Jonathan Wakely wrote: > > > > > > > I'd like to commit this to trunk for GCC 14. Please take a look. > > > > > > > > -- >8 -- > > > > > > > > This is the last part of PR libstdc++/108822 implementing P2255R2, which > > > > makes it ill-formed to create a std::tuple that would bind a reference > > > > to a temporary. > > > > > > > > The dangling checks are implemented as deleted constructors for C++20 > > > > and higher, and as Debug Mode static assertions in the constructor body > > > > for older standards. This is similar to the r13-6084-g916ce577ad109b > > > > changes for std::pair. > > > > > > > > As part of this change, I've reimplemented most of std::tuple for C++20, > > > > making use of concepts to replace the enable_if constraints, and using > > > > conditional explicit to avoid duplicating most constructors. We could > > > > use conditional explicit for the C++11 implementation too (with pragmas > > > > to disables the -Wc++17-extensions warnings), but that should be done as > > > > a stage 1 change for GCC 15 rather than now. > > > > > > > > The partial specialization for std::tuple is no longer used for > > > > C++20 (or more precisely, for a C++20 compiler that supports concepts > > > > and conditional explicit). The additional constructors and assignment > > > > operators that take std::pair arguments have been added to the C++20 > > > > implementation of the primary template, with sizeof...(_Elements)==2 > > > > constraints. This avoids reimplementing all the other constructors in > > > > the std::tuple partial specialization to use concepts. This way > > > > we avoid four implementations of every constructor and only have three! > > > > (The primary template has an implementation of each constructor for > > > > C++11 and another for C++20, and the tuple specialization has an > > > > implementation of each for C++11, so that's three for each constructor.) > > > > > > > > In order to make the constraints more efficient on the C++20 version of > > > > the default constructor I've also added a variable template for the > > > > __is_implicitly_default_constructible trait, implemented using concepts. > > > > > > > > libstdc++-v3/ChangeLog: > > > > > > > > PR libstdc++/108822 > > > > * include/std/tuple (tuple): Add checks for dangling references. > > > > Reimplement constraints and constant expressions using C++20 > > > > features. > > > > * include/std/type_traits [C++20] > > > > (__is_implicitly_default_constructible_v): Define. > > > > (__is_implicitly_default_constructible): Use variable template. > > > > * testsuite/20_util/tuple/dangling_ref.cc: New test. > > > > --- > > > > libstdc++-v3/include/std/tuple | 1021 ++++++++++++----- > > > > libstdc++-v3/include/std/type_traits | 11 + > > > > .../testsuite/20_util/tuple/dangling_ref.cc | 105 ++ > > > > 3 files changed, 841 insertions(+), 296 deletions(-) > > > > create mode 100644 libstdc++-v3/testsuite/20_util/tuple/dangling_ref.cc > > > > > > > > diff --git a/libstdc++-v3/include/std/tuple b/libstdc++-v3/include/std/tuple > > > > index 50e11843757..cd05b638923 100644 > > > > --- a/libstdc++-v3/include/std/tuple > > > > +++ b/libstdc++-v3/include/std/tuple > > > > @@ -752,11 +752,467 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION > > > > template > > > > class tuple : public _Tuple_impl<0, _Elements...> > > > > { > > > > - typedef _Tuple_impl<0, _Elements...> _Inherited; > > > > + using _Inherited = _Tuple_impl<0, _Elements...>; > > > > > > > > template > > > > using _TCC = _TupleConstraints<_Cond, _Elements...>; > > > > > > I guess this should be moved into the #else branch if it's not used in > > > the new impl. > > > > Ah yes, I left them there until I was sure I wouldn't need them ... > > then didn't move them when I didn't need them. > > > > > > > > > > > > > +#if __cpp_concepts && __cpp_conditional_explicit // >= C++20 > > > > + template > > > > + static consteval bool > > > > + __constructible() > > > > + { > > > > + if constexpr (sizeof...(_UTypes) == sizeof...(_Elements)) > > > > + return (is_constructible_v<_Elements, _UTypes> && ...); > > > > > > IIUC this (and all the other new constraints) won't short-circuit like > > > the old versions do :/ Not sure how much that matters? > > > > Yeah, I thought about that, but we have efficient built-ins for these > > traits now, so I think it's probably OK? > > Performance wise agreed, though I suppose removing the short circuiting > could break existing (though not necessarily valid) code that relied > on it to prevent an ill-formed template instantiation. It seems > the standard https://eel.is/c++draft/tuple uses conjunction_v in some > constraints, and fold-expressions in others, implying short circuiting > in some cases but not others? I don't recall any particular logic to those choices, they might be arbitrary. > > > > > If not we could go back to sharing the _TupleConstraints implementations. > > IMHO I'd be more comfortable with that. >