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 [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id E76DA386EC57 for ; Fri, 28 May 2021 03:05:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E76DA386EC57 Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-207-fNyFsaiwNPW8Id9hsTQlVw-1; Thu, 27 May 2021 23:05:56 -0400 X-MC-Unique: fNyFsaiwNPW8Id9hsTQlVw-1 Received: by mail-qv1-f71.google.com with SMTP id k12-20020a0cfd6c0000b029020df9543019so1661089qvs.14 for ; Thu, 27 May 2021 20:05:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=xpNnGXftQZ9tkFd1Ayq/0j1ZwKDpGYZlA0tLPPsU/4Q=; b=OmtPKj0oukfZmn8oSp4lrlm309DXAfQ43IEqf1fwOWkmUTNMGP192Jz61ylLl6D9j4 AS0+FY0GlfGm8oEcYTZG9OVnOsoQmBo8/1iuyVNvWEFQKySPjWBrDBglEHbw/lTuWjUB STMnKiHp+K+bU+RHaVr0uS3LtiiiiR7c78WkTnPe6pzre6mYVKJX4GHLdHw/kaz1b4mB g7WyL1X274rYSTpdnsRTtKhgMEyo8S07CYYqkhKuYytR6cflm+eJSmxjW+R5zgS1q29g Vm4AsXZb77w53oCTc+LAn0FmdAol14CMtMlUq3KusbpQVHredd2PqvMKSakVzcM7iSnS 2zkg== X-Gm-Message-State: AOAM532+D6V1apXsYlrFBpT5S6mVB/Qw/ipFCgtm0CIiWbwsW+U2PbYj FE+cf/afE+wXtrRUAbFmTEfGte2zEX5KqFIXF7YtRTtPXsoSEaDatYW60s6EzFmacFSy9Ofgx9J lZBCAxG9q45UrA7sZk0sI6CCphl2PD0rOFEVqYd0gdL9frAlef2zowb2gFJpLitA= X-Received: by 2002:ac8:5197:: with SMTP id c23mr1564820qtn.292.1622171155168; Thu, 27 May 2021 20:05:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwlYApu3QKV+1n1fSyJhplw2d/J8gYpU/F6pQ99P3lFChJ1Xn6PrxKToon1zf4iBaT9q5YZdA== X-Received: by 2002:ac8:5197:: with SMTP id c23mr1564801qtn.292.1622171154799; Thu, 27 May 2021 20:05:54 -0700 (PDT) Received: from [192.168.1.148] ([130.44.159.43]) by smtp.gmail.com with ESMTPSA id u2sm2680304qkk.75.2021.05.27.20.05.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 27 May 2021 20:05:53 -0700 (PDT) Subject: Re: [PATCH] Add gnu::diagnose_as attribute To: Matthias Kretz , gcc-patches@gcc.gnu.org Cc: libstdc++@gcc.gnu.org References: <14205410.xuKvIAzr1H@excalibur> <3483026.uDumqb6SjM@excalibur> <512c40d3-b85d-f08e-f4b5-b9e40b2a4a41@redhat.com> <2039917.z2SizfLdUX@excalibur> From: Jason Merrill Message-ID: <8cae5816-c00e-e8a6-59a5-9afce06d1fb2@redhat.com> Date: Thu, 27 May 2021 23:05:52 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: <2039917.z2SizfLdUX@excalibur> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libstdc++@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libstdc++ mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2021 03:05:59 -0000 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: >>> Also hiding all inline namespace by default might make some error messages >>> harder to understand: >>> >>> namespace Vir { >>> inline namespace foo { >>> struct A {}; >>> } >>> struct A {}; >>> } >>> using Vir::A; >>> >>> :7:12: error: reference to 'A' is ambiguous >>> :3:12: note: candidates are: 'struct Vir::A' >>> :5:10: note: 'struct Vir::A' >> >> That doesn't seem so bad. > > As long as you ignore the line numbers, it's a puzzling diagnostic. Only briefly puzzling, I think; Vir::A is a valid way of referring to both types. >>> This is from my pending std::string patch: >>> >>> --- a/libstdc++-v3/include/bits/c++config >>> +++ b/libstdc++-v3/include/bits/c++config >>> @@ -299,7 +299,8 @@ namespace std >>> >>> #if _GLIBCXX_USE_CXX11_ABI >>> namespace std >>> { >>> >>> - inline namespace __cxx11 __attribute__((__abi_tag__ ("cxx11"))) { } >>> + inline namespace __cxx11 >>> + __attribute__((__abi_tag__ ("cxx11"), __diagnose_as__("std"))) { } >> >> 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' still > 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 enable > the removal of nesting (e.g. from std::experimental::parallelism_v2::simd to > stdx::simd). However, for types and functions it would be a problem to drop > the enclosing scope, because the scope can be class templates and thus the > diagnose_as attribute would remove all template parms & args. I'd think you could get the same effect from a hypothetical namespace [[gnu::diagnose_as]] stdx = std::experimental; though we'll need to add support for attributes on namespace aliases to the grammar. >>> - 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 > instantiation without introducing a name for users. E.g. > > using __only_to_apply_the_attribute [[gnu::diagnose_as("intvector")]] > = std::vector; > > Now all diagnostics of 'std::vector' would print 'intvector' instead. 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. > But in general, I tend to agree, for type aliases there's rarely a case where the > names wouldn't match. > > However, I didn't want to special-case the attribute parameters for type > aliases (or introduce another attribute just for this case). The attribute > 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. "Treat this declaration as the name of the type/namespace it refers to in diagnostics" also seems consistent to me. > FWIW, before you suggest to have one attribute for namespaces and one for type > aliases (to cover the std::string case), I have another use case in stdx::simd > (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 = _Scalar; > } > > If the attribute were on the type alias (using scalar [[gnu::diagnose_as]] = > _Scalar;), then we'd have to apply the attribute to _Scalar after it was > completed. That seemed like a bad idea to me. Well, in your sample code, _Scalar isn't complete at the point of the alias-declaration. But even if it were, since the attribute doesn't affect code generation, it doesn't strike me as a big problem. Still, perhaps it would be better to store these aliases in a separate hash table instead of *_ATTRIBUTES. Jason