From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lxmtout2.gsi.de (lxmtout2.gsi.de [140.181.3.112]) by sourceware.org (Postfix) with ESMTPS id F2546385B805; Fri, 28 May 2021 07:42:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org F2546385B805 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gsi.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=M.Kretz@gsi.de Received: from localhost (localhost [127.0.0.1]) by lxmtout2.gsi.de (Postfix) with ESMTP id 82BE82027E52; Fri, 28 May 2021 09:42:14 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at lxmtout2.gsi.de Received: from lxmtout2.gsi.de ([127.0.0.1]) by localhost (lxmtout2.gsi.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ahC6O1bh3K7u; Fri, 28 May 2021 09:42:14 +0200 (CEST) Received: from srvex3.campus.gsi.de (unknown [10.10.4.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by lxmtout2.gsi.de (Postfix) with ESMTPS id 65F95202AD60; Fri, 28 May 2021 09:42:14 +0200 (CEST) Received: from excalibur.localnet (140.181.3.12) by srvex3.campus.gsi.de (10.10.4.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2242.10; Fri, 28 May 2021 09:42:13 +0200 From: Matthias Kretz To: , Jason Merrill CC: Subject: Re: [PATCH] Add gnu::diagnose_as attribute Date: Fri, 28 May 2021 09:42:13 +0200 Message-ID: <14231752.kytX9F1ty5@excalibur> Organization: GSI Helmholtzzentrum =?UTF-8?B?ZsO8cg==?= Schwerionenforschung In-Reply-To: <8cae5816-c00e-e8a6-59a5-9afce06d1fb2@redhat.com> References: <14205410.xuKvIAzr1H@excalibur> <2039917.z2SizfLdUX@excalibur> <8cae5816-c00e-e8a6-59a5-9afce06d1fb2@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Originating-IP: [140.181.3.12] X-ClientProxiedBy: SRVEX2.campus.gsi.de (10.10.4.15) To srvex3.campus.gsi.de (10.10.4.16) X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00, BODY_8BITS, KAM_DMARC_STATUS, SPF_PASS, TXREP, T_SPF_HELO_PERMERROR, URIBL_SBL, URIBL_SBL_A autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2021 07:42:18 -0000 On Friday, 28 May 2021 05:05:52 CEST Jason Merrill wrote: > On 5/27/21 6:07 PM, Matthias Kretz wrote: > > On Thursday, 27 May 2021 23:15:46 CEST Jason Merrill wrote: > >> On 5/27/21 2:54 PM, Matthias Kretz wrote: > >>> namespace Vir { > >>> inline namespace foo { > >>> struct A {}; > >>> } > >>> struct A {}; > >>> } > >>> using Vir::A; > >>>=20 > >>> :7:12: error: reference to 'A' is ambiguous > >>> :3:12: note: candidates are: 'struct Vir::A' > >>> :5:10: note: 'struct Vir::A' > >>=20 > >> That doesn't seem so bad. > >=20 > > As long as you ignore the line numbers, it's a puzzling diagnostic. >=20 > Only briefly puzzling, I think; Vir::A is a valid way of referring to > both types. True. But that's also what lead to the error. GCC easily clears it up=20 nowadays, but wouldn't anymore if inline namespaces were hidden by default. > I'd think you could get the same effect from a hypothetical >=20 > namespace [[gnu::diagnose_as]] stdx =3D std::experimental; >=20 > though we'll need to add support for attributes on namespace aliases to > the grammar. Right, but then two of my design goals can't be met: 1. Diagnostics have an improved signal-to-noise ratio out of the box. 2. We can use replacement names that are not valid identifiers. I don't think libstdc++ would ship with a namespace alias outside of the st= d=20 namespace. So we'd place the "burden" of using diagnose_as correctly on our= =20 users. Also as a user you'd possibly have to repeat the namespace alias in= =20 every source file and/or place it in your applications/libraries namespace. > >> Here it seems like you want to say "use this typedef as the true name = of > >> the type". Is it useful to have to repeat the name? Allowing people = to > >> use names that don't correspond to actual declarations seems unnecessa= ry. > >=20 > > Yes, but you could also use it to apply diagnose_as to a template > > instantiation without introducing a name for users. E.g. > >=20 > > using __only_to_apply_the_attribute [[gnu::diagnose_as("intvector")]] > > =20 > > =3D std::vector; > >=20 > > Now all diagnostics of 'std::vector' would print 'intvector' inste= ad. >=20 > Yes, but why would you want to? Making diagnostics print names that the > user can't use in their own code seems obfuscatory, and requiring users > to write the same names in two places seems like extra work. I can imagine using it to make _Internal __names more readable while at the= =20 same time discouraging users to utter them in their own code. Sorry for the= =20 bad code obfuscation example above. An example for consideration from stdx::simd: namespace std { namespace experimental { namespace parallelism_v2 [[gnu::diagnose_as("stdx")]] { namespace simd_abi [[gnu::diagnose_as("simd_abi")]] { template struct _VecBuiltin; template struct _VecBltnBtmsk; #if x86 using __ignore_me_0 [[gnu::diagnose_as("[SSE]")]] =3D _VecBuiltin<16>; using __ignore_me_1 [[gnu::diagnose_as("[AVX]")]] =3D _VecBuiltin<32>; using __ignore_me_2 [[gnu::diagnose_as("[AVX512]")]] =3D _VecBltnBtmsk<= 64>; #endif }}}} Then diagnostics would print 'stdx::simd' instea= d=20 of 'stdx::simd>'. (Users utter the type = by=20 saying e.g. 'stdx::native_simd', while compiling with AVX512 flags.) > > But in general, I tend to agree, for type aliases there's rarely a case > > where the names wouldn't match. > >=20 > > However, I didn't want to special-case the attribute parameters for type > > aliases (or introduce another attribute just for this case). The attrib= ute > > works consistently and with the same interface independent of where it's > > used. I tried to build a generic, broad feature instead of a narrow > > one-problem solution. >=20 > "Treat this declaration as the name of the type/namespace it refers to > in diagnostics" also seems consistent to me. Sure. In general, I think namespace foo [[gnu::this_is_the_name_I_want]] =3D bar; using foo [[gnu::this_is_the_name_I_want]] =3D bar; is not a terribly bad idea on its own. But it's not the solution for the=20 problems I set out to solve. > Still, perhaps it would be better to store these aliases in a separate ha= sh > table instead of *_ATTRIBUTES. Maybe. For performance reasons or for simplification of the implementation?= =20 What entity could I use for hashing? The identifier alone wouldn't suffice= =20 since different instantiations of the same class template can have differen= t=20 diagnose_as values (e.g. std::string, std::wstring, ...). =2D-=20 =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80 Dr. Matthias Kretz https://mattkretz.github.io GSI Helmholtz Centre for Heavy Ion Research https://gsi.de std::experimental::simd https://github.com/VcDevel/std-simd =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80