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.129.124]) by sourceware.org (Postfix) with ESMTPS id 9D47A3858D32 for ; Thu, 30 Nov 2023 15:42:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9D47A3858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 9D47A3858D32 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701358954; cv=none; b=s0bKpBNwBFMO0iZUJgVUY9UNP+Kbx4hDQ7b08MiQhqLJ0Y9XZpLn22SW9TDYRu9kH0JtQI+YwX+P1A4n/ugHPN90HK+spYFFcPnw74EauhNLrm23ibOImStkT+Lo+qu5pXgH3Yqapmw8CYeJr9z7MsA433BXUKwIaLwDuX7XD/s= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701358954; c=relaxed/simple; bh=bldErydk5tI76jQBUDRDo5XSVxm0JsXFZ4cQVINPn1k=; h=DKIM-Signature:From:Date:To:Subject:Message-ID:MIME-Version; b=HpRM4lPYedYvGoQnbsrNKNZWow0kU7Q3YSBEnOrU9fz7HLoXU1+MlnYY5Uwo9ZklAk8tBwd8YguOPUsAao9nsdmMw9OEU3t7hbp2aLXhVcTQ0vMO8pYGxtChMf2gQWgx6w1M3V5ppTeyvKEvtcu38JLjKyydzn2IJ4zmtYO4+L8= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1701358952; 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=FtnPea7E8JYCAI6e2jEBvo7WHa2yFSLbXMaKwXurTVE=; b=EGZWHLE1s2NOV3l3uSWT15wvS/MRIL/P7JucJNwHgJjZkrA6man4t9tqMPgIMWsvouMTDp 1QSFT9TpbfetZxK9QV5fZPHulgPmMPp2u7ZJsC9rW4IF8flFAb1CxkNx0PV2S5+QtPf4ty TDdKC/XVGdGki8uDqVR63OVVY2qLUxY= Received: from mail-yw1-f199.google.com (mail-yw1-f199.google.com [209.85.128.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-97-5OjUZOUUO5iUBUSOAOOy5Q-1; Thu, 30 Nov 2023 10:42:29 -0500 X-MC-Unique: 5OjUZOUUO5iUBUSOAOOy5Q-1 Received: by mail-yw1-f199.google.com with SMTP id 00721157ae682-5d379f92d70so9154317b3.1 for ; Thu, 30 Nov 2023 07:42:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701358949; x=1701963749; h=mime-version:references:message-id:in-reply-to:subject:cc:to:date :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=FtnPea7E8JYCAI6e2jEBvo7WHa2yFSLbXMaKwXurTVE=; b=PMoN9hzpmjvURv34tc6tQjamWQ7aLk/N3hM32T8Z8krsHGr9fYPP6/RYfptF9eaAB/ OMA3iKRZNrwPzecCxqRJy/TjeuiDvA4wqIQA2RDHUPpczAPq4pGaEGKiAEHc9V4KXAsI sinBNkz8Va5/Rw2Qs6yidog4hUEa0LE4dTs/2GPgp3GNKZwbsqdjJTPtjeyimUwgpLtu /4SCsPZ+Le1U9xijKSRIRuC7iS8Xr4g4iL/H4JAGiVcUtgUJSRUH94WcWGtm0V6IRAzA eAYA0WugFgrpZkJyAsnXJBpdufOpVPg0Ha9arjnoEPw86QzGHD1MhuoRSX0F/+Lv1jJo 8b+Q== X-Gm-Message-State: AOJu0YwLYcPxB3Ln+/Fe1PDrsrNApRj2S1ibe6TtQZ9lg44aZG9PkmQY PTJE+jUxTr/Nq6l87gsU7lLum52EqF6yuh+No4raQ3K62ihosSgIaFXIYmQR7oahuL429hhOkTj QtzWgVLTOMLrArTMAnw== X-Received: by 2002:a05:690c:fd5:b0:5d3:3d0e:c607 with SMTP id dg21-20020a05690c0fd500b005d33d0ec607mr2603686ywb.20.1701358948922; Thu, 30 Nov 2023 07:42:28 -0800 (PST) X-Google-Smtp-Source: AGHT+IE773ZWEa18dryoDfjn9OwziVhXhjXpBIhEsoCXpq3knZSwr+0fd8QBLJ5BivIWXmyNFSbxYA== X-Received: by 2002:a05:690c:fd5:b0:5d3:3d0e:c607 with SMTP id dg21-20020a05690c0fd500b005d33d0ec607mr2603665ywb.20.1701358948654; Thu, 30 Nov 2023 07:42:28 -0800 (PST) Received: from [192.168.1.130] (ool-457670bb.dyn.optonline.net. [69.118.112.187]) by smtp.gmail.com with ESMTPSA id p2-20020a0ccb82000000b0067a60a68810sm595284qvk.80.2023.11.30.07.42.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 Nov 2023 07:42:28 -0800 (PST) From: Patrick Palka X-Google-Original-From: Patrick Palka Date: Thu, 30 Nov 2023 10:42:27 -0500 (EST) To: Patrick Palka cc: Jason Merrill , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] c++: partial spec constraint checking context [PR105220] In-Reply-To: <6b8c0604-ec08-c7f5-29b3-4f3c9d35a91e@idea> Message-ID: <538b1c8e-faab-d4b4-f0b8-9715fd8af8c4@idea> References: <20220502185029.92137-1-ppalka@redhat.com> <6b8c0604-ec08-c7f5-29b3-4f3c9d35a91e@idea> 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=-13.8 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_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE 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 Fri, 3 Nov 2023, Patrick Palka wrote: > On Tue, 3 May 2022, Jason Merrill wrote: > > > On 5/2/22 14:50, Patrick Palka wrote: > > > Currently when checking the constraints of a class template, we do so in > > > the context of the template, not the specialized type. This is the best > > > we can do for a primary template since the specialized type is valid > > > only if the primary template's constraints are satisfied. > > > > Hmm, that's unfortunate. It ought to be possible, if awkward, to form the > > type long enough to check its constraints. > > (Sorry, lost track of this patch...) > > Seems doable, but I'm not sure if would make any difference in practice? > > If the access context during satisfaction of a primary class template's > constraints is the specialization rather than the primary template, > then that should only make a difference if there's some friend declaration > naming the specialization. But that'd mean the specialization's > constraints had to have been satisfied at that point, before the friend > declaration went into effect. So either the constraints don't depend on > the access granted by the friend declaration anyway, or they do and the > program is ill-formed (due to either satifaction failure or instability) IIUC. > > For example, I don't think an adapted version of the testcase without a > partial specialization is valid, regardless of whether the access context > during satisfaction of A is A or just A: > > template > concept fooable = requires(T t) { t.foo(); }; > > template > struct A { }; > > struct B { > private: > friend struct A; // satisfaction failure at this point > void foo(); > }; > > template struct A; ... so in light of the above, I wonder if the original patch can go in as-is? > > > > > > > But for a > > > partial specialization, we can assume the specialized type is valid (as > > > a consequence of constraints being checked only when necessary), so we > > > arguably should check the constraints on a partial specialization more > > > specifically in the context of the specialized type, not the template. > > > > > > This patch implements this by substituting and setting the access > > > context appropriately in satisfy_declaration_constraints. Note that > > > setting the access context in this case is somewhat redundant since the > > > relevant caller most_specialized_partial_spec will already have set the > > > access context to the specialiation, but this redundancy should be harmless. > > > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for > > > trunk and perhaps 12.2 (after the branch is thawed)? > > > > > > PR c++/105220 > > > > > > gcc/cp/ChangeLog: > > > > > > * constraint.cc (satisfy_declaration_constraints): When checking > > > the constraints of a partial template specialization, do so in > > > the context of the specialized type not the template. > > > > > > gcc/testsuite/ChangeLog: > > > > > > * g++.dg/cpp2a/concepts-partial-spec12.C: New test. > > > --- > > > gcc/cp/constraint.cc | 17 ++++++++++++++--- > > > .../g++.dg/cpp2a/concepts-partial-spec12.C | 19 +++++++++++++++++++ > > > 2 files changed, 33 insertions(+), 3 deletions(-) > > > create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-partial-spec12.C > > > > > > diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc > > > index 94f6222b436..772f8532b47 100644 > > > --- a/gcc/cp/constraint.cc > > > +++ b/gcc/cp/constraint.cc > > > @@ -3253,11 +3253,22 @@ satisfy_declaration_constraints (tree t, tree args, > > > sat_info info) > > > { > > > if (!push_tinst_level (t, args)) > > > return result; > > > - tree pattern = DECL_TEMPLATE_RESULT (t); > > > + tree ascope = DECL_TEMPLATE_RESULT (t); > > > + if (CLASS_TYPE_P (TREE_TYPE (t)) > > > + && CLASSTYPE_TEMPLATE_SPECIALIZATION (TREE_TYPE (t))) > > > + { > > > + gcc_checking_assert (t == most_general_template (t)); > > > + /* When checking the constraints on a partial specialization, > > > + do so in the context of the specialized type, not the template. > > > + This substitution should always succeed since we shouldn't > > > + be checking constraints thereof unless the specialized type > > > + is valid. */ > > > + ascope = tsubst (ascope, args, tf_none, info.in_decl); > > > + } > > > push_to_top_level (); > > > - push_access_scope (pattern); > > > + push_access_scope (ascope); > > > result = satisfy_normalized_constraints (norm, args, info); > > > - pop_access_scope (pattern); > > > + pop_access_scope (ascope); > > > pop_from_top_level (); > > > pop_tinst_level (); > > > } > > > diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-partial-spec12.C > > > b/gcc/testsuite/g++.dg/cpp2a/concepts-partial-spec12.C > > > new file mode 100644 > > > index 00000000000..641d456722d > > > --- /dev/null > > > +++ b/gcc/testsuite/g++.dg/cpp2a/concepts-partial-spec12.C > > > @@ -0,0 +1,19 @@ > > > +// PR c++/105220 > > > +// { dg-do compile { target c++20 } } > > > + > > > +template > > > +concept fooable = requires(T t) { t.foo(); }; > > > + > > > +template > > > +struct A; // #1, incomplete > > > + > > > +template > > > +struct A { }; // #2 > > > + > > > +struct B { > > > +private: > > > + friend struct A; > > > + void foo(); > > > +}; > > > + > > > +template struct A; // OK, B::foo() is accessible from #2 > > > > >