From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw1-xc42.google.com (mail-yw1-xc42.google.com [IPv6:2607:f8b0:4864:20::c42]) by sourceware.org (Postfix) with ESMTPS id 97ED9394CC3C for ; Mon, 9 Mar 2020 16:31:35 +0000 (GMT) Received: by mail-yw1-xc42.google.com with SMTP id d206so10673417ywa.12 for ; Mon, 09 Mar 2020 09:31:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=awzd9A5HFZ691FHIwKRFUNWyZIwDTUSIryZLnP6mKRY=; b=Vuqc0WGfbzMFWcfRNc6GAszrD1F0yCyxQJjZzasDwlu/5n9dsPKvA2lGRqxVKqhEBh bSd3GJNh8T1LLFmQd8cEKVNsJG87jfPKsDtcMcdL6ng1rncV5zS1CEUoj3omdG/9ifsQ 3O/nMmiyNGlKHYx0550COHTrvEXTXnlJZgxF1+ZJlPV+zQHw4EHDsS+7atgABk8FENV8 Z32H8Ia/gJmZTGhuKSM+xvX74UWzZ+N55XMgl4TLDldEvGaqmcsN++FolzUARFGM9lx1 tWkFcbGYvXeP1dcy44OC5VFghO2ZR8vidrdvXEFy+pdBUBel4WvDsCS+pg+h+00bsqh2 BB4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=awzd9A5HFZ691FHIwKRFUNWyZIwDTUSIryZLnP6mKRY=; b=tKLC1tTsD6T8IYKnMLLCse4t1K0dMSm1Dbm20ee9w0GO3v0Tnsg1+xpVVLMKf7jO/9 4xVxLxRIsvnAw2YCBIVkZemv3ZJ7yeXj9Kli4s05kNpmV7/hM0bVYbiZcxDyGf49Ta9Z ihR1PRx+E13xpiCeu5EONVq42UTkLGTLbRjHdJJ0YzBvXt92Jzx9eVbFxLavAQVwk2Zu MCoZ+RHCWEXgIFxguZwIVD9WkDVTisF3RwY0vZ7xK0GlE6jHgijxn/0pcXvG2jlZ4zKT kAEI1YFTH2myO8tWIhXRC0XXaupL14gy8SOCoxzBHsMsuWwJjSFjLL7TFKIP+lxlMDmV AgdA== X-Gm-Message-State: ANhLgQ04cbJ+qUerRrfb/98K2EuW2wQd/2JLNseYD7hy8sLYX0Fcqo2J 3ulErwd2ak55Df86+t3o14hEMFq5 X-Google-Smtp-Source: ADFU+vuqV+ofewzCFBCZdimI+QM97ENEqiZABHg7DQe3Yamaeei8eqyi2mWVeyRySgeuvj+BFNjbdQ== X-Received: by 2002:a0d:e297:: with SMTP id l145mr18500924ywe.132.1583771494932; Mon, 09 Mar 2020 09:31:34 -0700 (PDT) Received: from [192.168.0.41] (97-118-124-45.hlrn.qwest.net. [97.118.124.45]) by smtp.gmail.com with ESMTPSA id t3sm18968422ywi.18.2020.03.09.09.31.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Mar 2020 09:31:34 -0700 (PDT) From: Martin Sebor Subject: Re: [PATCH] avoid -Wredundant-tags on a first declaration in use (PR 93824) To: Jason Merrill , gcc-patches References: <010f6d68-a64e-45a4-744e-c040a4ea94d6@redhat.com> <65013bfc-23c3-47fb-a58d-9ab802d1febb@gmail.com> <2698a399-4176-2b5f-a134-52a0d82c2121@redhat.com> Message-ID: <13b8faa9-74b1-6131-5dda-d4f34dfa8af0@gmail.com> Date: Mon, 9 Mar 2020 10:31:32 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <2698a399-4176-2b5f-a134-52a0d82c2121@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GARBLED_BODY, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS autolearn=no 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: Mon, 09 Mar 2020 16:31:36 -0000 On 2/28/20 1:24 PM, Jason Merrill wrote: > On 2/28/20 12:45 PM, Martin Sebor wrote: >> On 2/28/20 9:58 AM, Jason Merrill wrote: >>> On 2/24/20 6:58 PM, Martin Sebor wrote: >>>> -Wredundant-tags doesn't consider type declarations that are also >>>> the first uses of the type, such as in 'void f (struct S);' and >>>> issues false positives for those.  According to the reported that's >>>> making it harder to use the warning to clean up LibreOffice. >>>> >>>> The attached patch extends -Wredundant-tags to avoid these false >>>> positives by relying on the same class_decl_loc_t::class2loc mapping >>>> as -Wmismatched-tags.  The patch also somewhat improves the detection >>>> of both issues in template declarations (though more work is still >>>> needed there). >>> >>>> +         a new entry for it and return unless it's a declaration >>>> +         involving a template that may need to be diagnosed by >>>> +         -Wredundant-tags.  */ >>>>        *rdl = class_decl_loc_t (class_key, false, def_p); >>>> -      return; >>>> +      if (TREE_CODE (decl) != TEMPLATE_DECL) >>>> +        return; >>> >>> How can the first appearance of a class template be redundant? >> >> I'm not sure I correctly understand the question.  The comment says >> "involving a template" (i.e., not one of the first declaration of >> a template).  The test case that corresponds to this test is: >> >>    template struct S7 { }; >>    struct S7 s7v;  // { dg-warning "\\\[-Wredundant-tags" } >> >> where DECL is the TEPLATE_DECL of S7. >> >> As I mentioned, more work is still needed to handle templates right >> because some redundant tags are still not diagnosed.  For example: >> >>    template struct S7 { }; >>    template >>    using U = struct S7;   // missing warning > > When we get here for an instance of a template, it doesn't make sense to > treat it as a new type. > > If decl is a template and type_decl is an instance of that template, do > we want to (before the lookup) change type_decl to the template or the > corresponding generic TYPE_DECL, which should already be in the table? I'm struggling with how to do this. Given type (a RECORD_TYPE) and type_decl (a TEMPLATE_DECL) representing the use of a template, how do I get the corresponding template (or its explicit or partial specialization) in the three cases below? 1) Instance of the primary: template class A; struct A a; 2) Instance of an explicit specialization: template class B; template <> struct B; class B b; 3) Instance of a partial specialization: template class C; template struct C; class C c; By trial and (lots of) error I figured out that in both (1) and (2), but not in (3), TYPE_MAIN_DECL (TYPE_TI_TEMPLATE (type)) returns the template's type_decl. Is there some function to call to get it in (3), or even better, in all three cases? Martin