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 82D8B389815E for ; Thu, 15 Dec 2022 19:04:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 82D8B389815E 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=1671131070; 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=hM2kBiLM5Ax3MvwH5mrinEwb8wO61kM/fM1QlEPvJzY=; b=CRbu69XjyItBrUUPSvsfWOU9Ouoe7t9QlD6syZABNKHubncFVXnuaEzk9MLqj7r8Huk6Jw aLGWpg9IQhiM+NUA2M+xNAH8fzYh9BqCxXYhqbtQg9NZsOH3KXxHRerRovZWHpve3W8uNc Q7TWDpy94xFq0H+NnxKWdzEho2tBbDo= Received: from mail-oo1-f69.google.com (mail-oo1-f69.google.com [209.85.161.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-447-OAzRPK9TPwmfaSf40H-AUQ-1; Thu, 15 Dec 2022 14:04:28 -0500 X-MC-Unique: OAzRPK9TPwmfaSf40H-AUQ-1 Received: by mail-oo1-f69.google.com with SMTP id g1-20020a4a9241000000b0049fd16671b4so79741ooh.14 for ; Thu, 15 Dec 2022 11:04:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=hM2kBiLM5Ax3MvwH5mrinEwb8wO61kM/fM1QlEPvJzY=; b=gfAnG2Jhmyde+fBPJcgtNcGvL0pQc/dteULvQ3ihXuLwK5P3OMGfcXn7gedW6H537T f4JucUxUw7642Q2kVu9k0HE5/N4oQNRg4xp+2iTL357ChhAVEP9T0Q4ZCf0A6ZsoTFmx 84uhk428IZ+g+oRq8woNbHf98Hbd1PA25Ti0jPvkbpFVTLyKZaMWeGpteyprVEInngqR Q1KDJjmziKyh/Bk9K0BBUipxsdrXp/o7xe36LGQFNs5fHdTzgShdGIDUHz3t5cWP39Xm uhQiXBgqul6qdWzn4iqV9D5+T7nbt53mVUOyGx/L0PGA+ZwrRfECkbpi85tgT1g/O1PD s9mg== X-Gm-Message-State: ANoB5pmmxq0MNyVGXYHMxkXcXuAsPJ5/eUsBJecRc+wIM/P6ZO3tJZLV L/PrW0hWFxkiJ423KryD4AImCaxWc52nRmmvBBBQQkffP4gaiPDpcwwM7+6cYHKotlkdqNhADuL Dxw+s3xeLUZC0AtvW2Q== X-Received: by 2002:a05:6358:178e:b0:dd:29bb:ee41 with SMTP id y14-20020a056358178e00b000dd29bbee41mr1262190rwm.31.1671131067031; Thu, 15 Dec 2022 11:04:27 -0800 (PST) X-Google-Smtp-Source: AA0mqf6Vt4PF0MMNIq2dR2EbpcL21Cq9n5BG8O/66in0egloZjHLFu0P0GwPTzYok9cfn75Sq3H59w== X-Received: by 2002:a05:6358:178e:b0:dd:29bb:ee41 with SMTP id y14-20020a056358178e00b000dd29bbee41mr1262126rwm.31.1671131064523; Thu, 15 Dec 2022 11:04:24 -0800 (PST) Received: from [192.168.1.130] (ool-457670bb.dyn.optonline.net. [69.118.112.187]) by smtp.gmail.com with ESMTPSA id t11-20020a05620a450b00b006eea4b5abcesm12917016qkp.89.2022.12.15.11.04.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Dec 2022 11:04:23 -0800 (PST) From: Patrick Palka X-Google-Original-From: Patrick Palka Date: Thu, 15 Dec 2022 14:04:23 -0500 (EST) To: Jason Merrill cc: Patrick Palka , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] c++: template friend with variadic constraints [PR108066] In-Reply-To: <0b5ba723-31cd-b12c-e3df-c25a1d074825@redhat.com> Message-ID: <2faaee96-6cc4-cff7-5cd5-bf3c1f5ce7b6@idea> References: <20221212172057.3527670-1-ppalka@redhat.com> <0b5ba723-31cd-b12c-e3df-c25a1d074825@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=-13.9 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 Thu, 15 Dec 2022, Jason Merrill wrote: > On 12/12/22 12:20, Patrick Palka wrote: > > When instantiating a constrained hidden template friend, we need to > > substitute into its constraints for sake of declaration matching. > > Hmm, we shouldn't need to do declaration matching when there's only a single > declaration. Oops, indeed. It looks like in this case we're not calling maybe_substitute_reqs_for during declaration matching, but rather from tsubst_friend_function and specifically for the non-trailing requirements: if (TREE_CODE (new_friend) == TEMPLATE_DECL) { DECL_UNINSTANTIATED_TEMPLATE_FRIEND_P (new_friend) = false; DECL_USE_TEMPLATE (DECL_TEMPLATE_RESULT (new_friend)) = 0; DECL_SAVED_TREE (DECL_TEMPLATE_RESULT (new_friend)) = DECL_SAVED_TREE (DECL_TEMPLATE_RESULT (decl)); /* Substitute TEMPLATE_PARMS_CONSTRAINTS so that parameter levels will match in decls_match. */ tree parms = DECL_TEMPLATE_PARMS (new_friend); tree treqs = TEMPLATE_PARMS_CONSTRAINTS (parms); treqs = maybe_substitute_reqs_for (treqs, new_friend); if (treqs != TEMPLATE_PARMS_CONSTRAINTS (parms)) { TEMPLATE_PARMS_CONSTRAINTS (parms) = treqs; /* As well as each TEMPLATE_PARM_CONSTRAINTS. */ tsubst_each_template_parm_constraints (parms, args, tf_warning_or_error); } } I'll adjust the commit message appropriately. > > > For > > this substitution we use a full argument vector whose outer levels > > correspond to the class's arguments and innermost level corresponds to > > the template's level-lowered generic arguments. > > > > But for A::f here, for which the relevant argument vector is > > {{int}, {Us...}}, this substitution triggers the assert in > > use_pack_expansion_extra_args_p since one argument is a pack expansion > > and the other isn't. > > > > And for A::f, for which the relevant argument vector is > > {{int, int}, {Us...}}, the use_pack_expansion_extra_args_p assert would > > also trigger but we first get a bogus "mismatched argument pack lengths" > > error from tsubst_pack_expansion. > > > > These might ultimately be bugs in tsubst_pack_expansion, but it seems > > we can work around them by tweaking the constraint substitution in > > maybe_substitute_reqs_for to only use the friend's outer arguments in > > the case of a template friend. > > Yes, this is how we normally substitute a member template during class > instantiation: with the class' template args, not its own. The assert seems > to be enforcing that. Ah, makes snese. > > > This should be otherwise equivalent to > > substituting using the full arguments, since the template's innermost > > arguments are just its generic arguments with level=1. > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for > > trunk/12? > > > > PR c++/108066 > > PR c++/108067 > > > > gcc/cp/ChangeLog: > > > > * constraint.cc (maybe_substitute_reqs_for): For a template > > friend, substitute using only its outer arguments. Remove > > dead uses_template_parms test. > > I don't see any removal? Oops, I reverted that change before posting the patch but forgot to adjust the ChangeLog as well. Removing the uses_template_parms test seems to be safe but it's not necessary to fix the bug. > > > gcc/testsuite/ChangeLog: > > > > * g++.dg/cpp2a/concepts-friend12.C: New test. > > --- > > gcc/cp/constraint.cc | 8 +++++++ > > .../g++.dg/cpp2a/concepts-friend12.C | 22 +++++++++++++++++++ > > 2 files changed, 30 insertions(+) > > create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-friend12.C > > > > diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc > > index d4cd92ec3b4..f9d1009c9fe 100644 > > --- a/gcc/cp/constraint.cc > > +++ b/gcc/cp/constraint.cc > > @@ -1352,6 +1352,14 @@ maybe_substitute_reqs_for (tree reqs, const_tree > > decl) > > tree tmpl = DECL_TI_TEMPLATE (decl); > > tree gargs = generic_targs_for (tmpl); > > processing_template_decl_sentinel s; > > + if (PRIMARY_TEMPLATE_P (tmpl)) > > + { > > + if (TEMPLATE_ARGS_DEPTH (gargs) == 1) > > + return reqs; > > + ++processing_template_decl; > > + gargs = copy_node (gargs); > > + --TREE_VEC_LENGTH (gargs); > > Maybe instead of messing with TEMPLATE_ARGS_DEPTH we want to grab the targs > for DECL_FRIEND_CONTEXT instead of decl itself? IIUC DECL_FRIEND_CONTEXT wouldn't give us the right args if the template friend is declared inside a partial specialization: template concept C = __is_same(T, U); template struct A; template struct A { template requires (__is_same(T, U)) friend void f() { }; }; template struct A; The DECL_FRIEND_CONTEXT of f is A, whose TYPE_TI_ARGS are {int*}, relative to the primary template instead of the partial specialization. So we'd wrongly end up substituting T=int* instead of T=int into f's TEMPLATE_PARMS_CONSTRAINTS. r12-6950-g76dc465aaf1b74 fixed a similar issue when substituting into class-scope deduction guides declared inside a partial specialization. > > > + } > > if (uses_template_parms (gargs)) > > ++processing_template_decl; > > reqs = tsubst_constraint (reqs, gargs, > > diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-friend12.C > > b/gcc/testsuite/g++.dg/cpp2a/concepts-friend12.C > > new file mode 100644 > > index 00000000000..95973842afb > > --- /dev/null > > +++ b/gcc/testsuite/g++.dg/cpp2a/concepts-friend12.C > > @@ -0,0 +1,22 @@ > > +// PR c++/108066 > > +// PR c++/108067 > > +// { dg-do compile { target c++20 } } > > + > > +template > > +concept C = __is_same(T, U); > > + > > +template > > +struct A { > > + template > > + requires (... && C) > > + friend void f(A, A) { } > > +}; > > + > > +int main() { > > + A x; > > + f(x, x); > > + A y; > > + f(y, y); > > + A z; > > + f(x, z); // { dg-error "no match" } > > +} > >