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 [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id 0B549384F007 for ; Wed, 7 Jul 2021 22:34:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0B549384F007 Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-128-jD82lKVyOauosc462jzxVQ-1; Wed, 07 Jul 2021 18:34:50 -0400 X-MC-Unique: jD82lKVyOauosc462jzxVQ-1 Received: by mail-qt1-f198.google.com with SMTP id t6-20020ac80dc60000b029024e988e8277so2143939qti.23 for ; Wed, 07 Jul 2021 15:34:50 -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:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=N5+yxwMSrXJBzdektKzIlem0HmAwFRlfTXBDgIbNof0=; b=GZ3vuT4+FzE3OcF4TZmH+0SIUUgC9gP8YrxRbs/L3zBLQp2QKz7WTyWGg1eJC6gL/q YLW5C+6gC2G/uDKgrEpI553gp64YoNe99BagjhHcIXjy/WN1odvVVmf+53KOwZIfC6NL YfYQF1KZsWit179F3hGNulR2NwdDcKCQSuXjZh7e5Gzd/ZJZGT/i9HpkUlB67w3Zu/Cy WOxLCZ2pL/FLYaBW8z4msjv+tPGnumag311907DN26p0wQbYm/gvv1rK+4DCqR2TCOvl llBR2oeX8lsBwWt1NIRYbjvQsGxHmbTGM6WHb3r6H3gmVuwT3ziN1SFhWZcHWg1tnASY 34YA== X-Gm-Message-State: AOAM531KO6whAPEmAGIV7FfQ7cr2gprUOsz8wS3DM6str3Nx+6g38Q0a p50dSldVonvQMTiyV4DYMG5A7L/+/+tShfDpWlxMNu6AMeOwDyH4dQBjHVpdiNtPS5FKqADKad1 +uDHmigf7QRQFmJHDW63WMyTaowxpc25/qTXFF87WG+3crDNK+ag9f0NdUOqcr+6/Mw== X-Received: by 2002:a05:620a:142d:: with SMTP id k13mr10216687qkj.48.1625697289949; Wed, 07 Jul 2021 15:34:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxKVe5Vf+HCoNrQbq/+A9yROr4W8b97fn9k7yLjXYpPNU1yFFbT/B/sgmkfu3o/o6StdlO85g== X-Received: by 2002:a05:620a:142d:: with SMTP id k13mr10216665qkj.48.1625697289590; Wed, 07 Jul 2021 15:34:49 -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 q12sm155391qkn.47.2021.07.07.15.34.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Jul 2021 15:34:49 -0700 (PDT) Subject: Re: [PATCH] Add gnu::diagnose_as attribute To: Matthias Kretz , gcc-patches@gcc.gnu.org References: <14205410.xuKvIAzr1H@excalibur> <2984128.Mn6ktlgx0N@excalibur> <16bf94b5-cda3-08df-144b-739fa1c0ce3f@redhat.com> <4558474.TO5rdG3zkT@excalibur> From: Jason Merrill Message-ID: Date: Wed, 7 Jul 2021 18:34:48 -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: <4558474.TO5rdG3zkT@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.8 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_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Wed, 07 Jul 2021 22:34:54 -0000 On 7/5/21 10:18 AM, Matthias Kretz wrote: > On Thursday, 1 July 2021 17:18:26 CEST Jason Merrill wrote: >> You probably want to adjust is_late_template_attribute to change that. > > Right, I hacked is_late_template_attribute but now I only see a TYPE_DECL > passed to my attribute handler (!DECL_ALIAS_TEMPLATE_P). > I.e. I don't know how > your previous comment is supposed to help me: > > On Tuesday, 22 June 2021 22:12:42 CEST Jason Merrill wrote: >> Yes. You can check that with get_underlying_template. > > FWIW, I don't feel qualified to implement the diagnose_as attribute on alias > templates. The trees I've seen while testing the following test case don't > make sense to me. :( > > > // { dg-do compile { target c++11 } } > // { dg-options "-fdiagnostics-use-aliases -fpretty-templates" } > > template class A0 {}; > template using B0 [[gnu::diagnose_as]] = A0; // #1 > template using C0 [[gnu::diagnose_as]] = A0; // #2 > > template class A1 {}; > template class A1 {}; > template using B1 [[gnu::diagnose_as]] = A1; // #3 > > void fn_1(int); > > int main () > { > fn_1 (A0 ()); // { dg-error "cannot convert 'B0' to 'int'" } > fn_1 (A1 ()); // { dg-error "cannot convert 'A1' to 'int'" } > fn_1 (A1 ()); // { dg-error "cannot convert 'B1' to 'int'" } > } > > On #1 I see !COMPLETE_TYPE_P (TREE_TYPE (*node)) Yes; a use that matches the primary template but is not the primary template gets a separate dependent type. > while on #3 TREE_TYPE (*node) is a complete type. Indeed, we don't do the same thing for partial specializations. > Like I said, I don't get to see the TEMPLATE_DECL of > either #1, #2, or #3, only a TYPE_DECL whose TREE_TYPE is A0. I thus have no > idea how to reject #2. The difference between #1 and #2 is that same_type_p (#1, CLASSTYPE_PRIMARY_TEMPLATE_TYPE (TREE_TYPE (#1)) is true; see the use of that in resolve_typename_type. Jason