From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by sourceware.org (Postfix) with ESMTP id A3C633940CE9 for ; Wed, 11 Mar 2020 20:10:55 +0000 (GMT) Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-43-StMbiu5iMfmv9RcReA8Alg-1; Wed, 11 Mar 2020 16:10:53 -0400 X-MC-Unique: StMbiu5iMfmv9RcReA8Alg-1 Received: by mail-qv1-f72.google.com with SMTP id r16so2080985qvp.13 for ; Wed, 11 Mar 2020 13:10:53 -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=C05q5tGTIh6gBSyIVTVDAIYeXG04XFGedsrCMra9P1g=; b=DzKFsyybdqTT6d9x7tCThF9ZUXxt6Lmmv8mOIaCMKIvQ2FuAXT/nqCn29NEO2VzF5F WBM2kfdZflj/6hvgo6BifLGu9ED5XTIrA6RvynREGdOD9zUA50sE05cOTGnrvBW3o5fD U7iDQgtgUSyx/3xcSH/Kcg659sH5ttDcRVntjOcgZeUpY2YIJ5EkYfF+IiJgFLMe494Y J5Bsy3K9bNlVc9saG1PEXJhsiAF+MzGxvd8IqOQ3iN3TQdn5NUdRW1p5gAMbHu8iOzXY ZwM5sa6hCkxKEz3mzajQMAEUSQX0m+7PM4rkkCZ8fksGtPxSPR4LwAK/U/34LX46XCWM wKRw== X-Gm-Message-State: ANhLgQ2AwjF2nC5WOn6WUk3+x1JHnLTAstfrdm4Zle3ONPDBwRT7l25d WayAjcWEeFD++n+hlG1RHxA3N6TBmUn7BnrhIMz2OnbG2jooLSaacfUsmgKq4ct8oGQrgQFXwq+ iiay2fObZqYaXsFlRmQ== X-Received: by 2002:ac8:6ec8:: with SMTP id f8mr4361491qtv.283.1583957452380; Wed, 11 Mar 2020 13:10:52 -0700 (PDT) X-Google-Smtp-Source: ADFU+vtoMxKUc08jQiyrWoc6PjASkQi4VCE7alJBwk7MZK3CyiIWoGbQohTWyDyRaW7vV8iXga/FKQ== X-Received: by 2002:ac8:6ec8:: with SMTP id f8mr4361460qtv.283.1583957451940; Wed, 11 Mar 2020 13:10:51 -0700 (PDT) Received: from [192.168.1.148] (209-6-216-142.s141.c3-0.smr-cbr1.sbo-smr.ma.cable.rcncustomer.com. [209.6.216.142]) by smtp.gmail.com with ESMTPSA id v82sm26221100qka.51.2020.03.11.13.10.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 11 Mar 2020 13:10:50 -0700 (PDT) Subject: Re: [PATCH] avoid -Wredundant-tags on a first declaration in use (PR 93824) To: Martin Sebor , gcc-patches References: <010f6d68-a64e-45a4-744e-c040a4ea94d6@redhat.com> <65013bfc-23c3-47fb-a58d-9ab802d1febb@gmail.com> <2698a399-4176-2b5f-a134-52a0d82c2121@redhat.com> <13b8faa9-74b1-6131-5dda-d4f34dfa8af0@gmail.com> <77dc94af-40f1-46fd-f3f4-ceb7e3afc4b6@gmail.com> <00f21176-ea92-937c-5c8a-c04d5d813257@redhat.com> <90a6aebc-8fef-0b96-cd2b-3234bd82b9a0@gmail.com> From: Jason Merrill Message-ID: <2c553c0d-c0ac-88ba-2a85-12c523a9a164@redhat.com> Date: Wed, 11 Mar 2020 16:10:50 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0 MIME-Version: 1.0 In-Reply-To: <90a6aebc-8fef-0b96-cd2b-3234bd82b9a0@gmail.com> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=0.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, 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: Wed, 11 Mar 2020 20:10:56 -0000 On 3/11/20 12:57 PM, Martin Sebor wrote: > On 3/9/20 6:08 PM, Jason Merrill wrote: >> On 3/9/20 5:39 PM, Martin Sebor wrote: >>> On 3/9/20 1:40 PM, Jason Merrill wrote: >>>> On 3/9/20 12:31 PM, Martin Sebor wrote: >>>>> 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.=C2=A0 According to the reported= =20 >>>>>>>>> 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=20 >>>>>>>>> mapping >>>>>>>>> as -Wmismatched-tags.=C2=A0 The patch also somewhat improves the= =20 >>>>>>>>> detection >>>>>>>>> of both issues in template declarations (though more work is stil= l >>>>>>>>> needed there). >>>>>>>> >>>>>>>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 a new entry for= it and return unless it's a declaration >>>>>>>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 involving a tem= plate that may need to be diagnosed by >>>>>>>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -Wredundant-tag= s.=C2=A0 */ >>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *rdl =3D class_decl_loc_t (c= lass_key, false, def_p); >>>>>>>>> -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return; >>>>>>>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (TREE_CODE (decl) !=3D TEMPLAT= E_DECL) >>>>>>>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return; >>>>>>>> >>>>>>>> How can the first appearance of a class template be redundant? >>>>>>> >>>>>>> I'm not sure I correctly understand the question.=C2=A0 The comment= says >>>>>>> "involving a template" (i.e., not one of the first declaration of >>>>>>> a template).=C2=A0 The test case that corresponds to this test is: >>>>>>> >>>>>>> =C2=A0=C2=A0 template struct S7 { }; >>>>>>> =C2=A0=C2=A0 struct S7 s7v;=C2=A0 // { dg-warning "\\\[-Wredu= ndant-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.=C2=A0 For exam= ple: >>>>>>> >>>>>>> =C2=A0=C2=A0 template struct S7 { }; >>>>>>> =C2=A0=C2=A0 template >>>>>>> =C2=A0=C2=A0 using U =3D struct S7;=C2=A0=C2=A0 // missing warni= ng >>>>>> >>>>>> When we get here for an instance of a template, it doesn't make=20 >>>>>> sense to treat it as a new type. >>>>>> >>>>>> If decl is a template and type_decl is an instance of that=20 >>>>>> template, do we want to (before the lookup) change type_decl to=20 >>>>>> the template or the corresponding generic TYPE_DECL, which should=20 >>>>>> already be in the table? >>>>> >>>>> I'm struggling with how to do this.=C2=A0 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? >>>>> >>>>> =C2=A0=C2=A0 1) Instance of the primary: >>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 template class A; >>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 struct A a; >>>>> >>>>> =C2=A0=C2=A0 2) Instance of an explicit specialization: >>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 template class B; >>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 template <> struct B; >>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 class B b; >>>>> >>>>> =C2=A0=C2=A0 3) Instance of a partial specialization: >>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 template class C; >>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 template struct C; >>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 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? >>>> >>>> I think you're looking for most_general_template. >>> >>> I don't think that's quite what I'm looking for.=C2=A0 At least it does= n't >>> return the template or its specialization in all three cases above. >> >> Ah, true, that function stops at specializations.=C2=A0 Oddly, I don't= =20 >> think there's currently a similar function that looks through them. =20 >> You could create one that does a simple loop through DECL_TI_TEMPLATE=20 >> like is_specialization_of. >=20 > Thanks for the tip.=C2=A0 Even with that I'm having trouble with partial > specializations.=C2=A0 For example in: >=20 > =C2=A0 template =C2=A0=C2=A0 struct S; > =C2=A0 template class S; > =C2=A0 extern class=C2=A0 S s1; > =C2=A0 extern struct S s2;=C2=A0 // expect -Wmismatched-tags >=20 > how do I find the declaration of the partial specialization when given > the type in the extern declaration?=C2=A0 A loop in my find_template_for(= ) > function (similar to is_specialization_of) only visits the implicit > specialization S (i.e., its own type) and the primary. Is that a problem? The name is from the primary template, so does it=20 matter for this warning whether there's an explicit specialization involved= ? > Martin >=20 >> >>> In (2) and (3) it won't distinguish between specializations of B or >>> C on different types.=C2=A0 In (2), the function returns the same resul= t >>> for both: >>> >>> =C2=A0=C2=A0 template <> struct B; >>> =C2=A0=C2=A0 template <> struct B; >>> >>> In (3), it similarly returns the same result for both of >>> >>> =C2=A0=C2=A0 template struct C; >>> =C2=A0=C2=A0 template struct C; >>> >>> even though they are declarations of distinct types. >> >> >> Jason >> >=20