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 8742C3858D38 for ; Fri, 12 Apr 2024 13:53:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8742C3858D38 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 8742C3858D38 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712929983; cv=none; b=nUTPulgoRUFKAzcDMvcFT7tRxjJV9z69JxQN0nlc7s/VHZ0O+1j3PZxBlAzv5B/2zhd2jt29O3XN5SqKgRHlZatW273TnPB2oKZr6CH19rkUtUNy9SwHu57t3oO2YzI/HR2OJc8Dk+2WFDMIYt0ZreQPKXGO8VrihIDjPPTAgUE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712929983; c=relaxed/simple; bh=nzsDW645qBGHjb6X2PAjYZHRrNhgw/Dll+73qjdxvhg=; h=DKIM-Signature:From:Date:To:Subject:Message-ID:MIME-Version; b=o1GQjGKA+Gv93JZBiXGX8/e2qe+XTZ6VPxKG0zAnOIWmWNXpUaw9dnuvhhPA5fsysWgY9G9H0e4wmhkcfFt35AGQr9Q/AZSA8ZUTN1ojPDDwDpg4QQI0JfJTxDaP9uk+UArY+pVPuv1UxIvXngmvBtKEyY/c8NHqTTxs/AbK0T4= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1712929981; 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=+AA2ql7HPwFL59h4lbTGd6cucelfLcJJyAyk2k4L7ok=; b=iNU25Lce8g1ln3Zj5QeSWWSYBtU2twHeaJMnDFDFCCBKXd6cjwu+k26WRPqCsTq16tzGf+ id1mqBx9QzuI3H9l/u7Hi2dDrnUBM56I2iaQQjb8vEP/wAf/mb/LOPfC5a2wKwnICeZakf 9xnxtS+mX37DTNfnXdP9PKs2TatOc10= 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-264-GIRlanuVOyG8C6PZIeUIXA-1; Fri, 12 Apr 2024 09:52:59 -0400 X-MC-Unique: GIRlanuVOyG8C6PZIeUIXA-1 Received: by mail-yw1-f199.google.com with SMTP id 00721157ae682-615110c3472so16957107b3.3 for ; Fri, 12 Apr 2024 06:52:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712929979; x=1713534779; 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=+AA2ql7HPwFL59h4lbTGd6cucelfLcJJyAyk2k4L7ok=; b=kvxi/aMNbblk3Ffp6uryBhQ2Xm0ZTsE+0FNqlsoGM4aHMvRDmbXqabhU/w9GuDDTE2 /swqP6tJw1zAHGdj9Q6uqlMKLXQQSh+VvMuNsR39NCuXfdeXlCW1+6r8BVx9uy0hvRjo wUsPiALPkuP2nfwZIGBL6rCJiYLRNWdz7DcQU6p2EC3ueH4NNeLVAIAGmAcZralGooZt oMuUu4imC5LRlO9dy/eSUh4ae8Rh0oaFoqvwdPXqw7qMuSNW9y2lnj9U95Z+T6pZ/V3R C7f88hVHZTYN0jxhy6ZmCzIx7Zq/cLX0x2Ku4Hp1mpJvcmsKzbmVx9sJcInTB47O1H2O 3CUw== X-Forwarded-Encrypted: i=1; AJvYcCWu1WAC/qkAgDtRLwG+0scyqwrSq9vVwYcqVE+J8jr4KabjpLZnYsFf2EJvi0XLzHJbMtz4GFB80IEoMGrqFhAbZBrIX1tY4g== X-Gm-Message-State: AOJu0YyeD9eur9cHcl2Jo8CfORIV+NakAjH80jVQVASLp/VkmuPQMKhY 8ZFva61CelhyIQUYX1tuCPP63oOFhdRtVV0vQmKEvkmaksM9bF3aNNPuLxAFYeN6N0lfYNA9vvt WAAHmPlI9wPpc8ap8uMuhCx0WuwjRwTunwuwnpYPGFJem8a+SZS4VDGc= X-Received: by 2002:a0d:d80e:0:b0:617:c521:eeb0 with SMTP id a14-20020a0dd80e000000b00617c521eeb0mr2533348ywe.27.1712929979026; Fri, 12 Apr 2024 06:52:59 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEZBceZ5hglCg/oQ6QE0+kU1loKx+jKhbnZbNM2GO1OADnvCtbu2fn2u7K6WJbxKwBVyPjd4A== X-Received: by 2002:a0d:d80e:0:b0:617:c521:eeb0 with SMTP id a14-20020a0dd80e000000b00617c521eeb0mr2533333ywe.27.1712929978584; Fri, 12 Apr 2024 06:52:58 -0700 (PDT) Received: from [192.168.1.130] (ool-457670bb.dyn.optonline.net. [69.118.112.187]) by smtp.gmail.com with ESMTPSA id i9-20020a05620a404900b0078d6c0cd0b6sm2410872qko.85.2024.04.12.06.52.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Apr 2024 06:52:58 -0700 (PDT) From: Patrick Palka X-Google-Original-From: Patrick Palka Date: Fri, 12 Apr 2024 09:52:57 -0400 (EDT) To: Jason Merrill cc: Patrick Palka , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] c++: templated substitution into lambda-expr [PR114393] In-Reply-To: <5f5551e7-6c93-4516-8281-376fc202e9e9@redhat.com> Message-ID: <8a9ab31e-d7e1-a03c-f65b-a78d68daca20@idea> References: <20240325204448.340940-1-ppalka@redhat.com> <5d1bdce4-91e7-7a80-8459-228bb0b65809@idea> <080968c1-af41-3597-f980-667f41ac98a2@idea> <5f5551e7-6c93-4516-8281-376fc202e9e9@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.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,KAM_SHORT,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,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 Wed, 10 Apr 2024, Jason Merrill wrote: > On 3/27/24 10:01, Patrick Palka wrote: > > On Mon, 25 Mar 2024, Patrick Palka wrote: > > > On Mon, 25 Mar 2024, Patrick Palka wrote: > > > > > > > > The below testcases use a lambda-expr as a template argument and they > > > > all trip over the below added tsubst_lambda_expr sanity check ultimately > > > > because current_template_parms is empty, which causes push_template_decl > > > > to return error_mark_node from the call to begin_lambda_type. Were it > > > > not for the sanity check this silent error_mark_node result leads to > > > > nonsensical errors down the line, or silent breakage. > > > > > > > > In the first testcase, we hit this assert during instantiation of the > > > > dependent alias template-id c1_t<_Data> from instantiate_template, which > > > > clears current_template_parms via push_to_top_level. Similar story for > > > > the second testcase. For the third testcase we hit the assert during > > > > partial instantiation of the member template from > > > > instantiate_class_template > > > > which similarly calls push_to_top_level. > > > > > > > > These testcases illustrate that templated substitution into a > > > > lambda-expr > > > > is not always possible, in particular when we lost the relevant template > > > > context. I experimented with recovering the template context by making > > > > tsubst_lambda_expr fall back to using scope_chain->prev->template_parms > > > > if > > > > current_template_parms is empty which worked but seemed like a hack. I > > > > also experimented with preserving the template context by keeping > > > > current_template_parms set during instantiate_template for a dependent > > > > specialization which also worked but it's at odds with the fact that we > > > > cache dependent specializations (and so they should be independent of > > > > the template context). > > I suspect the problem comes from this bit in type_unification_real: > > > /* First instatiate in template context, in case we still > > depend on undeduced template parameters. */ > > ++processing_template_decl; > > substed = tsubst_template_arg (arg, full_targs, complain, > > NULL_TREE); > > --processing_template_decl; > > if (substed != error_mark_node > > && !uses_template_parms (substed)) > > /* We replaced all the tparms, substitute again out of > > template context. */ > > substed = NULL_TREE; > > and perhaps we should switch to searching the argument for undeduced template > parameters rather than doing a trial substitution. Interesting, you also mentioned that approach would help fix PR101463 (which I need to get back to): https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642340.html > > But the pattern of setting processing_template_decl, substituting, and > clearing it again is very widespread, so we still want to handle lambdas in > that context. > > > > > + if (processing_template_decl && !in_template_context) > > > > + { > > > > + /* Defer templated substitution into a lambda-expr when arguments > > > > + are dependent or when we lost the necessary template context, > > > > + which may happen for a lambda-expr used as a template argument. */ > > > > > > And this comment is stale (an earlier version of the patch also deferred > > > for dependent arguments even when current_template_parms is non-empty, > > > which I backed out to make the fix as narrow as possible). > > > > FWIW I also experimented with unconditionally deferring templated > > substitution into a lambda-expr (i.e. iff processing_template_decl) > > which passed bootstrap+regtest, and turns out to also fix the > > (non-regression) PR114167. I didn't analyze the underlying issue > > very closely though, there might very well be a better way to fix > > that particular non-regression PR. > > > > One downside of unconditionally deferring is that it'd mean less > > ahead-of-time checking of uninvoked deeply-nested generic lambdas, > > e.g.: > > > > int main() { > > [](auto x) { > > [](auto) { > > [](auto) { decltype(x)::fail; }; // not diagnosed anymore > > }; > > }(0); > > } > > Hmm, unconditionally deferring would probably also help to resolve issues with > local classes in generic lambdas. It might be worth going that way rather > than continue to grapple with partial substitution problems. > > > > diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc > > > index 8cf0d5b7a8d..c25bdd283f1 100644 > > > --- a/gcc/cp/pt.cc > > > +++ b/gcc/cp/pt.cc > > > @@ -19571,6 +19572,18 @@ tsubst_lambda_expr (tree t, tree args, > > > tsubst_flags_t complain, tree in_decl) > > > tree oldfn = lambda_function (t); > > > in_decl = oldfn; > > > + args = add_extra_args (LAMBDA_EXPR_EXTRA_ARGS (t), args, complain, > > > in_decl); > > > + if (processing_template_decl && !in_template_context) > > > + { > > > + /* Defer templated substitution into a lambda-expr when we lost the > > > + necessary template context, which may happen for a lambda-expr > > > + used as a template argument. */ > > as a *default* template argument. OK with that tweak. Thanks a lot, pushed as r14-9938-g081c1e93d56d35. Unfortunately this isn't enough to fix the original testcase from the PR due a related but distinct return type confusion issue. It ultimately seems we need to defer substitution in more cases, not just when we don't have a template context. I submitted a follow-up patch at https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649387.html The patch makes us defer for all dependent substitution. Unconditionally deferring would do the trick as well, but I reckon a narrower fix might be better at this point. > > Jason > >