From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch [185.70.40.133]) by sourceware.org (Postfix) with ESMTPS id 3A7DF3858D32 for ; Fri, 24 Nov 2023 23:26:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3A7DF3858D32 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=protonmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=protonmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 3A7DF3858D32 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=185.70.40.133 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700868420; cv=none; b=AfhAVEKrommLcXgmtw0rDsCiN4fzRo66yxOhATWH43nV1oiAqdRCuOUd3HDfC62b4S/id07FXkeOByJjgB3QFUz7rnvo7+WCDXGeX+Vi6iRNuUoh2fN/uk5dS7PJUIzQAH3gwKuEEJHYc0xZM/YlMS2TM04o6vxdjTKA221zMvU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700868420; c=relaxed/simple; bh=goH/RQ8JmvqvHVz+XtGSmDGwAG6yCIAHx/WBnkNWhFc=; h=DKIM-Signature:Date:To:From:Subject:Message-ID:MIME-Version; b=GAwGa3uPRlI17CInb7IzWyekfunSXXEDpHr4Q9XFgVXpy1kRfMHUa0cfXADEPmhJpY9qkfJTPHEzhTUgZps0xMHYvkAjKQpcm1H71XylGrG6AZbHqbEYD3kFl8Cuykwebbp6pEfRXq1Ftd048Lo4IXP4SnJDX7xM9F/OFf2URBU= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1700868416; x=1701127616; bh=y1JiTq8Y12uKQk+9ac5j6V4vHz1IUKdrmWD//YMpH6c=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=VE8vAZF01IBMBGA4Gi6PFKqoQISbpBFIiHp3xtdSvYYARy8uhhwGZEwtG/1mfZ/JP pRAH9h/4T/2pUhfA3JO5wwbC33UFF2Ahn/xTh2Ib0vq7Oi7wiX1FZagSL5GwOBKxv0 bUFHetehYXLGX2wpCrMN85jTHMvXY+Atxtt9h1EOSnPBdV7iae5MpBfU+00k0YHEhJ keauxMRv7UZIduFxq+pt4GpXEa+uIhJJG4cJsF4I5yu456UBUpRgvSPQF7m526iFUg rDzy8mF3Pv1y2JH79O/WbI1Lpo0oPVoB0XvwamwYpcb9QR7kFe3MtoptsyVy8jdv6J Y+lC2VdwDXS9A== Date: Fri, 24 Nov 2023 23:26:45 +0000 To: waffl3x From: waffl3x Cc: Jason Merrill , "gcc-patches@gcc.gnu.org" Subject: Re: [PATCH v5 1/1] c++: Initial support for P0847R7 (Deducing This) [PR102609] Message-ID: In-Reply-To: References: <1MdaTybBd_o4uw-Gb23fYyd5GNz7qFqoSe_f5h90LY_BdzM2ge2qPSyCuiCLYoYcZSjmVv13fw1LmjQC_M2L8raS1fydY5pEJ_vwvv5Z-0k=@protonmail.com> <9OlK_2c3Punfm3w-wEHqyHGyKGG8Gr_K0BUnDOuC9Aazur4mWlAM5WuL1Ea0AMLvFLl6LKFVTs813yY0zA7m0_ji_R9qhE52G7MZXrVPfZE=@protonmail.com> Feedback-ID: 14591686:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS,TO_EQ_FM_DIRECT_MX,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: Okay within about half an hour today I think I've figured out what the main issue is for my problem. For the static lambda case, while I don't like the hack that's currently present, I reckon we just leave it as it is, as it works just fine right now. For my issue, I'm not totally sure how to tackle it, but here's what I've identified. build_memfn_type calls into build_method_type_directly and that takes the main variant of the passed in basetype and sets it as the TYPE_METHOD_BASETYPE. TYPE_METHOD_BASETYPE (t) =3D TYPE_MAIN_VARIANT (basetype); So naively just bypassing build_memfn_type is not going to work, I'm not totally sure how to solve this though. (Below) /* Fix the type of 'this'. */ fntype =3D build_memfn_type (fntype, type, type_memfn_quals (fntype), type_memfn_rqual (fntype)); Making tree nodes in general is something I'm not very familiar with, and struggled with every time I tried to read any of the code. So for now I'm going to hope that the next block (below) handles everything properly as far as creating a new node and substitution goes. tree inst =3D (oldtmpl ? tsubst_template_decl (oldtmpl, args, complain, fntype, tparms) : tsubst_function_decl (oldfn, args, complain, fntype)); And I'll just see if setting the decl_context of inst to type does the trick. I guess I forgot to elaborate that tsubst_function_decl uses the decl_context of t on the second, which ends up having template-info attached to it. As you might have been able to deduce from what I've said so far, I suspect that it's because I'm not setting it properly when the function_decl is substituted into. I don't really know where the right place to do that is though, or really why it's not happening already, so I'm just gonna poke around, try some things, and clean it up later if it's messy. That's my quick update, hopefully this gets me somewhere finally. Alex On Thursday, November 23rd, 2023 at 11:49 PM, waffl3x wrote: >=20 >=20 > > and this in tsubst_lambda_expr that assumes iobj: >=20 > > /* Fix the type of 'this'. */ > > fntype =3D build_memfn_type (fntype, type, > > type_memfn_quals (fntype), > > type_memfn_rqual (fntype)); >=20 >=20 > Unfortunately, putting a condition on this had some unforeseen > consequences. I've been working on this about 8 hours today and I'm a > little defeated after discovering this. >=20 > commit 39ade88fa1632c659c5c4ed065fa2b62d16a8670 > Author: Jason Merrill jason@redhat.com >=20 > Date: Tue Jan 24 15:29:35 2023 -0500 >=20 > c++: static lambda in template [PR108526] >=20 > tsubst_lambda_expr uses build_memfn_type to build a METHOD_TYPE for the n= ew > lamba op(). This is not what we want for a C++23 static op(), but since w= e > also use that METHOD_TYPE to communicate the closure type down to > tsubst_function_decl, let's wait and turn it back at that point. >=20 > PR c++/108526 >=20 > gcc/cp/ChangeLog: >=20 > gcc/cp/ChangeLog: >=20 > * pt.cc (tsubst_function_decl): Handle static lambda. >=20 > gcc/testsuite/ChangeLog: >=20 > * g++.dg/cpp23/static-operator-call5.C: New test. >=20 > diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc > index 2a4d03c5e47..51fc246ed71 100644 > --- a/gcc/cp/pt.cc > +++ b/gcc/cp/pt.cc > @@ -14306,6 +14306,11 @@ tsubst_function_decl (tree t, tree args, tsubst_= flags_t complain, > tree ctx =3D closure ? closure : DECL_CONTEXT (t); > bool member =3D ctx && TYPE_P (ctx); >=20 > + /* If this is a static lambda, remove the 'this' pointer added in > + tsubst_lambda_expr now that we know the closure type. */ > + if (lambda_fntype && DECL_STATIC_FUNCTION_P (t)) > + lambda_fntype =3D static_fn_type (lambda_fntype); > + >=20 > I discovered this when I decided to try a static lambda to see if that > would help me narrow down my current problem. I was shocked to find out > it exhibited the exact same ICE I was trying to fix. So I was going to > go undo my changes one by one to see what it was, thankfully this was > the first one I tried, I undid the condition I put on it, and the crash > was gone. >=20 > Anyway, this has been my whole day so far, I am going to have to look > deeper to decide how exactly I fix this because I don't think this hack > that is in place at the moment is the right way to do it. The first > idea that comes to mind is modifying the decl_context of the call > operator, but I'm really not sure. I'm just going to take a break, eat > some pizza, and come back to this hopefully less defeated. >=20 > Alex