From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by sourceware.org (Postfix) with ESMTP id EDB74394D898 for ; Mon, 9 Mar 2020 19:40:14 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1583782814; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=htkUlJYOgyUfBhl9UVM+xV49LVNrTjqef9dHCYkzV7k=; b=MQyhHF5TE2l7PMoFS9ozqz+ezBOYi3aIK82pX7zdRnMo/bgH/hO4XquZuGoeN3YPpMMaC9 ZCSxpDl8YTMi4eezJuPkrOJOx3WJpIVb4CwOmTHwql/E4FzfhmXIXlnQgdN31NI0Jn0kgi E0I0ibUAG7Ai8VgWaEK7JOdcJ7lYIFc= 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-2-u86QST5oOS-Yf5vYaIHYkg-1; Mon, 09 Mar 2020 15:40:12 -0400 X-MC-Unique: u86QST5oOS-Yf5vYaIHYkg-1 Received: by mail-qv1-f71.google.com with SMTP id k1so6692362qvw.1 for ; Mon, 09 Mar 2020 12:40:12 -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=VExR8e0c6HAfrBqkks28VCoMaNLjH+3lMTKsAm2wpIA=; b=GK7s0G2kKOpTQnExoBnceuLFal+ZPjGVJWVxMzp0pBb6UUWwUzUSTzSiOB9t3vUKfR ex4XOElrE6sSQGs5WDtoitiJpBN9x+2LWivlPtJ3qrT1pY2HB18Xvus7cCi2LUsVpyPM v8VZ3uJ7JE95DcwvWV6ddNgSQ7WNalXSWpVXfHabLIEE/CTQKYJAjm+Nj/F3RyZkq6b/ gbAVTzF2mRyJhzh7P7sDgmttnrQJyznC4ixCdaiB8+5mltCMshly4S/wudJ7D8oDxplf 5BddXzWpCfoLMvl5Gq0DGEWLzud5ZGvU81lT/nTaQJNhG5u3fzJ1/jZ6QVg1WFpY8/YK /nIA== X-Gm-Message-State: ANhLgQ0Kp723NfU5Z6lsteUsn9RtD0Mn1K4dbst3VN+AbzW/QyF1OGy+ D9pnXmsJqWcq5lcNldn3omkosLx1kWY7XYOZz0nxectBSondzRs+RcMuazbmHCcDh82Zo6XkHWC ERwbsf/FWk7TTUpBHSw== X-Received: by 2002:ae9:c012:: with SMTP id u18mr16697938qkk.140.1583782812000; Mon, 09 Mar 2020 12:40:12 -0700 (PDT) X-Google-Smtp-Source: ADFU+vuX9xgRooXo4F9+IQ4fSM2R6arQ/m0vkcToypL7NPIFRxWloYSFic7hGaZLyzA3I67YBpUmLg== X-Received: by 2002:ae9:c012:: with SMTP id u18mr16697913qkk.140.1583782811632; Mon, 09 Mar 2020 12:40:11 -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 z6sm22759887qka.34.2020.03.09.12.40.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Mar 2020 12:40:10 -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> From: Jason Merrill Message-ID: Date: Mon, 9 Mar 2020 15:40:09 -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: <13b8faa9-74b1-6131-5dda-d4f34dfa8af0@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: Mon, 09 Mar 2020 19:40:16 -0000 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 tha= t'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.=C2=A0 The patch also somewhat improves the dete= ction >>>>> of both issues in template declarations (though more work is still >>>>> 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 templat= e that may need to be diagnosed by >>>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -Wredundant-tags.= =C2=A0 */ >>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *rdl =3D class_decl_loc_t (class= _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 TEMPLATE_DE= CL) >>>>> +=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 say= s >>> "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 "\\\[-Wredundan= t-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 example: >>> >>> =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 warning >> >> When we get here for an instance of a template, it doesn't make sense=20 >> to treat it as a new type. >> >> If decl is a template and type_decl is an instance of that template,=20 >> do we want to (before the lookup) change type_decl to the template or=20 >> the corresponding generic TYPE_DECL, which should already be in the=20 >> table? >=20 > 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? >=20 > =C2=A0 1) Instance of the primary: > =C2=A0=C2=A0=C2=A0=C2=A0 template class A; > =C2=A0=C2=A0=C2=A0=C2=A0 struct A a; >=20 > =C2=A0 2) Instance of an explicit specialization: > =C2=A0=C2=A0=C2=A0=C2=A0 template class B; > =C2=A0=C2=A0=C2=A0=C2=A0 template <> struct B; > =C2=A0=C2=A0=C2=A0=C2=A0 class B b; >=20 > =C2=A0 3) Instance of a partial specialization: > =C2=A0=C2=A0=C2=A0=C2=A0 template class C; > =C2=A0=C2=A0=C2=A0=C2=A0 template struct C; > =C2=A0=C2=A0=C2=A0=C2=A0 class C c; >=20 > 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. >=20 > 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. Jason