From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id D40413858D33 for ; Wed, 1 Mar 2023 22:33:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D40413858D33 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1677710001; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=QtWSpj5JbN1MvXMsaw72KxuwgSBDZoC1NUXhMr0Yztk=; b=IzTpQ/mfDPUMoY+hI42a2xkbTTHSqtpMwoXpgYVPGWSAkYVB7JZvPUVYdy1ED3eUSXWhqN 85LTxaSYLEPnBbCjfLoEWob4khiHBZK7aYIs3l+WnAtI+P+DW4u4j6etVoJRXI+ri+NGnx QTeNnWlGMWxBOjV5JI0u6vtDLYSTGnw= Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-646-tAE4VrewO4am95Bli7jtog-1; Wed, 01 Mar 2023 17:33:20 -0500 X-MC-Unique: tAE4VrewO4am95Bli7jtog-1 Received: by mail-qv1-f71.google.com with SMTP id jy22-20020a0562142b5600b005710b856106so7922645qvb.0 for ; Wed, 01 Mar 2023 14:33:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=QtWSpj5JbN1MvXMsaw72KxuwgSBDZoC1NUXhMr0Yztk=; b=bo4RPEYEhpuRSQJ1ghpS0zcCoHcVDv/f9OSkUB57E/L3SoyRrNClvAWk6PG8txxCzZ 7ko3obE5p0IJ5yevie6yd/fMfY5E6dBYiwklmYc1BR0s1RXcfdXuLMAOVX/2tYP+LtfO FBOxaNXVLKcHz4pkIOfnitgEKkF/yzoilRNyXDreLX9f+9qQhxeUgkeA7MSdCRCoW7EA 30KNAc/qRp4Fe1rwsmXoxEmxRGZohgnqBM9ZZa5pdrvkflGOq70XDPDikVStADoIixKO Gc/mjmXwLEqRbZ2a5AZeurOgK8HJvOWE9mtK6ze8qGfQ5DV+n2DhUxWFLycvBGofzviB 8nig== X-Gm-Message-State: AO0yUKVdpQ1gTASPT5BuBtnP1qLOMFfWUQQxV9Jtjx05XIC7JBPmdwXZ JPWrH4afDnu/ecaRyoEd9ft4P7ewWZauJMH+PyxiPqG+cpb2IKc6g58EhJLgMzS1qPDkjc6RMuK 818fsXNj9H3owl3A6jB2giuE= X-Received: by 2002:a05:622a:1a92:b0:3bf:ca4f:9c4c with SMTP id s18-20020a05622a1a9200b003bfca4f9c4cmr14028519qtc.56.1677709999913; Wed, 01 Mar 2023 14:33:19 -0800 (PST) X-Google-Smtp-Source: AK7set+kM/u7++xvC2h6ampiLW5add95b4dTAFsGVX2pNsWNCHxRtla+TY79g0gVz/AGCXr2o4T/PA== X-Received: by 2002:a05:622a:1a92:b0:3bf:ca4f:9c4c with SMTP id s18-20020a05622a1a9200b003bfca4f9c4cmr14028491qtc.56.1677709999555; Wed, 01 Mar 2023 14:33:19 -0800 (PST) Received: from redhat.com (2603-7000-9500-34a5-0000-0000-0000-1db4.res6.spectrum.com. [2603:7000:9500:34a5::1db4]) by smtp.gmail.com with ESMTPSA id r191-20020a37a8c8000000b00729a26e836esm9624818qke.84.2023.03.01.14.33.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Mar 2023 14:33:19 -0800 (PST) Date: Wed, 1 Mar 2023 17:33:17 -0500 From: Marek Polacek To: Jason Merrill Cc: GCC Patches Subject: Re: [PATCH] c++: ICE with -Wmismatched-tags and member template [PR106259] Message-ID: References: <20230301203308.405645-1-polacek@redhat.com> <41623b13-6b28-45ba-5839-e46207090f5c@redhat.com> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/2.2.9 (2022-11-12) X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-12.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Wed, Mar 01, 2023 at 04:44:12PM -0500, Jason Merrill wrote: > On 3/1/23 16:40, Marek Polacek wrote: > > On Wed, Mar 01, 2023 at 04:30:16PM -0500, Jason Merrill wrote: > > > On 3/1/23 15:33, Marek Polacek wrote: > > > > -Wmismatched-tags warns about the (harmless) struct/class mismatch. > > > > For, e.g., > > > > > > > > template struct A { }; > > > > class A a; > > > > > > > > it works by adding A to the class2loc hash table while parsing the > > > > class-head and then, while parsing the elaborate type-specifier, we > > > > add A. At the end of c_parse_file we go through the table and > > > > warn about the class-key mismatches. In this PR we crash though; we > > > > have > > > > > > > > template struct A { > > > > template struct W { }; > > > > }; > > > > struct A::W w; // #1 > > > > > > > > where while parsing A and #1 we've stashed > > > > A > > > > A::W > > > > A::W > > > > into class2loc. Then in class_decl_loc_t::diag_mismatched_tags TYPE > > > > is A::W, and specialization_of gets us A::W, which > > > > is not in class2loc, so we crash on gcc_assert (cdlguide). But it's > > > > OK not to have found A::W, we should just look one "level" up, > > > > that is, A::W. > > > > > > > > It's important to handle class specializations, so e.g. > > > > > > > > template<> > > > > struct A { > > > > template > > > > class W { }; > > > > }; > > > > > > > > where W's class-key is different than in the primary template above, > > > > so we should warn depending on whether we're looking into A > > > > or into a different instantiation. > > > > > > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > > > > > PR c++/106259 > > > > > > > > gcc/cp/ChangeLog: > > > > > > > > * parser.cc (class_decl_loc_t::diag_mismatched_tags): If the first > > > > lookup of SPEC didn't find anything, try to look for > > > > most_general_template. > > > > > > > > gcc/testsuite/ChangeLog: > > > > > > > > * g++.dg/warn/Wmismatched-tags-11.C: New test. > > > > --- > > > > gcc/cp/parser.cc | 30 +++++++++++++++---- > > > > .../g++.dg/warn/Wmismatched-tags-11.C | 23 ++++++++++++++ > > > > 2 files changed, 47 insertions(+), 6 deletions(-) > > > > create mode 100644 gcc/testsuite/g++.dg/warn/Wmismatched-tags-11.C > > > > > > > > diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc > > > > index 1a124f5395e..b528ee7b1d9 100644 > > > > --- a/gcc/cp/parser.cc > > > > +++ b/gcc/cp/parser.cc > > > > @@ -34473,14 +34473,32 @@ class_decl_loc_t::diag_mismatched_tags (tree type_decl) > > > > be (and inevitably is) at index zero. */ > > > > tree spec = specialization_of (type); > > > > cdlguide = class2loc.get (spec); > > > > + /* It's possible that we didn't find SPEC. Consider: > > > > + > > > > + template struct A { > > > > + template struct W { }; > > > > + }; > > > > + struct A::W w; // #1 > > > > + > > > > + where while parsing A and #1 we've stashed > > > > + A > > > > + A::W > > > > + A::W > > > > + into CLASS2LOC. If TYPE is A::W, specialization_of > > > > + will yield A::W which may be in CLASS2LOC if we had > > > > + an A class specialization, but otherwise won't be in it. > > > > + So try to look up A::W. */ > > > > + if (!cdlguide) > > > > + { > > > > + spec = DECL_TEMPLATE_RESULT (most_general_template (spec)); > > > > > > Would it make sense to only look at most_general_template, not A::W > > > at all? > > > > I think that would break with class specialization, as in... > > > > > > +template struct A { > > > > + template > > > > + struct W { }; > > > > +}; > > > > + > > > > +template<> > > > > +struct A { > > > > + template > > > > + class W { }; > > > > +}; > > > > + > > > > +void > > > > +g () > > > > +{ > > > > + struct A::W w1; // { dg-warning "mismatched" } > > > > ...this, where we should first look into A, and only if not > > found, go to A. > > I'd expect the > > > /* Stop if we run into an explicitly specialized class template. */ > > code in most_general_template to avoid that problem. Ah, I had no idea it does that. The unconditional most_general_template works fine for the new test, but some of the existing tests then fail. Reduced: template struct S2; // #1 template class S2; // #2 extern class S2 s2ci; // #3 extern struct S2 s2ci; // { dg-warning "\\\[-Wmismatched-tags" } where the unconditional most_general_template changes spec from "class S2" to "struct S2" (both of which are in class2loc). So it regresses the diagnostic, complaining that #3 should have "struct" since #1 has "struct". I think we want to keep the current diagnostic, saying that the last line should have "class" since the specialization in line #2 has "class".