From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lxmtout1.gsi.de (lxmtout1.gsi.de [140.181.3.111]) by sourceware.org (Postfix) with ESMTPS id 6EF33385380D; Thu, 27 May 2021 22:07:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 6EF33385380D 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 lxmtout1.gsi.de (Postfix) with ESMTP id 326832050D12; Fri, 28 May 2021 00:07:57 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at lxmtout1.gsi.de Received: from lxmtout1.gsi.de ([127.0.0.1]) by localhost (lxmtout1.gsi.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id IioJT0RA7xIT; Fri, 28 May 2021 00:07:57 +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 lxmtout1.gsi.de (Postfix) with ESMTPS id 197CE2050D00; Fri, 28 May 2021 00:07:57 +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 00:07:56 +0200 From: Matthias Kretz To: , Jason Merrill CC: Subject: Re: [PATCH] Add gnu::diagnose_as attribute Date: Fri, 28 May 2021 00:07:56 +0200 Message-ID: <2039917.z2SizfLdUX@excalibur> Organization: GSI Helmholtzzentrum =?UTF-8?B?ZsO8cg==?= Schwerionenforschung In-Reply-To: <512c40d3-b85d-f08e-f4b5-b9e40b2a4a41@redhat.com> References: <14205410.xuKvIAzr1H@excalibur> <3483026.uDumqb6SjM@excalibur> <512c40d3-b85d-f08e-f4b5-b9e40b2a4a41@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: srvex1.Campus.gsi.de (10.10.4.11) To srvex3.campus.gsi.de (10.10.4.16) X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00, BODY_8BITS, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP, 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: Thu, 27 May 2021 22:08:01 -0000 On Thursday, 27 May 2021 23:15:46 CEST Jason Merrill wrote: > On 5/27/21 2:54 PM, Matthias Kretz wrote: > > Also hiding all inline namespace by default might make some error messa= ges > > harder to understand: > >=20 > > 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. As long as you ignore the line numbers, it's a puzzling diagnostic. > > This is from my pending std::string patch: > >=20 > > --- a/libstdc++-v3/include/bits/c++config > > +++ b/libstdc++-v3/include/bits/c++config > > @@ -299,7 +299,8 @@ namespace std > >=20 > > #if _GLIBCXX_USE_CXX11_ABI > > namespace std > > { > >=20 > > - inline namespace __cxx11 __attribute__((__abi_tag__ ("cxx11"))) { } > > + inline namespace __cxx11 > > + __attribute__((__abi_tag__ ("cxx11"), __diagnose_as__("std"))) { } >=20 > This seems to have the same benefits and drawbacks of my inline > namespace suggestion. True for std::string, not true for TS's where the extra '::experimental' st= ill=20 makes finding the relevant information in diagnostics harder than necessary. > And it seems like applying the attribute to a > namespace means that enclosing namespaces are not printed, unlike the > handling for types. Yes, that's also how I documented it. For nested namespaces I wanted to ena= ble=20 the removal of nesting (e.g. from std::experimental::parallelism_v2::simd t= o=20 stdx::simd). However, for types and functions it would be a problem to drop= =20 the enclosing scope, because the scope can be class templates and thus the= =20 diagnose_as attribute would remove all template parms & args. > > - typedef basic_string string; > > + typedef basic_string string > > [[__gnu__::__diagnose_as__("string")]]; > > 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 unnecessary. Yes, but you could also use it to apply diagnose_as to a template=20 instantiation without introducing a name for users. E.g. using __only_to_apply_the_attribute [[gnu::diagnose_as("intvector")]] =3D std::vector; Now all diagnostics of 'std::vector' would print 'intvector' instead. = But=20 in general, I tend to agree, for type aliases there's rarely a case where t= he=20 names wouldn't match. However, I didn't want to special-case the attribute parameters for type=20 aliases (or introduce another attribute just for this case). The attribute= =20 works consistently and with the same interface independent of where it's us= ed.=20 I tried to build a generic, broad feature instead of a narrow one-problem=20 solution. =46WIW, before you suggest to have one attribute for namespaces and one for= type=20 aliases (to cover the std::string case), I have another use case in stdx::s= imd=20 (the spec requires simd_abi::scalar to be an alias): namespace std::experimental::parallelism_v2::simd_abi { struct [[gnu::diagnose_as("scalar")]] _Scalar; using scalar =3D _Scalar; } If the attribute were on the type alias (using scalar [[gnu::diagnose_as]] = =3D=20 _Scalar;), then we'd have to apply the attribute to _Scalar after it was=20 completed. That seemed like a bad idea to me. =20 =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