From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-40131.protonmail.ch (mail-40131.protonmail.ch [185.70.40.131]) by sourceware.org (Postfix) with ESMTPS id 75E013858D32 for ; Sat, 25 Nov 2023 01:15:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 75E013858D32 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 75E013858D32 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=185.70.40.131 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700874905; cv=none; b=DjbGwPeW63bYdLGxgCSVHZuPNQWLUTINHOf0mAKRYkVtIn6DmhIIUsNsYAv/kglk4OPxRa9JilPsxdg0CYbpPuQ6A3jXhT2J1YyWaEAmHJbO/JwPhttnXFu0F/jZFPi0HehFCoR+fXG7ZhDxYABfIweOd09Yon10/L5IcTCBN9w= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700874905; c=relaxed/simple; bh=1YpJdLMVJeBpmJa0yEhSZk1uCOas1pVFFRdrMgi0u6o=; h=DKIM-Signature:Date:To:From:Subject:Message-ID:MIME-Version; b=bd8a2YjcbF7MW/VW8VAcmyzNtwWtHEuV6Ql0egi93QGigwdZ+RAjjAWG66aJIgEGZEfyVVZhXlXaQwubA/LK241bMLSEkzW6NKi1aNHCEBSSK77B/M1AKmlqVtECVLVJRk0JMmN5hQ59Z2FVdNAqvy6KZ4EvFhuh/7WjbV5Rvwc= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1700874899; x=1701134099; bh=4xPM5UjPGDsiL3gjBgPEhdg2qHVZemQE4kffkuDtpq0=; 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=p9gtnMFEMdyj2Je26DIrajW04zqI0er1C2SFDKoqyZeU8+IeHSnb/kv2BIBwDkc/2 B4vmWCExC4UM7UhiM8c9OIIWKSBOINOI/6K6+ZC3a3srfZU9ggDS2h2p8FLNi2NAj3 hkBkf+vETAsLvevu+I304ncxLTFCNri0mE1FJ2IeiKvP0D2NYxMBem0d5G/2GULIb1 pdcZ+p8ZAlYfvaV+ZvbGn9Vm6hilqOMxoWcye6znJMDKt5cMjXgVEX0s1XkscvxxKj KDKnQoG+Ha27n9PH1SU8qHvFtWbMRI0FZCUvXWmD6kBlvkKdDgLIx9M7/vrg3t6mrJ fsJi1pvMM/KBA== Date: Sat, 25 Nov 2023 01:14:44 +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: <7Xr5Vil7ptZzPaCtc_ZCdcTPuUVY7dheOnklF-vVDb5_jl8PivYWgTT_f3cKLvg7IMnDruCDDrICRI6WVrUT3f8ZScGKAh4ATIkYSuRqPZc=@protonmail.com> In-Reply-To: References: =?us-ascii?Q?__<1MdaTybBd=5Fo4uw-Gb23fYyd5GNz7qFqoSe=5Ff5h90LY=5FBdzM2ge2qPSyCuiCLYoYcZSjmVv13fw1LmjQC=5FM2L8raS1fydY5pEJ=5Fvwvv5Z-0k=3D@protonmail.com>___<9OlK=5F2c3Punfm3w-wEHqyHGyKGG8Gr=5FK0BUnDOuC9Aazur4mWlAM5WuL1Ea0AMLvFLl6LKFVTs813yY0zA7m0=5Fji=5FR9qhE52G7MZXrVPfZE=3D@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.7 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, I figured out SOMETHING, I think this should be fine. As noted in the comments, this might be a better way of handling the static lambda case too. This is still a nasty hack so it should probably be done differently, but I question if making a whole new fntype node in tsubst_lambda_expr makes sense. On the other hand, maybe there will be problems if a lambda is already instantiated? I'm not sure, mutating things this way makes me uneasy though. I don't like that pt.cc feels like it has a ton of hidden mutations, it's really hard to follow through it. Would you agree it's in need for cleanup or am I just not experienced enough in this area yet? I still have to write good tests for this case and move the error handling for unrelated object types into here, but my gut tells me this issue should be fixed now. Regarding the error handling, I just had a thought about it, I have a hunch it definitely needs to go in tsubst_template_decl or tsubst_function_decl. There might need to be more changes to determine the actual type of the lambda in there, but everything else I've done changes the implicit object argument to be treated more like a regular argument, doing error handling for the object type in tsubst_lambda_expr would be inconsistent with that. Also, before I forget, you were totally right about just using dependent_type_p in cp_parser_lambda_declarator_opt. It really is just that simple. The code below is not necessarily final, but I wanted to get your thoughts about doing it this way given my concerns written above. Now that this problem is out of the way, or at least almost out of the way, I hopefully can get a version pushed out today. Alex diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc index 86c95b278ba..ea2db5c0c9d 100644 --- a/gcc/cp/pt.cc +++ b/gcc/cp/pt.cc @@ -14407,14 +14407,20 @@ tsubst_function_decl (tree t, tree args, tsubst_f= lags_t complain, gen_tmpl =3D NULL_TREE; argvec =3D NULL_TREE; } - + /* We hack TYPE_METHOD_BASETYPE onto xobj member functions in + tsubst_lambda_expr to get the proper closure type here. */ tree closure =3D (lambda_fntype ? TYPE_METHOD_BASETYPE (lambda_fntype) : NULL_TREE); 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. */ + tsubst_lambda_expr now that we know the closure type. + I suspect that we can just carry this information down in + TYPE_METHOD_BASETYPE without building the full method type in + tsubst_lambda_expr. This wouldn't be ideal but neither is this. + Since that field isn't used for anything for static or xobj member + functions, it should be fine to do that. */ if (lambda_fntype && DECL_STATIC_FUNCTION_P (t)) lambda_fntype =3D static_fn_type (lambda_fntype); =20 @@ -14490,12 +14496,12 @@ tsubst_function_decl (tree t, tree args, tsubst_f= lags_t complain, DECL_NAME (r) =3D make_conv_op_name (TREE_TYPE (type)); =20 tree parms =3D DECL_ARGUMENTS (t); - if (closure && !DECL_STATIC_FUNCTION_P (t)) + if (closure && DECL_IOBJ_MEMBER_FUNC_P (t)) parms =3D DECL_CHAIN (parms); parms =3D tsubst (parms, args, complain, t); for (tree parm =3D parms; parm; parm =3D DECL_CHAIN (parm)) DECL_CONTEXT (parm) =3D r; - if (closure && !DECL_STATIC_FUNCTION_P (t)) + if (closure && DECL_IOBJ_MEMBER_FUNC_P (t)) { tree tparm =3D build_this_parm (r, closure, type_memfn_quals (type))= ; DECL_NAME (tparm) =3D closure_identifier; @@ -19491,9 +19497,16 @@ tsubst_lambda_expr (tree t, tree args, tsubst_flag= s_t complain, tree in_decl) cp_evaluated ev; =20 /* Fix the type of 'this'. */ - fntype =3D build_memfn_type (fntype, type, -=09=09=09=09 type_memfn_quals (fntype), -=09=09=09=09 type_memfn_rqual (fntype)); + if (DECL_IOBJ_MEMBER_FUNC_P (oldfn)) +=09fntype =3D build_memfn_type (fntype, type, +=09=09=09=09 type_memfn_quals (fntype), +=09=09=09=09 type_memfn_rqual (fntype)); + /* We don't use this field anywhere else for xobj member functions, = and +=09 we need a way to pass this information down. Theres some really +=09 convoluted stuff going on unfortunately, and I can only begin to +=09 unravel it all. */ + if (DECL_XOBJ_MEMBER_FUNC_P (oldfn)) +=09TYPE_METHOD_BASETYPE (fntype) =3D type; tree inst =3D (oldtmpl ? tsubst_template_decl (oldtmpl, args, complain, fntype, tparms)