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 1B0FB395144A for ; Tue, 22 Jun 2021 19:52:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1B0FB395144A 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-115-SlfxmKExOSGO2wcYPF_u5Q-1; Tue, 22 Jun 2021 15:52:18 -0400 X-MC-Unique: SlfxmKExOSGO2wcYPF_u5Q-1 Received: by mail-qv1-f71.google.com with SMTP id y17-20020ad445b10000b029027389e9530fso298070qvu.4 for ; Tue, 22 Jun 2021 12:52:18 -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=I6KAASMcxIIxZWUoYgSsQ25nynKD7/uP8niJ7PRUiwo=; b=GVgepa9I/rTXAc4V/wif0N0tJl/xQo89x3zMjsI20h7j/MfhSTy6ejl/EyAzZfljn9 ejrAwt0G/827RyPIJfozn/et5UscyZ1BdRX6J3a+3ELnpC0kaP7u4MGzR+qosSMRjKAC wqwv/OJCOyNzitFRCjiW5SwcE0ChAtj7QbRtdYvy6HazGUw6QyIMX5hR5G2LibH29T+p xFF0E2Fid8qkHtkwX6j7RsWVdzoYtzv3bfWjlzvHVc4A6s+CBTNHGsavpdjr2OhZtA3+ cwhUp9uu8A9uEOHMMm9DOORYVEbjTGYqiPdR+v6squsndaRNbi0hrXJi2W5Fwe6lBTOx I32g== X-Gm-Message-State: AOAM531fHDg5m0zUMGp2q5cG1tk1QH26FyzN1iX6airChBy4RJX8vfR1 Ae+iFzg2ZBWjerbP7fCWlVSUV5DlNndTRdztg0OLK7hm02K1lXcimIkSo+qk/wW7agw3L9ZDuxH 1JHAZSRAha4S5LvYniaUZcKjfjd4E29xIFmDm75gdCyBPcn5zm0qYLtCgg0ro75o= X-Received: by 2002:a05:620a:21c3:: with SMTP id h3mr6317332qka.202.1624391538176; Tue, 22 Jun 2021 12:52:18 -0700 (PDT) X-Google-Smtp-Source: ABdhPJztGMkcTbuBTlq9W9EnV5soczPDAN5hdpYUg94ygm1Se5mB06E9BBWl7+ToxlwS8UGRg1Wumg== X-Received: by 2002:a05:620a:21c3:: with SMTP id h3mr6317305qka.202.1624391537857; Tue, 22 Jun 2021 12:52:17 -0700 (PDT) Received: from [192.168.1.148] (130-44-159-43.s11817.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [130.44.159.43]) by smtp.gmail.com with ESMTPSA id 5sm13745301qkj.99.2021.06.22.12.52.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Jun 2021 12:52:17 -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> <2511559.k3LOHGUjKi@minbar> <2031764.yKVeVyVuyW@minbar> From: Jason Merrill Message-ID: Date: Tue, 22 Jun 2021 15:52:16 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <2031764.yKVeVyVuyW@minbar> 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.1 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: Tue, 22 Jun 2021 19:52:22 -0000 On 6/22/21 3:30 AM, Matthias Kretz wrote: > On Wednesday, 16 June 2021 02:48:09 CEST Jason Merrill wrote: >>> IIUC, your main concern is that my proposed diagnose_as *can* be used to >>> make diagnostics worse, by replacing names with strings that are not >>> valid identifiers. Of course, whoever uses the attribute to that effect >>> should have a good reason to do so. Is your other concern that using the >>> attribute in a "good" way is repetitive? Would you be happier if I make >>> the string argument to the attribute optional for type aliases? >> >> Yes, and namespace aliases. > > I'll look into making the attribute argument optional for aliases. Would you > accept the patch with this change? Yes (after resolving any technical details, of course). > Questions: > > 1. If a type alias applies the attribute after a type was completed / > implicitly instantiated (and possibly already used in diagnostics) should / > can I still modify the type and add the attribute? Yes, because it has no semantic effect. For alias templates, you probably want the attribute only on the templated class, not on the instantiations. > 2. About the namespace aliases: IIUC an attribute would currently be rejected > because of the C++ grammar. Do you want to make it valid before WG21 > officially decides how to proceed? And if you have a pointer for me where I'd > have to adjust the grammar rules, that'd help. :) You will want to adjust cp_parser_namespace_alias_definition to handle attributes like cp_parser_namespace_definition. The latter currently accepts attributes both before and after the name, which seems like a good pattern to follow so it doesn't matter which WG21 chooses. Probably best to pedwarn about C++11 attributes in both locations for now, not just after. Jason