From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ua1-x933.google.com (mail-ua1-x933.google.com [IPv6:2607:f8b0:4864:20::933]) by sourceware.org (Postfix) with ESMTPS id 1FDB33858C5F for ; Mon, 27 Mar 2023 20:16:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1FDB33858C5F Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=cs.washington.edu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=cs.washington.edu Received: by mail-ua1-x933.google.com with SMTP id m5so7266586uae.11 for ; Mon, 27 Mar 2023 13:16:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.washington.edu; s=goo201206; t=1679948197; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Dd6qjf+2suUlQdSvX6e3sFH39GmH1zFkmmssbwk81Js=; b=Vx6sHLeSo3txmdi66I1MvovEHTx+9896EfuU3x9s5lgqB4R8n3CbYvyBMoNkR3RJNI 3i9o1T6+i5ukokDVzT6sY9VePMUTR9BAQ4sX//GWeFeV2W/pKCOPdbTBru2mYNxfQUU2 GgkcMgzHe1jMDW+NMq+c9qkLbS8V57UQ8qQNA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679948197; h=content-transfer-encoding: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=Dd6qjf+2suUlQdSvX6e3sFH39GmH1zFkmmssbwk81Js=; b=bOHUOTu6ekLjvq6NRtb6PHRFwg7HNcrN8SaizmeHDSGoinMccNDRLIuNt99xPMKISi WD4QFwZwk68J/ofjZwD1BuLw56piSp8xINiyBfweeJ8Ryh4pQnnheoFl9CtLvUdmzxpe 2Gg+X237PjrLjufTwe99vjUvR44MR3ClVTC43DD6mhcKPCRzvfc4iBl24o+4xYraTGNs mtBBv/RmOMlEycz2Umn4gfzOeoiGs3+STMUTk34cE9goEtBJxVnB0foPZ0z0UE/t3QrP cmXVJTCkJzro9d7t4dg5GTE3zAAXX6l1xk+rCI6A+FEGgYQNSs4HS1o5aAH+Gu609mQs 2vrw== X-Gm-Message-State: AAQBX9e6xCkg+iSfOU+N7hLTNz+/JIqePmboI0I2SSzwURqu8p9afshA zCIiWpjoH7SwmyJnDY3FfjUnkc9d2KcpyNkttLA7OA== X-Google-Smtp-Source: AKy350bkN5iUOATp1K+EKVhk1XyPil5Q6pUkm/AZ+75TP2XYSmzcxJR9HR1H1E9NINChC0K2RLuSpeDPCefl9EXQRbk= X-Received: by 2002:a1f:1dcd:0:b0:43b:30a4:5bc1 with SMTP id d196-20020a1f1dcd000000b0043b30a45bc1mr6272164vkd.2.1679948197387; Mon, 27 Mar 2023 13:16:37 -0700 (PDT) MIME-Version: 1.0 References: <7f83711f-5094-6c6d-822b-966293062afc@inria.fr> In-Reply-To: From: Ken Matsui Date: Mon, 27 Mar 2023 13:16:26 -0700 Message-ID: Subject: Re: [GSoC] Conflicted Built-in Trait Name To: =?UTF-8?Q?Fran=C3=A7ois_Dumont?= Cc: gcc@gcc.gnu.org, libstdc++@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP 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 Mon, Mar 27, 2023 at 10:33 AM Fran=C3=A7ois Dumont wrote: > > > On 26/03/2023 04:01, Ken Matsui via Libstdc++ wrote: > > On Sat, Mar 25, 2023 at 5:38=E2=80=AFAM Marc Glisse wrote: > >> On Sat, 25 Mar 2023, Ken Matsui via Gcc wrote: > >> > >>> Built-in trait naming simply adds two underscores (__) to the origina= l > >>> trait name. However, the same names are already in use for some > >>> built-in traits, such as is_void, is_pointer, and is_signed. > >>> > >>> For example, __is_void is used in the following files: > >>> > >>> * gcc/testsuite/g++.dg/tm/pr46567.C > >> This is a testcase, you can rename __is_void to whatever in there, it > >> doesn't matter. > >> > >>> * libstdc++-v3/include/bits/cpp_type_traits.h > >> This __is_void seems to be used in a single place in > >> include/debug/helper_functions.h, couldn't we tweak that code so __is_= void > >> becomes unused and can be removed? > > That worked. Thank you! > What worked ? If you meant about the code, I sent a patch series, as you can see in the following link. https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614620.html * In the following patch, I replaced __is_void with std::is_void in helper_functions.h. https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614624.html * And then, I deleted __is_void in cpp_type_traits.h. https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614623.html * Also, I replaced __is_void with ____is_void in the testcase. https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614625.html If you meant what tests had been done, I did the following tests because the header is under libstdc++. * make check-gcc-c++ (because the patches involve changes on GCC) * make check-target-libstdc++-v3 > > So, we can remove a code in a header as long as it is not standard and > > is not used elsewhere, can't we? > > You can do anything you like as long as you run the testsuite before > presenting your patch. Here note that you'll need to run: > > make check-debug > > to run tests in _GLIBCXX_DEBUG mode which is making use of the code in > helper_functions.h. > > Clearly this usage of std::__is_void could be replaced with your builtin > by reimplementing _Distance_traits like this: > > template typename =3D typename std::__is_integer<_Iterator>::__type> > struct _Distance_traits > { > private: > typedef > typename std::iterator_traits<_Iterator>::difference_type _ItDiffTyp= e; > > typedef > typename std::conditional<__is_void<_ItDiffType>, > std::ptrdiff_t, _ItDiffType>::type _DiffType; > > public: > typedef std::pair<_DiffType, _Distance_precision> __type; > }; > > this is untested, just to give you an idea of what your patch could be. > > Fran=C3=A7ois Thank you! I thought the tests that I did included the hepler_function.h header, but they don=E2=80=99t...? If not, I must check i= f std::is_void in the type_traits header was correctly used.