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 ESMTP id 7B4903851C10 for ; Fri, 25 Jun 2021 17:14:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7B4903851C10 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-168-7q8dXE8cPeiaWyuZyaIV6w-1; Fri, 25 Jun 2021 13:14:43 -0400 X-MC-Unique: 7q8dXE8cPeiaWyuZyaIV6w-1 Received: by mail-qv1-f71.google.com with SMTP id z6-20020a0cfec60000b0290263740e5b2aso10433117qvs.6 for ; Fri, 25 Jun 2021 10:14: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:from:date:to:cc:subject:in-reply-to:message-id :references:mime-version; bh=Ce3flSDreVtB/ae0FUaqXJNHCa8PageZdYZr4N1eqUw=; b=PcGuU55RLYM5YKhqwfXSjUJFi1lC2+wMxZvZmjhDw3nISauPRkl0QiRdcPZ+PTBzed WzKVS1LDQ6B3G5k2pDCDdSr3pfAYHBEphd3MOYl8lfZF/gPSW+Mf4jcqfextG5v4Ou4b cF1r+ag6h2na2vF4Y+vGNKj3sQItnAVwHQuwkISGED+YS3EnvHKl9VZaOaKAojeLCM8+ C3PdC2SjHERFRjtoNkeCLabxjJkMYBunAqbYvWnN1l7YwtU44eRZQhXqorsldTnOWFN4 dB119UTZ+SBQ7Gq5DBZZg8BoHWggmYZ6BcLYQ25SiaMVUl0OMXV5Ye8pjpbemeuHPPvq iqkw== X-Gm-Message-State: AOAM5332pYYcoWdV7vJuG1EoYWl/Ang07qGoSGDzfxA+xtoBmf5st7do 3NwbfwHkqC8PSKvzHniUpng0946MWzVhbdkHIv0UdvgRkftHaQeUDhqqSWnyM5LnCqCCvllBtz0 VGoPfieB77kyF9po8xg== X-Received: by 2002:a37:a6c8:: with SMTP id p191mr12369060qke.343.1624641282664; Fri, 25 Jun 2021 10:14:42 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyitV6ibdmrz9ymwcsn1FAIsDfMhvh1g3zTDoZ8H1hzIcmjA48O3lqOMfxygey6lSExG/zHBg== X-Received: by 2002:a37:a6c8:: with SMTP id p191mr12369046qke.343.1624641282449; Fri, 25 Jun 2021 10:14:42 -0700 (PDT) Received: from [192.168.1.130] (ool-457d493a.dyn.optonline.net. [69.125.73.58]) by smtp.gmail.com with ESMTPSA id m6sm3918235qtx.9.2021.06.25.10.14.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 25 Jun 2021 10:14:42 -0700 (PDT) From: Patrick Palka X-Google-Original-From: Patrick Palka Date: Fri, 25 Jun 2021 13:14:41 -0400 (EDT) To: Jason Merrill cc: Patrick Palka , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] c++: access scope during partial spec matching [PR96204] In-Reply-To: <6d414d65-3666-f17d-d5dc-1de7a9e4c929@redhat.com> Message-ID: <89c8e62c-fc79-8bf6-53e8-7865aa2af68c@idea> References: <20210625150352.913072-1-ppalka@redhat.com> <6d414d65-3666-f17d-d5dc-1de7a9e4c929@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-16.3 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_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham 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, 25 Jun 2021 17:14:46 -0000 On Fri, 25 Jun 2021, Jason Merrill wrote: > On 6/25/21 11:03 AM, Patrick Palka wrote: > > Here, when determining whether the partial specialization matches the > > specialization has_set_attr_method, we do so from the scope of > > where the template-id appears rather than from the scope of the > > specialization, and this causes us to select the partial specialization > > (since Child::type is accessible from Parent). When we later > > instantiate this partial specialization, we've entered the scope of the > > specialization and so substitution into e.g. the DECL_CONTEXT for > > 'value' yields access errors for Child::type since the friend > > declaration no longer applies. > > > > It seems the appropriate access scope from which to perform partial > > specialization matching is the specialization itself (similar to how > > we check access of base-clauses), which is what this patch implements. > > > There's implementation divergence however: Clang accepts both testcases > > below whereas MSVC and ICC reject both (indicating that Clang performs > > partial spec matching from the scope of the specialization and MSVC/ICC > > performs it from whatever scope the template-id appears). > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for > > trunk? > > > > PR c++/96204 > > > > gcc/cp/ChangeLog: > > > > * pt.c (instantiate_class_template_1): Enter the scope of the > > type before calling most_specialized_partial_spec. > > > > gcc/testsuite/ChangeLog: > > > > * g++.dg/template/access40.C: New test. > > * g++.dg/template/access40a.C: New test. > > --- > > gcc/cp/pt.c | 6 ++++- > > gcc/testsuite/g++.dg/template/access40.C | 30 +++++++++++++++++++++++ > > gcc/testsuite/g++.dg/template/access40a.C | 30 +++++++++++++++++++++++ > > 3 files changed, 65 insertions(+), 1 deletion(-) > > create mode 100644 gcc/testsuite/g++.dg/template/access40.C > > create mode 100644 gcc/testsuite/g++.dg/template/access40a.C > > > > diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c > > index f4e0abe5c1e..5107bfbf9d1 100644 > > --- a/gcc/cp/pt.c > > +++ b/gcc/cp/pt.c > > @@ -11774,8 +11774,12 @@ instantiate_class_template_1 (tree type) > > deferring_access_check_sentinel acs (dk_no_deferred); > > /* Determine what specialization of the original template to > > - instantiate. */ > > + instantiate; do this relative to the scope of the type. */ > > + push_access_scope (TYPE_NAME (type)); > > + pushclass (type); > > How about replacing these two calls with push_nested_class (type), like we use > later in the function? That works nicely. Would the patch be OK with that change? Bootstrapped and regtested on x86_64-pc-linux-gnu. > > > t = most_specialized_partial_spec (type, tf_warning_or_error); > > + popclass (); > > + pop_access_scope (TYPE_NAME (type)); > > if (t == error_mark_node) > > return error_mark_node; > > else if (t) > > diff --git a/gcc/testsuite/g++.dg/template/access40.C > > b/gcc/testsuite/g++.dg/template/access40.C > > new file mode 100644 > > index 00000000000..e0d30779377 > > --- /dev/null > > +++ b/gcc/testsuite/g++.dg/template/access40.C > > @@ -0,0 +1,30 @@ > > +// PR c++/96204 > > + > > +template struct bool_constant; > > + > > +template > > +struct has_type_member { > > + static const bool value = false; > > +}; > > + > > +template > > +struct has_type_member { > > + static const bool value = true; > > +}; > > + > > +struct Parent; > > + > > +struct Child { > > +private: > > + friend struct Parent; > > + typedef void type; > > +}; > > + > > +struct Parent { > > + static void f() { > > + // The partial specialization of has_type_member does not match > > + // despite Child::type being accessible from the current scope. > > + typedef bool_constant::value> type; > > + typedef bool_constant type; > > + } > > +}; > > diff --git a/gcc/testsuite/g++.dg/template/access40a.C > > b/gcc/testsuite/g++.dg/template/access40a.C > > new file mode 100644 > > index 00000000000..85138c9e570 > > --- /dev/null > > +++ b/gcc/testsuite/g++.dg/template/access40a.C > > @@ -0,0 +1,30 @@ > > +// PR c++/96204 > > + > > +template struct bool_constant; > > + > > +template > > +struct has_type_member { > > + static const bool value = false; > > +}; > > + > > +template > > +struct has_type_member { > > + static const bool value = true; > > +}; > > + > > +struct Parent; > > + > > +struct Child { > > +private: > > + friend struct has_type_member; > > + typedef void type; > > +}; > > + > > +struct Parent { > > + static void f() { > > + // The partial specialization matches because Child::type is > > + // accessible from has_type_member. > > + typedef bool_constant::value> type; > > + typedef bool_constant type; > > + } > > +}; > > > >