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 3A31A3858D1E for ; Sat, 11 Nov 2023 11:25:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3A31A3858D1E 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 3A31A3858D1E 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=1699701911; cv=none; b=aMTJkD6yHXLqJRESDJki5lOP9Vlyz0agu/qlvOCKgc3sqyxWdrF7w2pPpUMf/OF8XipQPMCV5V+WYNW9il9y21Eda1R+oBCqvxhehXnDYIGdKhxx4xVz9XLvjnF7wGzRDTZZCNUC07tlvB62nznjF0QuT9unRmxvdnKmo4T9FHk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699701911; c=relaxed/simple; bh=j0uvnpkKdpnNPcmwGmM3N5CEpocix6dwbdRmTGwT8gs=; h=DKIM-Signature:Date:To:From:Subject:Message-ID:MIME-Version; b=k7SWfOUqklrGsOVPrbCA7cS00j+yvwKc7OOG6FBoSik3kubtu5qBYxaARHOLLr1qL7Gn4/T9YT4DxUJ0SqTyJfKbD8gLtg3atC7Oi4ismQAy4xZI99WabzNXpVl8ZZ1azE2wbyQnN1G9CjmziQzIxp3A8z7vK2tAk8FGxCWjHIQ= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1699701906; x=1699961106; bh=gDQqtmgengmO7IXNh64X85+ljoZNXS/RRBLjgCohHyc=; 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=yMQOJbaVlf3IqF6y/6pydLiff3zFdTzXi1DOoHxB2M5sBq2XAGo7zJhnfM+zrUWdd nWZIt6DldpCFEBxMQgV3mQNZF4xG5zUaqBKr2i6qgHgmtdxGlvU4YwSzictG8LBzww Yb467v11+qG7lt9o/YtUsGdORRPjGpF0RgCN2vF1YLpfSqYukJSRsTcOBmVKnPmQj0 nKsrbioHYhDtIh4r4Ucs8HSv+fBuyKe3Gmp/HXhutBeXtAfAz7HUDuLiVhOxwm5dLo WoeiUqvgX4NaFWCqqcAaIIeSbfNMiKgsXP8OsTbRiVNhFfG3MYwJ9tWArGhgdkEZES bYeRJGT1jZP1w== Date: Sat, 11 Nov 2023 11:24:58 +0000 To: waffl3x From: waffl3x Cc: Jason Merrill , "gcc-patches@gcc.gnu.org" Subject: Re: [PATCH v3 1/2] c++: Initial support for P0847R7 (Deducing This) [PR102609] Message-ID: In-Reply-To: References: <2f4020bf-3ef7-4627-9d92-c74676981f4b@redhat.com> <2nV4Jls2nmL2lahW6X-HZsBb90H1QZJhy3ApVC8xpxvP6KUYDriDYJpxzqjDnshOUEQ6ehYzuXU6rJmPvj3l6jtqAniFlH4Buyfls4E8cfY=@protonmail.com> <00094736-8325-4c83-9237-a6c15c324c24@redhat.com> <3tSXKK_P5IpLLm2VJ76q-eiLPZhiaC6_ZpwOrej22LWsmGA_YXipLXwLdLNeFlShJaqpFH_LPQW6tqkPD1WlFnExnL-iDoW9CoA-KQETWYw=@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=-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,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: Just a quick addition here as I was starting to work on things I realized where some misunderstandings were coming from. (Please also see my previous e-mail, it is all still relevant, I just wanted to clarify this.) (From the other thread) > > @@ -9949,7 +9951,8 @@ build_over_call (struct z_candidate cand, int fla= gs, tsubst_flags_t complain) > > } > > } > > / Bypass access control for 'this' parameter. */ > > - else if (TREE_CODE (TREE_TYPE (fn)) =3D=3D METHOD_TYPE) > > + else if (TREE_CODE (TREE_TYPE (fn)) =3D=3D METHOD_TYPE > > + || DECL_XOBJ_MEMBER_FUNC_P (fn)) >=20 >=20 > We don't want to take this path for xob fns. Instead I think we need to > change the existing: > > > gcc_assert (first_arg =3D=3D NULL_TREE); >=20 >=20 > to assert that if first_arg is non-null, we're dealing with an xob fn, > and then go ahead and do the same conversion as the loop body on first_ar= g. (This thread) > > Yeah, as I noted above I realized that just handling it the same way as > > iobj member functions is fundamentally broken. I was staring at it last > > night and eventually realized that I could just copy the loop body. I > > ended up asserting in the body handling the implicit object argument > > for xobj member functions that first_arg !=3D NULL_TREE, which I wasn't > > sure of, but it seems to work. >=20 >=20 > That sounds like it might cause trouble with >=20 > struct A { > void f(this A); > }; >=20 > int main() > { > (&A::f) (A()); > } >=20 Upon reviewing your reply in the other thread, I noticed you are maybe misunderstanding the assertion a little bit. ``` else if (TREE_CODE (TREE_TYPE (fn)) =3D=3D METHOD_TYPE) { /* SNIP */ if (first_arg !=3D NULL_TREE) first_arg =3D NULL_TREE; else ++arg_index; ++i; is_method =3D 1; } else if (DECL_XOBJ_MEMBER_FUNC_P (fn)) { gcc_assert (cand->first_arg); /* SNIP */ first_arg =3D NULL_TREE; } ``` I already showed my code here but I didn't think to include the previous conditional block to demonstrate how the first_arg variable gets handled in it. Although, maybe you understood they set it to NULL_TREE by the end of the block and I just poorly communicated that I would be doing the same. Perhaps you think it better to handle the implicit object argument within the loop, but given that it is stored in first_arg I don't think that would be correct. Granted, as I previously said, maybe there are some situations where it isn't that I haven't encountered yet. The other thing is there is some handling in the loop that isn't relevant to the implicit object argument. Well, I would also just argue this function needs a fair degree of refactoring, but I've already talked about that. Anyway, hopefully that clarifies things, and hopefully things actually needed to be clarified and I'm not being a fool here. :) That's all I had to add about this, back to work now. Alex