From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw1-xc44.google.com (mail-yw1-xc44.google.com [IPv6:2607:f8b0:4864:20::c44]) by sourceware.org (Postfix) with ESMTPS id 763793952D98 for ; Mon, 9 Mar 2020 21:39:05 +0000 (GMT) Received: by mail-yw1-xc44.google.com with SMTP id v138so11690028ywa.9 for ; Mon, 09 Mar 2020 14:39:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=2U94uGr1xL8NR9bfs/0+2bjbiriwmT07sr7M1P0dT90=; b=Al9dEBc6WI9IB0CV2bRtzEkoxj9gX9OPrbZmc2JUPl3TavDKCpUgOSGDcyVatq8FS0 XVfXL17mO/RpYyTzFZOAXLFlNO+UNzE4RPo+nygTJh9ceqVfF5t7Ffe5eYTFWtA4rf8z 838A0Bp9Oh3EkuYbc9TyikeiG5J22ziKzTj0y4TkN2CUReUVO2Ozujm9YMgY+DlzVIrs vvSPvYSVN0fsdv1ePnGhj51l2QOMXnwUI87jrH1Nn5DRQs59KDsfmRq5CRSS8V3LtLPH kptLBySBkjBxmR2NW/MgGa0hrA3BjQg17eraeQ/3F99jGwD1o06wauAYf8ohH/ay0sPK ikRQ== 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=2U94uGr1xL8NR9bfs/0+2bjbiriwmT07sr7M1P0dT90=; b=tZfzdfKZN+Di8B79rj+5eTNNX+IBWf9AX++FA7X6XPHyNMxTX4ZjYxG8kYOU0NR+Ey zuPGDF0JgPVczqMAxptT09CrNb6DXntXkex70nbFLU8yUBaoKpZYLLb0WLTLOC8PWbGF klVMb03+3gTc8QJRuNM5UqxKHdvxlmJq4npkwT9bTtH54V2XluE5vdFkajjo6kbUF1D7 X19wnis0CtOuhnUj+89lwtUzdIiTne2DzX9TjeF9dIQg2HqxoGIJaf9orLcWjx2hZL44 omXqDS1IBKQDHzELIjTsXMdGvMyKh14ZtoSgDuseb71FXMfMIi/IMT/Kqgw5tqqzREXC 2jBg== X-Gm-Message-State: ANhLgQ0m//Rj0csYNrUkNyulIW8JnqpsEq7VYQOZickWGV/EUZsj2O0J HJZ+I0hm42tzqDz5vsVGZiyIYgyQ X-Google-Smtp-Source: ADFU+vuLY8sq6Vj2Pw8I/Loo4qb2q/Ng+0TRbHUqFHiZNH419Ui8N5w+NW+9cdtgBXMMgmOAyvloXQ== X-Received: by 2002:a25:6d54:: with SMTP id i81mr18678516ybc.323.1583789944880; Mon, 09 Mar 2020 14:39:04 -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 l193sm15129152ywl.30.2020.03.09.14.39.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Mar 2020 14:39:04 -0700 (PDT) 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> <13b8faa9-74b1-6131-5dda-d4f34dfa8af0@gmail.com> From: Martin Sebor Message-ID: <77dc94af-40f1-46fd-f3f4-ceb7e3afc4b6@gmail.com> Date: Mon, 9 Mar 2020 15:39:03 -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: 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 21:39:06 -0000 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.  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? > > I think you're looking for most_general_template. I don't think that's quite what I'm looking for. At least it doesn't return the template or its specialization in all three cases above. In (2) and (3) it won't distinguish between specializations of B or C on different types. In (2), the function returns the same result for both: template <> struct B; template <> struct B; In (3), it similarly returns the same result for both of template struct C; template struct C; even though they are declarations of distinct types. What I missing? Martin