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 240B13858C60 for ; Thu, 1 Dec 2022 19:51:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 240B13858C60 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=1669924276; 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=6T87q8/Pe6t0BgZjS/5kVuGtZ9RG0c8SzLjkWeVj+O0=; b=HxqaA02xhPZAI9I3KrBT6x7RuLYz+BGHyBPY47U34SZIjHb9J0f+WyCOBFtLHW++za4id6 TplsaF+YORgYq3MJfglE7HbiEij+NfzrL8YEBiGJ/40LrSjTxYJmbFtVMAMFehOU2uUk6D ZKoK5CYWKuHyqJMU+RTk3zR6LsvzKFY= 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-410-1wdKDI11PNy-XbfG-rVH8A-1; Thu, 01 Dec 2022 14:51:15 -0500 X-MC-Unique: 1wdKDI11PNy-XbfG-rVH8A-1 Received: by mail-qv1-f71.google.com with SMTP id og17-20020a056214429100b004c6ae186493so7901834qvb.3 for ; Thu, 01 Dec 2022 11:51:15 -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=6T87q8/Pe6t0BgZjS/5kVuGtZ9RG0c8SzLjkWeVj+O0=; b=g6o2pc4ZXeS9VaOK4cU5HrevBDjV2EajaT2MQabHgx1jFBD94G/JMDPiiOME3t+x0n 0F2wvKm6daGSFqP8/AE01JCXQ2+FZwlpoU2qZlvRCNFOpek3pAzAsnJSt+zkjQj89dfp WIjsEH6buh4t7RMZslWbgtLDppg/XeJwghiX4V9BwPKuDXYlWfOA2ix2ecjgPE2oiHNh mWh67VcxrspAeqITzRjJgFbszOvwvBAlL2pVd86KNgna05EPFxiT6JOg93yqJNHUDmmQ ZdzORq2clonSCrVKqH4pEZSuwJvpciU7DBC6/+YnuLhj0cMyz+J7yJW/R8XegEj6t07v gXtg== X-Gm-Message-State: ANoB5pnRVGjQpg1k79JG3XBKHu7c/0YTT+F6F8hbeqYlC2MuWhjpP9hv BHb8N3TDpOZ8dojXvG9QAQz4QOVnb/2o92sFaDV7QjSVrbKjAupvn2dE/K35V7llwewDFw1Ky9t 6KHwboKdOqkqPAJEewA== X-Received: by 2002:a0c:8091:0:b0:4bb:b8ec:2bc7 with SMTP id 17-20020a0c8091000000b004bbb8ec2bc7mr46185059qvb.20.1669924275300; Thu, 01 Dec 2022 11:51:15 -0800 (PST) X-Google-Smtp-Source: AA0mqf6r30zMze9peKjuiV7UC0h3qy96ud5bBRjDtMGvSsrs+7LfYcOSruEnWdVmbnRNzOw90HdsAw== X-Received: by 2002:a0c:8091:0:b0:4bb:b8ec:2bc7 with SMTP id 17-20020a0c8091000000b004bbb8ec2bc7mr46185039qvb.20.1669924275038; Thu, 01 Dec 2022 11:51:15 -0800 (PST) Received: from [192.168.1.130] (ool-457670bb.dyn.optonline.net. [69.118.112.187]) by smtp.gmail.com with ESMTPSA id ay18-20020a05620a179200b006ef1a8f1b81sm4048665qkb.5.2022.12.01.11.51.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 Dec 2022 11:51:14 -0800 (PST) From: Patrick Palka X-Google-Original-From: Patrick Palka Date: Thu, 1 Dec 2022 14:51:13 -0500 (EST) To: Jason Merrill cc: Patrick Palka , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] c++: explicit spec of constrained member tmpl [PR107522] In-Reply-To: Message-ID: References: <20221201163752.2176490-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=-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, 1 Dec 2022, Jason Merrill wrote: > On 12/1/22 11:37, Patrick Palka wrote: > > When defining a explicit specialization of a constrained member template > > (of a class template) such as f and g in the below testcase, the > > DECL_TEMPLATE_PARMS of the corresponding TEMPLATE_DECL are partially > > instantiated, whereas its associated constraints are carried over > > from the original template and thus are in terms of the original > > DECL_TEMPLATE_PARMS. > > But why are they carried over? We wrote a specification of the constraints in > terms of the temprate parameters of the specialization, why are we throwing > that away? Using the partially instantiated constraints would require adding a special case to satisfaction since during satisfaction we currently always use the full set of template arguments (relative to the most general template). For satisfaction of the partiall instantiated constraints, we'd instead have to use the template arguments relative to the explicit specialization, e.g. {42} instead of {{int},{42}} for A::f<42>. Not sure if that would be preferable, but it seems doable. > > > So during normalization for such an explicit > > specialization we need to consider the (parameters of) the most general > > template, since that's what the constraints are in terms of and since we > > always use the full set of template arguments during satisfaction. > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for > > trunk and perhaps 12? > > > > PR c++/107522 > > > > gcc/cp/ChangeLog: > > > > * constraint.cc (get_normalized_constraints_from_decl): Use the > > most general template for an explicit specialization of a > > member template. > > > > gcc/testsuite/ChangeLog: > > > > * g++.dg/cpp2a/concepts-explicit-spec7.C: New test. > > --- > > gcc/cp/constraint.cc | 18 ++++++++--- > > .../g++.dg/cpp2a/concepts-explicit-spec7.C | 31 +++++++++++++++++++ > > 2 files changed, 44 insertions(+), 5 deletions(-) > > create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-explicit-spec7.C > > > > diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc > > index ab0f66b3d7e..f1df84c2a1c 100644 > > --- a/gcc/cp/constraint.cc > > +++ b/gcc/cp/constraint.cc > > @@ -973,11 +973,19 @@ get_normalized_constraints_from_decl (tree d, bool > > diag = false) > > accepting the latter causes the template parameter level of U > > to be reduced in a way that makes it overly difficult substitute > > concrete arguments (i.e., eventually {int, int} during satisfaction. > > */ > > - if (tmpl) > > - { > > - if (DECL_LANG_SPECIFIC(tmpl) && !DECL_TEMPLATE_SPECIALIZATION (tmpl)) > > - tmpl = most_general_template (tmpl); > > - } > > + if (tmpl && DECL_LANG_SPECIFIC (tmpl) > > + && (!DECL_TEMPLATE_SPECIALIZATION (tmpl) > > + /* DECL_TEMPLATE_SPECIALIZATION means we're dealing with either a > > + partial specialization or an explicit specialization of a member > > + template. In the former case all is well: the constraints are in > > + terms in TMPL's parameters. But in the latter case TMPL's > > + parameters are partially instantiated whereas its constraints > > + aren't, so we need to consider (the parameters of) the most > > + general template. The following test distinguishes between a > > + partial specialization and such an explicit specialization. */ > > + || (TMPL_PARMS_DEPTH (DECL_TEMPLATE_PARMS (tmpl)) > > + < TMPL_ARGS_DEPTH (DECL_TI_ARGS (tmpl))))) > > + tmpl = most_general_template (tmpl); > > d = tmpl ? tmpl : decl; > > diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-explicit-spec7.C > > b/gcc/testsuite/g++.dg/cpp2a/concepts-explicit-spec7.C > > new file mode 100644 > > index 00000000000..5b5a6df20ff > > --- /dev/null > > +++ b/gcc/testsuite/g++.dg/cpp2a/concepts-explicit-spec7.C > > @@ -0,0 +1,31 @@ > > +// PR c++/107522 > > +// { dg-do compile { target c++20 } } > > + > > +template > > +struct A > > +{ > > + template > > + static void f() requires (N == 42); > > + > > + template > > + struct B { > > + template > > + static void g() requires (T(N) == 42); > > + }; > > +}; > > + > > +template<> > > +template > > +void A::f() requires (N == 42) { } > > + > > +template<> > > +template<> > > +template > > +void A::B::g() requires (int(N) == 42) { } > > + > > +int main() { > > + A::f<42>(); > > + A::f<43>(); // { dg-error "no match" } > > + A::B::g<42>(); > > + A::B::g<43>(); // { dg-error "no match" } > > +} > >