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 B6E1A3850232 for ; Thu, 20 Oct 2022 16:21:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B6E1A3850232 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=1666282905; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=H+30zP+gKF27wo6sMSPjxsRp0jD5YA8+HwifznCKWDw=; b=c9hwn5pD65tTVqQhlW7fH/37e95rvxUvKke/PC5fZbCD+gxrOMSqGV4hYcPHimxSn5ybn7 mFVjv3Y3UN9zElAMgTAl2zBycTsDI7mfmIpxEF+BNiWYbHqitRm7OABjHo5pmDDstrGU4g Z7aCOW3xDOEel/Ed2L4TiFASIpf4DeY= Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-260-s6QCqNSiOdum3RlNgohVZA-1; Thu, 20 Oct 2022 12:21:44 -0400 X-MC-Unique: s6QCqNSiOdum3RlNgohVZA-1 Received: by mail-qk1-f199.google.com with SMTP id x16-20020a05620a449000b006eecf2d621eso273430qkp.16 for ; Thu, 20 Oct 2022 09:21:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=H+30zP+gKF27wo6sMSPjxsRp0jD5YA8+HwifznCKWDw=; b=LmVpHmGgaD6gUjyDzfBVf5/K/3wy0UxTJEjpzMp9KBXvr5n8YYIyrkeiG23YxQ6pVB EudBTf+5lE+y2ReCNYRXprYdhBn0sRkW+2EfIsp6Ni9AxPpUV9PKeKTkJ/2TvlhY4cGU ya6S2KcPP7jJ9KZMKS4LAlPKyEX1G34lVFQAljd8SwiKuQyKnc2AlRhe/KBijvpI0AKJ dIM9tsMG/irQstjTuftsNOVloeetSc6IJvVdtd9o1bfLHUTh2gH4ZuMUQc6R8vOezMQk ywYomH3X3gSD/TE4SziyJhG8L6kBe+O5S4iEvu7qxxNgyeuJ41t45IBGJKh9rB/pU/px /2Qg== X-Gm-Message-State: ACrzQf0q+6p36qUA//JPCXRBdcX6woUkMYkh+ShtTuj+BvCYFzbbSvv5 IAx3wgs1UkvF9w0M5j9iwRyl8MkcXnwT3KidrDO7kDhdophNoToQiYeXnwbMsjAW9o1FRJHNXy2 cyrrSFM6S+XvWYuEnVg== X-Received: by 2002:a05:620a:1452:b0:6ec:3f82:522b with SMTP id i18-20020a05620a145200b006ec3f82522bmr9718869qkl.402.1666282903581; Thu, 20 Oct 2022 09:21:43 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4y46badeTPKMMpjv7DypTwiMeMooxe6p1BF3T/e6KOQHRFyjjmZWYD7sbqu33N7MaZwSAXRw== X-Received: by 2002:a05:620a:1452:b0:6ec:3f82:522b with SMTP id i18-20020a05620a145200b006ec3f82522bmr9718852qkl.402.1666282903272; Thu, 20 Oct 2022 09:21:43 -0700 (PDT) Received: from [192.168.1.101] (130-44-159-43.s15913.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [130.44.159.43]) by smtp.gmail.com with ESMTPSA id y5-20020a05620a44c500b006b5e296452csm7958162qkp.54.2022.10.20.09.21.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 20 Oct 2022 09:21:42 -0700 (PDT) Message-ID: Date: Thu, 20 Oct 2022 12:21:41 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.2 Subject: Re: [PATCH] c++: constraint matching, TEMPLATE_ID_EXPR, current inst To: Patrick Palka Cc: gcc-patches@gcc.gnu.org References: <20220915155822.4021344-1-ppalka@redhat.com> <549844d1-be60-592b-5e2b-1e4071f6a7f8@redhat.com> <8abd55bf-7f1e-5ab5-895e-a3f42631ec56@idea> From: Jason Merrill In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-12.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,NICE_REPLY_A,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 9/17/22 10:31, Patrick Palka wrote: > On Sat, 17 Sep 2022, Jason Merrill wrote: > >> On 9/16/22 10:59, Patrick Palka wrote: >>> On Fri, 16 Sep 2022, Jason Merrill wrote: >>> >>>> On 9/15/22 11:58, Patrick Palka wrote: >>>>> Here we're crashing during constraint matching for the instantiated >>>>> hidden friends due to two issues with dependent substitution into a >>>>> TEMPLATE_ID_EXPR naming a template from the current instantiation >>>>> (as performed from maybe_substitute_reqs_for for C<3> with T=T): >>>>> >>>>> * tsubst_copy substitutes into such a TEMPLATE_DECL by looking it >>>>> up from the substituted class scope. But for this to not fail >>>>> when >>>>> the args are dependent, we need to pass entering_scope=true for >>>>> the >>>>> class scope substitution so that we obtain the primary template >>>>> type >>>>> A (which has TYPE_BINFO) instead of the implicit instantiation >>>>> A (which doesn't). >>>>> * lookup_and_finish_template_variable shouldn't instantiate a >>>>> TEMPLATE_ID_EXPR that names a TEMPLATE_DECL which has more than >>>>> one level of (unsubstituted) parameters (such as A::C). >>>>> >>>>> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for >>>>> trunk? >>>>> >>>>> gcc/cp/ChangeLog: >>>>> >>>>> * pt.cc (lookup_and_finish_template_variable): Don't >>>>> instantiate if the template's scope is dependent. >>>>> (tsubst_copy) : Pass entering_scope=true >>>>> when substituting the class scope. >>>>> >>>>> gcc/testsuite/ChangeLog: >>>>> >>>>> * g++.dg/cpp2a/concepts-friend10.C: New test. >>>>> --- >>>>> gcc/cp/pt.cc | 14 +++++++------ >>>>> .../g++.dg/cpp2a/concepts-friend10.C | 21 >>>>> +++++++++++++++++++ >>>>> 2 files changed, 29 insertions(+), 6 deletions(-) >>>>> create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-friend10.C >>>>> >>>>> diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc >>>>> index db4e808adec..bfcbe0b8670 100644 >>>>> --- a/gcc/cp/pt.cc >>>>> +++ b/gcc/cp/pt.cc >>>>> @@ -10475,14 +10475,15 @@ tree >>>>> lookup_and_finish_template_variable (tree templ, tree targs, >>>>> tsubst_flags_t complain) >>>>> { >>>>> - templ = lookup_template_variable (templ, targs); >>>>> - if (!any_dependent_template_arguments_p (targs)) >>>>> + tree var = lookup_template_variable (templ, targs); >>>>> + if (TMPL_PARMS_DEPTH (DECL_TEMPLATE_PARMS (templ)) == 1 >>>>> + && !any_dependent_template_arguments_p (targs)) >>>> >>>> I notice that finish_id_expression_1 uses the equivalent of >>>> type_dependent_expression_p (var). Does that work here? >>> >>> Hmm, it does, but kind of by accident: type_dependent_expression_p >>> returns true for all variable TEMPLATE_ID_EXPRs because of their empty >>> TREE_TYPE (as set by finish_template_variable). So testing t_d_e_p here >>> is equivalent to testing processing_template_decl, it seems -- maximally >>> conservative. >>> >>> We can improve type_dependent_expression_p for variable TEMPLATE_ID_EXPR >>> by ignoring its (always empty) TREE_TYPE and just considering dependence >>> of its template and args directly. I guess the problem is that a variable template specialization is type-dependent until it's instantiated or specialized, and here we're trying to instantiate if that hasn't happened yet, so using type_dependent_expression_p would be wrong. The patch is OK as is. Jason