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 AE1683858D1E for ; Mon, 1 Jan 2024 15:18:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AE1683858D1E 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 AE1683858D1E 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=1704122286; cv=none; b=PKSGZ0ytMPCD3xTO0MrJKPBiFWLixydrpoUH/u+41f2cooDvwBiEpCHQy8shEUtPjyOoZaRBJf5XnqbDj9MEmdaOH4MrKGNljXdu0axSsnlXlvR3sk7AInK07wxLVGUBzKCypaWzM9e4X9+Ou+M+cf9Manpp2RwopPehF0WOnRY= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704122286; c=relaxed/simple; bh=cxx8lPReKUmcwAGpAD4iKxlsT4qZcAKNOyU0jnxpvpA=; h=DKIM-Signature:Date:To:From:Subject:Message-ID:MIME-Version; b=SCrC5hK7qz76Bt+XrYbmE4+0zBuD5XYfHehR20k6CgA4MABDmyC1dn5SONrvZ3nhPbvIuZOCgM70L9wFiSCII2mSIWiMewAEMkCS1Zi8k3w9tzwgOk2DlSudcYRHekvEIyjbxfzQuDZWTGtB5PyH4Y1aFEdrwRZxZB791xH2tYE= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1704122280; x=1704381480; bh=BOSGGSgAzk7D3ggyAuyfPneKAIPAJsw0GqSU6C9QYGs=; 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=i+3b5M7YDCBpyDOP7964/Tkr+aLo1ggLyw2ZJ110sCDGjsbct7qxvsD4rXjcVVsjP 1AiYBEAFrHFEc13Nvdw6S4CjvNumyCfFoVSASw9cn+mahdp6s6BXEldsYCdkFiaDS+ dpm3PrXEs+GiNxk4JNnBssIz/h0bPOL35AKK41OTPhjbU4OR0LJeFHBER+gHHl6NmV JuS+4N9wiC7PEernTvw1qzWrU7X7Zp+rHvi/vtJzQyrYkjxYq+zeFk90qngZMJtn0Z m1PW4+IB2asmz5AhbIrQrpDDkYBDr7Nk4oo3thNs/6x21OpVZ/jTkLeG0rygTvVHeb U4gnWyUdMp1Ww== Date: Mon, 01 Jan 2024 15:17:34 +0000 To: Jason Merrill From: waffl3x Cc: "gcc-patches@gcc.gnu.org" Subject: Re: [PATCH v7 1/1] c++: Initial support for P0847R7 (Deducing This) [PR102609] Message-ID: In-Reply-To: <8b5533f7-4033-47f5-b238-851e37730b52@redhat.com> References: <59LofhYhxl7MLEuElXwZcESRB6MpjdG-iq-89B63siDRo5k0j-y6z-PVa6Y3iE1xE5LkJwpwTFi82bd0RZjB1yZbSJptFdPTBWfvOGj1W78=@protonmail.com> <4e1adee6-269a-4a27-ad23-2742277d7889@redhat.com> <8b5533f7-4033-47f5-b238-851e37730b52@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.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_SHORT,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: I've been at this for a while, and I'm not sure what the proper way to fix this is. ``` struct S; struct B { void f(this S&) {} void g() {} }; struct S : B { using B::f; using B::g; void f() {} void g(this S&) {} }; int main() { S s{}; s.f(); s.g(); } ``` In short, the call to f is ambiguous, but the call to g is not. I already know where the problem is, but since I share this code in places that don't know about whether a function was introduced by a using declaration (cand_parms_match), I don't want to rely on that to solve the problem. ``` /* An iobj member function's object parameter can't be an unrelated type,= if the xobj member function's object parameter is an unrelated type we kn= ow they must not correspond to each other. If the iobj member function w= as introduced with a using declaration, then the type of its object param= eter is still that of the class we are currently adding a member function t= o, so this assumption holds true in that case as well. [over.match.funcs.general.4] For non-conversion functions that are implicit object member functions nominated by a using-declaration in a derived class, the function is considered to be a member of the derived class for the pur= pose of defining the type of the implicit object parameter. We don't get to bail yet out even if the xobj parameter is by-value as elaborated on below. This also implicitly handles xobj parameters of type pointer. */ if (DECL_CONTEXT (xobj_fn) !=3D TYPE_MAIN_VARIANT (non_reference (xobj_pa= ram))) return false; ``` I feel like what we are actually supposed to be doing to be to the letter of the standard is to be creating a new function entirely, with a decl_context of the original class, which sounds omega silly, and might bring a new set of problems. I think I might have came up with an unfortunately fairly convoluted way to solve this just now, but I don't know if it brings another new set of problems. The assumptions I had when I originally implemented this in add_method bled through when I broke it out into it's own function. At the very least I need to better document how the function is intended to be used, at worst I'll need to consider whether it makes sense to be reusing this logic if the use cases are subtly different. I don't think the latter is the case now though, I'm noticing GCC just has a bug in general with constraints and using declarations. https://godbolt.org/z/EbGvjfG7E So it might actually just be better to be rewriting functions that are introduced by using declarations, I have a feeling that will be what introduces the least pain. I'm not sure where exactly GCC is deciding that a function introduced by a using declaration is different from an otherwise corresponding one declared directly in that class, but I have a feeling on where it is. Obviously it's in joust, but I'm not sure the object parameters are actually being compared. I'll investigate this bug and get back to you, I imagine fixing it is going to be key to actually implementing the xobj case without hacks. Finding both these issues has slowed down my next revision as I noticed the problem while cleaning up my implementation of CWG2789. I want to note, I am implementing it as if it specifies corresponding object arguments, not object arguments of the same type, as we previously discussed, I believe that to be the right resolution as there are really bad edge cases with the current wording. Alex On Tuesday, December 26th, 2023 at 9:37 AM, Jason Merrill wrote: >=20 >=20 > On 12/23/23 02:10, waffl3x wrote: >=20 > > On Friday, December 22nd, 2023 at 10:26 AM, Jason Merrill jason@redhat.= com wrote: > >=20 > > > On 12/22/23 04:01, waffl3x wrote: > > >=20 > > > > int n =3D 0; > > > > auto f =3D [](this Self){ > > > > static_assert(__is_same (decltype(n), int)); > > > > decltype((n)) a; // { dg-error {is not captured} } > > > > }; > > > > f(); > > > >=20 > > > > Could you clarify if this error being removed was intentional. I do > > > > recall that Patrick Palka wanted to remove this error in his patch,= but > > > > it seemed to me like you stated it would be incorrect to allow it. > > > > Since the error is no longer present I assume I am misunderstanding= the > > > > exchange. > > > >=20 > > > > In any case, let me know if I need to modify my test case or if thi= s > > > > error needs to be added back in. > > >=20 > > > Removing the error was correct under > > > https://eel.is/c++draft/expr.prim#id.unqual-3 > > > Naming n in that lambda would not refer a capture by copy, so the > > > decltype is the same as outside the lambda. > >=20 > > Alright, I've fixed my tests to reflect that. > >=20 > > I've got defaulting assignment operators working. Defaulting equality > > and comparison operators seemed to work out of the box somehow, so I > > just have to make some fleshed out tests for those cases. > >=20 > > There can always be more tests, I have a few ideas for what still needs > > to be covered, mostly with dependent lambdas. Tests for xobj conversion > > operators definitely need to be more fleshed out. I also need to > > formulate some tests to make sure constraints are not being taking into > > account when the object parameters should not correspond, but that's a > > little more tough to test for than the valid cases. > >=20 > > Other than tests though, is there anything you can think of that the > > patch is missing? Other than the aforementioned tests, I'm pretty > > confident everything is done. > >=20 > > To recap, I have CWG2789 implemented on my end with the change we > > discussed to require corresponding object parameters instead of the > > same type, and I have CWG2586 implemented. I can't recall what other > > outstanding issues we had, and my notes don't mention anything other > > than tests. So I'm assuming everything is good. >=20 >=20 > Sounds good! Did you mean to include the updated patch? >=20 > Jason