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 66F5C3858D28 for ; Fri, 3 Nov 2023 15:02:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 66F5C3858D28 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 66F5C3858D28 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=1699023770; cv=none; b=bCPfPmQSTMbbxwg/fldljR12WyJOEl+D9yD907VklM6WqJNkgKCaFLFJGdMYkdDfXxOx2FOJG175B/6z7aGl+J3CK4kRER4TwyWeLtxknxWIGcONCTT5CumcDoFw2iBNU1voIDOFkbuFfZ9VHzTj4d4Etwyw4qBKgeN3PiIOVG4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699023770; c=relaxed/simple; bh=FFMRpSu4ibG0twbiWdz8q5/4x1SE7xcTDmAkAtbDeF4=; h=DKIM-Signature:From:Date:To:Subject:Message-ID:MIME-Version; b=r4Q/UrjFLLXSEQJ6K4V/Wyg1MxoxiKzeaQiwK0JjSZipnxMtD93KFatZmeB1rniH/zjSi+aeKcTUGySomNrRFaoajDjqsDK/9t2+Wpp0winwegaL5aNcCjEjLXExSGfTtel50ndgulJ+MY9/5riZblJpyQjicfgY5G5KFKfo4PA= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1699023760; 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=g+ZhwdBQshovshp+lWDu7OxDjW3Lso3Ege5HES8nvqk=; b=EIAi88vPER2TjFerzeoYKkaFdYXtyNApQEOtuBPB3Svr9FbKCi9AoJ79rT03aw3sXnLX1P Z6NDVlFyJF018UwQYel9U6+kjzzdFRiDuHs3rCASPTs59GnGhgA7pbYVVxQGlvqY+fQbrr sVKA16zbEkPUG5vsBBG9xtfaV69eXHU= Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-629-g7NeMMuhN5qQ-XtjyRK4Fg-1; Fri, 03 Nov 2023 11:02:38 -0400 X-MC-Unique: g7NeMMuhN5qQ-XtjyRK4Fg-1 Received: by mail-qv1-f69.google.com with SMTP id 6a1803df08f44-66fa17e145aso22933796d6.0 for ; Fri, 03 Nov 2023 08:02:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699023758; x=1699628558; 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=g+ZhwdBQshovshp+lWDu7OxDjW3Lso3Ege5HES8nvqk=; b=fnN7ZC2NLfhhCApZ/6YEf+6+tgcuqs4X5q5jSi0aP0K3LRh2Eo8WueZGuvbp3TYJqG 6RKFJjsPMiWYEVG2+geH0/SCLRKF1fwZ7hmrs9GMcGnUWE3qtnQbg8IVJ3wGlnIrPHqD 45/eTf2n1aA2RZtBwT+gSFIRN8Fkj3MHpyvZtPlOBhow6C2adsaEjCLRoeUVtWWl8HTP 23Q8OCbAfqAXiiXU881JQ3nF9zN+7l3sp0tZBiGhw0udFKTO9mJi4GhCoaldaZZTAFTL 4x+Opbp+f+iK3PzC6wzXux8RH9zzgGjBP1RAKwK8bYW3PcAkS4iMJYHD6GinlVUSmobg 0/Pg== X-Gm-Message-State: AOJu0YwFNmY1289Sxl7l/LTsOpbdhhnQpcBDbSPHvdJu3/pY+ZyvznnV X6LRYVEWOp/IN2bGTucjyxmgMQ3LJodFzmLVNOLSBOt1bHADmECrn2i9bvHZ8TZGdWhgI9AMRm0 47KuQ7wUmeV6C4D+HEg== X-Received: by 2002:a05:6214:f25:b0:670:85e1:3902 with SMTP id iw5-20020a0562140f2500b0067085e13902mr22422153qvb.57.1699023758153; Fri, 03 Nov 2023 08:02:38 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHmFMVOVdlFZgODaqY54lRWFSE5HGnCYFwarpIQqJ3hrAj69udn0v5PPp4f0qAOzpLrr5NliQ== X-Received: by 2002:a05:6214:f25:b0:670:85e1:3902 with SMTP id iw5-20020a0562140f2500b0067085e13902mr22422126qvb.57.1699023757844; Fri, 03 Nov 2023 08:02:37 -0700 (PDT) Received: from [192.168.1.130] (ool-457670bb.dyn.optonline.net. [69.118.112.187]) by smtp.gmail.com with ESMTPSA id c10-20020a0cfb0a000000b0065af9d1203dsm806657qvp.121.2023.11.03.08.02.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Nov 2023 08:02:09 -0700 (PDT) From: Patrick Palka X-Google-Original-From: Patrick Palka Date: Fri, 3 Nov 2023 11:02:07 -0400 (EDT) To: Jason Merrill cc: Patrick Palka , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] c++: partial spec constraint checking context [PR105220] In-Reply-To: Message-ID: <6b8c0604-ec08-c7f5-29b3-4f3c9d35a91e@idea> References: <20220502185029.92137-1-ppalka@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=-14.0 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 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; > > > 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 > >