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 BFD03398545E for ; Tue, 1 Jun 2021 19:12:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BFD03398545E Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-333-rEx8xgiPPt6b1AALt7o5lg-1; Tue, 01 Jun 2021 15:12:21 -0400 X-MC-Unique: rEx8xgiPPt6b1AALt7o5lg-1 Received: by mail-qt1-f197.google.com with SMTP id j19-20020ac85f930000b029021f033edf60so19824qta.10 for ; Tue, 01 Jun 2021 12:12:21 -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=QwXTSAvaParPZvgW3aHdk3eLlFBqgzxCHu1bLBIBFwU=; b=r+c36wLw76utlI0cwlzSpUoHpzWmqFMHgykr96WDyTGhn1iMajcoe+icfox8XdQjkb AuoCZ+UF3qHZxiuMQPA3Fy619a70cts1L82PmMDHeMnFNUpZmFAOdWfGC24z7t7kqQpD CzBzJ3C0eHvoNGRgQeqwttB4gk5+h2kjhc4MFNfOjFKOfOD4StVLO3/25xdq80/0Qfzg ZDBPZBzCkglWKCcYrPXnFxmsxhnTFMAWh8W3KvbjYhZEXCgGarxEqvS0KOXllG6CFyBC Jkntzb19Ed2Uz77tdMBVXaErCEdKx0JL37aMQ3POqcI7yhGhcYTvVzoMgh8eBgf/E5Tk b+Rg== X-Gm-Message-State: AOAM531wERMgyULyCp69y8BtRN4e3t2OhrfMvPmiSEPDiKds4zpml/HU mUHhAd4s7FGlEDHWNPnvGSs19SzF5ACL17lXhgTbX3LalMuoXtr7qpYmk2aTRN8DlxqDmIQy51h 5DbvqF6kAEtO5i0U= X-Received: by 2002:a05:6214:1791:: with SMTP id ct17mr4162038qvb.21.1622574740609; Tue, 01 Jun 2021 12:12:20 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzhXREPODhPhuImYEYRv2oJMMCSiRbs6YGjZIptti+pF8gqiIJLjfZPqUvnckgkSNRA7HwJtA== X-Received: by 2002:a05:6214:1791:: with SMTP id ct17mr4162022qvb.21.1622574740335; Tue, 01 Jun 2021 12:12:20 -0700 (PDT) Received: from [192.168.1.148] ([130.44.159.43]) by smtp.gmail.com with ESMTPSA id a23sm11729275qkl.6.2021.06.01.12.12.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Jun 2021 12:12:19 -0700 (PDT) Subject: Re: [PATCH] Add gnu::diagnose_as attribute To: Matthias Kretz , gcc-patches@gcc.gnu.org Cc: libstdc++@gcc.gnu.org, David Malcolm , Jonathan Wakely References: <14205410.xuKvIAzr1H@excalibur> <2039917.z2SizfLdUX@excalibur> <8cae5816-c00e-e8a6-59a5-9afce06d1fb2@redhat.com> <14231752.kytX9F1ty5@excalibur> From: Jason Merrill Message-ID: Date: Tue, 1 Jun 2021 15:12:18 -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: <14231752.kytX9F1ty5@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.6 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: 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: Tue, 01 Jun 2021 19:12:26 -0000 On 5/28/21 3:42 AM, Matthias Kretz wrote: > 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; >>>>> >>>>> :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. > > True. But that's also what lead to the error. GCC easily clears it up > nowadays, but wouldn't anymore if inline namespaces were hidden by default. > >> 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. > > 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. This is the basic disconnect: I think that these goals are contradictory, and that replacement names that are not valid identifiers will just confuse users that don't know about them. If a user sees stdx::foo in a diagnostic and then tries to refer to stdx::foo and gets an error, the diagnostic is not more helpful than one that uses the fully qualified name. Jonathan, David, any thoughts on this issue? > I don't think libstdc++ would ship with a namespace alias outside of the std > namespace. So we'd place the "burden" of using diagnose_as correctly on our > users. Also as a user you'd possibly have to repeat the namespace alias in > 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 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. > > I can imagine using it to make _Internal __names more readable while at the > same time discouraging users to utter them in their own code. Sorry for the > 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]")]] = _VecBuiltin<16>; > using __ignore_me_1 [[gnu::diagnose_as("[AVX]")]] = _VecBuiltin<32>; > using __ignore_me_2 [[gnu::diagnose_as("[AVX512]")]] = _VecBltnBtmsk<64>; > #endif > }}}} > > Then diagnostics would print 'stdx::simd' instead > of 'stdx::simd>'. (Users utter the type by > saying e.g. 'stdx::native_simd', while compiling with AVX512 flags.) Wouldn't it be better to print stdx::native_simd if that's how the users write the type? >>> 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. > > Sure. In general, I think > > namespace foo [[gnu::this_is_the_name_I_want]] = bar; > using foo [[gnu::this_is_the_name_I_want]] = bar; > > is not a terribly bad idea on its own. But it's not the solution for the > problems I set out to solve. > >> Still, perhaps it would be better to store these aliases in a separate hash >> table instead of *_ATTRIBUTES. > > Maybe. For performance reasons or for simplification of the implementation? I was thinking for not messing with the type after it's defined, but there are other things that do that (such as lazy declaration of implicit constructors) so I wouldn't worry about it. Jason