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 60BD3397301A for ; Fri, 28 May 2021 03:05:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 60BD3397301A Received: from mail-qk1-f200.google.com (mail-qk1-f200.google.com [209.85.222.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-507-VWW8oIYCM2mgcRkkNKTQrQ-1; Thu, 27 May 2021 23:05:55 -0400 X-MC-Unique: VWW8oIYCM2mgcRkkNKTQrQ-1 Received: by mail-qk1-f200.google.com with SMTP id b19-20020a05620a0893b02902e956b29f5dso1984233qka.16 for ; Thu, 27 May 2021 20:05:55 -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=kU2DQAJnf4ca2tgsm+hlpixfv66t7GAD5QZQzOEeS3KpnRAt6/cgx0ioUG+T7hTGRm YzrWpIVCGySsfFDPw5CuuYeGvg7wQ6n+nHD67thsJqJCcS4bYCec3e7WmOthvJw06BM4 M9ouaiHyumJ3PH9t0KQBAKqixL6Cfw7JRMODmIl8T5cTVsv25IKIX099+9b2Afvl5qXL onZna7KBvkVh9yRRXHBTiUiRMdVwkRhKJP26l1RUH+SgSXPczGqWUCVRcfCI2FhZWeLH tL0D2I8n+cY/TuU3w+uxh2eBOGvfdDvo24RititN8ZlsGfkmLecW1gektkGlI1x5Y1yL cx4g== X-Gm-Message-State: AOAM532+Ke7Y02l4ab/q1Kcof1YoHvcCsrysYK+OIjUGdXDSJQozqUMo TnSvDHQmGNtCrWwPt4gBWwBmvuv0meg3QYgFMMdSl4gBCQEf4OPVkjIWDv5sZx1mcGzZutBX/F0 QQjsfodNvbPfi+NWUGA== X-Received: by 2002:ac8:5197:: with SMTP id c23mr1564815qtn.292.1622171155103; 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=unavailable 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 03:06:00 -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