From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16]) by sourceware.org (Postfix) with ESMTPS id A01F438449ED for ; Tue, 21 Nov 2023 10:03:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A01F438449ED 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 A01F438449ED Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=185.70.43.16 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700561001; cv=none; b=ZVDpei3EMpymmjFDsI2BQs11khDmjCCQpnxx0umxTNnCojnR+naKJYMEzVpgvKCa2deQFEF3u8kK7lQG9llHZd5aqjIfp9t9qAxV5oTjHbR3Uuj+1KEgaJ91lN8kryTlUdKzd0hmfsG9GYIcPh/s4oPYojxeriprapn/4GiO9V0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700561001; c=relaxed/simple; bh=YTc3mCdkUBNNbtX4jhJnFUHh7JWBT0Tbt3ixKEUvpeY=; h=DKIM-Signature:Date:To:From:Subject:Message-ID:MIME-Version; b=inO1t3ARA+luJ2WoZ/nJatpeH/tdCxPqsB08cm/dIELd4eClbnoemVOSb8sPYXQqvf/bDsBvqxelFdRZWomqfggrK2op+6TBt6DC0A8wI1BEb7UT2nY0E9ubcYfr2SnWQuY+smMzyEJsH0kPDkv1pWFu00hu6xff49DlYPODa2g= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1700560994; x=1700820194; bh=YTc3mCdkUBNNbtX4jhJnFUHh7JWBT0Tbt3ixKEUvpeY=; 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=YIJZM7IH6Bm8R79Rpr/1yS0J4/XJ2neFXHFkZxtGDEb679HoYrZctwxIV8PXJu13W JoWe7luIpM2F/s8fBcMZpa18j/+wJtvOB5tL2FQtwKeQdZ96btzBJRJWQEMT2iDHgX 2Z5MlLZD7jabfd+AZ4Dkbq810NOm8+aW4Qr+c8PYaxGs2CjGWUY039YA/BSDAqrOkq /I2i4czy1slSOrh1AIas726mu2SlNa2XBYAvdprv6hywc4CDgJw9nySyu0sYyLQlv5 aU6BSq+PuJQ0v7zbK9aNnSxy4Q72XHmOGxsYZTpPItN+ZRGD85wXLs3bkk3G+iwT0t op2Mxoz8iHD0w== Date: Tue, 21 Nov 2023 10:02:58 +0000 To: Jason Merrill From: waffl3x Cc: "gcc-patches@gcc.gnu.org" Subject: Re: [PATCH v3 1/2] c++: Initial support for P0847R7 (Deducing This) [PR102609] Message-ID: <1MdaTybBd_o4uw-Gb23fYyd5GNz7qFqoSe_f5h90LY_BdzM2ge2qPSyCuiCLYoYcZSjmVv13fw1LmjQC_M2L8raS1fydY5pEJ_vwvv5Z-0k=@protonmail.com> In-Reply-To: References: <9890a007-755e-41e2-bc33-37ebf0755435@redhat.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=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS,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: On Monday, November 20th, 2023 at 7:35 AM, Jason Merrill = wrote: >=20 >=20 > On 11/19/23 16:44, waffl3x wrote: >=20 > > On Sunday, November 19th, 2023 at 1:34 PM, Jason Merrill jason@redhat.c= om wrote: > >=20 > > > On 11/19/23 13:36, waffl3x wrote: > > >=20 > > > > I'm having trouble fixing the error for this case, the control flow > > > > when the functions are overloaded is much more complex. > > > >=20 > > > > struct S { > > > > void f(this S&) {} > > > > void f(this S&, int) > > > >=20 > > > > void g() { > > > > void (*fp)(S&) =3D &f; > > > > } > > > > }; > > > >=20 > > > > This seemed to have fixed the non overloaded case, but I'm also not > > > > very happy with it, it feels kind of icky. Especially since the exp= r's > > > > location isn't available here, although, it just occurred to me tha= t > > > > the expr's location is probably stored in the node. > > > >=20 > > > > typeck.cc:cp_build_addr_expr_1 > > > > ``` > > > > case BASELINK: > > > > arg =3D BASELINK_FUNCTIONS (arg); > > > > if (DECL_XOBJ_MEMBER_FUNC_P ( > > > > { > > > > error ("You must qualify taking address of xobj member functions"); > > > > return error_mark_node; > > > > } > > >=20 > > > The loc variable was set earlier in the function, you can use that. > >=20 > > Will do. > >=20 > > > The overloaded case we want to handle here in > > > resolve_address_of_overloaded_function: > > >=20 > > > > if (DECL_NONSTATIC_MEMBER_FUNCTION_P (fn) > > > > && !(complain & tf_ptrmem_ok) && !flag_ms_extensions) > > > > { > > > > static int explained; > > > >=20 > > > > if (!(complain & tf_error)) > > > > return error_mark_node; > > > >=20 > > > > auto_diagnostic_group d; > > > > if (permerror (input_location, "assuming pointer to member %qD", fn= ) > > > > && !explained) > > > > { > > > > inform (input_location, "(a pointer to member can only be " > > > > "formed with %<&%E%>)", fn); > > > > explained =3D 1; > > > > } > > > > } > > >=20 > > > Jason > >=20 > > I'll check that out now, I just mostly finished the first lambda crash. > >=20 > > What is the proper way to error out of instantiate_body? What I have > > right now is just not recursing down further if theres a problem. Also, > > I'm starting to wonder if I should actually be erroring in > > instantiate_decl instead. >=20 >=20 > I think you want to error in start_preparsed_function, to handle > template and non-template cases in the same place. >=20 > Jason I just started a bootstrap, hopefully everything comes out just fine. If I don't pass out before the tests finish (and the tests are all fine) then I'll send it in for review tonight. I stared at start_preparsed_function for a long while and couldn't figure out where to start off at. So for now the error handling is split up between instantiate_body and cp_parser_lambda_declarator_opt. The latter is super not correct but I've been stuck on this for a long time now though so I wanted to actually get something that works and then try to make it better. This patch is not as final as I would have liked as you can probably deduce from the previous paragraph. I still have to write tests for a number of cases, but I'm pretty sure everything works. I was going to say except for by-value xobj parameters in lambdas with captures, but that's magically working now too. I was also going to say I don't know why, but I found where my mistake was (that I fixed without realizing it was causing the aforementioned problem) so I do know what did it. So rambling aside, I think everything should work now. To reiterate, I still have to finish the tests for a few things. There's some diagnostics I'm super not happy with, and lambda's names still say static, but I already know how to fix that I think. I will make an attempt at moving the diagnostics for an unrelated explicit object parameter in a lambda with captures tomorrow. I just want to get the almost fully featured patch reviewed ASAP, even if it's still got some cruft. As soon as these tests pass I will submit the patch, I'm not going to split it up today, I'm simply too tired, but I assure you the final version will properly be split up with a correct commit message and everything. Alex