From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-74.mimecast.com (us-smtp-delivery-74.mimecast.com [63.128.21.74]) by sourceware.org (Postfix) with ESMTP id 44ACC394B004 for ; Fri, 20 Mar 2020 21:53:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 44ACC394B004 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-206-1RDkXXJ4N3GtgDP1ug606w-1; Fri, 20 Mar 2020 17:53:44 -0400 X-MC-Unique: 1RDkXXJ4N3GtgDP1ug606w-1 Received: by mail-qt1-f197.google.com with SMTP id t6so7060447qtj.12 for ; Fri, 20 Mar 2020 14:53:43 -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=fwQfoIucCxgjew3rdMCIeihB9A3p8Dd1H8CiWznlzcI=; b=phNicS84KHkIdoykvTVOrBnM4OBrBNic+6I/HTaNvWGPKc8wLtT61qLZbQRLvtSxMV QC672ubUEzH9Bt/xwr8phLNNbOzCmlm2OSFkdlntGOC+P3Tp8BjHJpm4mkCoGgcw5oaf FbO+KfNIdbiogKpMq25e+63CSLfKwwA42fLsdnApbZ7xFQ+A+Y37nHa+nN1clMDI8qyU yeS+Sl2oW2CpYyLD1excHTIIKv3hX/tB872dhek9e8XdFdewXQpSO3gZGlFoFJyrty6Q E50wMusX4iyvdoyxxdGbln0qYp9wdSqesMQ3gmsp3Whf7r1qcwiuVG2P8lSTlbNqoY03 6M6g== X-Gm-Message-State: ANhLgQ1kChkIxENRtNc5BhxwEduAaqpBpB256E630QuTQNKoKAJIPl9H 1ikZBgUFDhUjJLEXDJVYZdMtVSsq+YyFSszP7PvvoaadSOhkGJXKCGv9WPTZ/owDd/EtQA6xobl sfvCmku+4ksLDVe0Zbw== X-Received: by 2002:a0c:9102:: with SMTP id q2mr6295913qvq.161.1584741222790; Fri, 20 Mar 2020 14:53:42 -0700 (PDT) X-Google-Smtp-Source: ADFU+vvpc2Vh5VwJtKL78B3Ma5kZw2PKt6uo7lMYCoipKLA+zoqgoNMlFL+EqnSY4xdWgylSRHrIdg== X-Received: by 2002:a0c:9102:: with SMTP id q2mr6295880qvq.161.1584741222235; Fri, 20 Mar 2020 14:53:42 -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 m10sm5666390qte.71.2020.03.20.14.53.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 20 Mar 2020 14:53:41 -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> <2c553c0d-c0ac-88ba-2a85-12c523a9a164@redhat.com> <2744364d-e705-06f8-064a-5425ade11669@gmail.com> <1239c5f0-7ea7-e760-0b1c-1fe725a5e129@redhat.com> <48d42e59-64c4-6674-40a4-c786f9e504f4@gmail.com> From: Jason Merrill Message-ID: Date: Fri, 20 Mar 2020 17:53:40 -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: <48d42e59-64c4-6674-40a4-c786f9e504f4@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: Fri, 20 Mar 2020 21:53:48 -0000 On 3/19/20 7:55 PM, Martin Sebor wrote: > On 3/18/20 9:07 PM, Jason Merrill wrote: >> On 3/12/20 6:38 PM, Martin Sebor wrote: > ... >>> +=C2=A0=C2=A0=C2=A0=C2=A0 declarations of a class from its uses doesn't= work for type=20 >>> aliases >>> +=C2=A0=C2=A0=C2=A0=C2=A0 (as in using T =3D class C;).=C2=A0 */ >> >> Good point.=C2=A0 Perhaps we could pass flags to=20 >> cp_parser_declares_only_class_p and have it return false if=20 >> CP_PARSER_FLAGS_TYPENAME_OPTIONAL, since that is set for an alias but=20 >> not for a normal type-specifier. >=20 > I wondered if there was a way to identify that we're dealing with > an alias.=C2=A0 CP_PARSER_FLAGS_TYPENAME_OPTIONAL is set not just for > those but also for template declarations (in > cp_parser_single_declaration) but I was able to make it work by > tweaking cp_parser_type_specifier.=C2=A0 It doesn't feel very clean > (it seems like either the bit or all of cp_parser_flags could be > a member of the parser class or some subobject of it) but it does > the job.=C2=A0 Thanks for pointing me in the right direction! Hmm, true, relying on that flag is probably too fragile. And now that I=20 look closer, I see that we already have is_declaration in=20 cp_parser_elaborated_type_specifier, we just need to check that before=20 cp_parser_declares_only_class_p like we do earlier in the function. >>> +=C2=A0 if (!decl_p && !def_p && TREE_CODE (decl) =3D=3D TEMPLATE_DECL) >>> =C2=A0=C2=A0=C2=A0=C2=A0 { >>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /* When TYPE is the use of an implicit = specialization of a=20 >>> previously >>> +=C2=A0=C2=A0=C2=A0=C2=A0 declared template set TYPE_DECL to the type o= f the primary=20 >>> template >>> +=C2=A0=C2=A0=C2=A0=C2=A0 for the specialization and look it up in CLAS= S2LOC below.=C2=A0 For=20 >>> uses >>> +=C2=A0=C2=A0=C2=A0=C2=A0 of explicit or partial specializations TYPE_D= ECL already points to >>> +=C2=A0=C2=A0=C2=A0=C2=A0 the declaration of the specialization.=C2=A0 = */ >>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 type_decl =3D specialization_of (type_d= ecl); >> >> Here shouldn't is_use be true? >=20 > If it were set to true here we would find the partial specialization > corresponding to its specialization in the use when what we want is > the latter.=C2=A0 As a result, for the following: >=20 > =C2=A0 template =C2=A0=C2=A0 struct S; > =C2=A0 template struct S; >=20 > =C2=A0 extern class=C2=A0 S s1;=C2=A0=C2=A0 // expect -Wmismatched= -tags > =C2=A0 extern struct S s2; >=20 > we'd end up with a warning for s2 pointing to the instantiation of > s1 as the "guiding declaration:" >=20 > z.C:5:15: warning: =E2=80=98template struct S=E2=80=99 decla= red with a=20 > mismatched class-key =E2=80=98struct=E2=80=99 [-Wmismatched-tags] > =C2=A0=C2=A0=C2=A0 5 | extern struct S s2; > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ^~~~~~~ > z.C:5:15: note: remove the class-key or replace it with =E2=80=98class=E2= =80=99 > z.C:4:15: note: =E2=80=98template struct S=E2=80=99 first de= clared as=20 > =E2=80=98class=E2=80=99 here > =C2=A0=C2=A0=C2=A0 4 | extern class=C2=A0 S s1;=C2=A0=C2=A0 // exp= ect -Wmismatched-tags > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ^~~~~~~ I found this puzzling and wanted to see why that would be, but I can't=20 reproduce it; compiling with -Wmismatched-tags produces only wa2.C:4:17: warning: =E2=80=98S=E2=80=99 declared with a mismatched cla= ss-key=20 =E2=80=98class=E2=80=99 [-Wmismatched-tags] 4 | extern class S s1; // expect -Wmismatched-tags | ^~~~~~~ wa2.C:4:17: note: remove the class-key or replace it with =E2=80=98struct= =E2=80=99 wa2.C:2:29: note: =E2=80=98S=E2=80=99 first declared as =E2=80=98struct= =E2=80=99 here 2 | template struct S; So the only difference is whether we talk about S or S. I=20 agree that the latter is probably better, which is what you get without=20 my suggested change. But since specialization_of does nothing if is_use=20 is false, how about removing the call here and removing the is_use=20 parameter? > + if (tree spec =3D most_specialized_partial_spec (ret, tf_none)) > + if (spec !=3D error_mark_node) > + ret =3D TREE_VALUE (spec); I think you want to take the TREE_TYPE of the template here, so you=20 don't need to do it here: > + tree pt =3D specialization_of (TYPE_MAIN_DECL (type), true); > + if (TREE_CODE (pt) =3D=3D TEMPLATE_DECL) > +=09 pt =3D TREE_TYPE (pt); > + pt =3D TYPE_MAIN_DECL (pt); And also, since it takes a TYPE_DECL, it would be better to return=20 another TYPE_DECL rather than a _TYPE, especially since the only caller=20 immediately extracts a TYPE_DECL. Jason