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 728073858D1E for ; Mon, 1 Jan 2024 15:34:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 728073858D1E 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 728073858D1E 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=1704123301; cv=none; b=wV1EFFAUFR9OTAmZb0Bwfi/P5WcF0ThqUFecFVvwucLUZyeGrDdj+EJpfh+XFWxA2n2MhSREALMVhPOnmHWmznsBH7XdfKeZYbPbcSjXyRrFcb9HbViQ6FknHg4+wpN4OFhGtCHzcqjBs8sVeAXybvgkbMeHrFD0F1LE5iewiSk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704123301; c=relaxed/simple; bh=MkpjpKG7OZ0jXW0wVkwN5s8K5SPXQ1dJndcQOTboszA=; h=DKIM-Signature:Date:To:From:Subject:Message-ID:MIME-Version; b=bW40rVcn9mc3ZllHehFB9NmQbxD14u0He/Uaan84g/OwZYhq0xA6tLAu3tZRJR6N1Kz0TOqxhWpgf4gce9wwl3u77V/G1FLs47H8SERsYFcj5dMFgrE+oc0+j64GtTq94FRqSA2HRl0nFUSTS4xPPavtbeEypIzuvLFFlpqwS60= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1704123298; x=1704382498; bh=MkpjpKG7OZ0jXW0wVkwN5s8K5SPXQ1dJndcQOTboszA=; 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=xwaZJCJx3Y49+mPMlB/vs+VZuM+W1HJDynAg70UCwL57np08I2hIFj2VNo4z2bQ9B JdMfftdHQk7HXiSkea9bzL39Oip8lwS//ClUZG1+DmPQUNomCKya9Czpb7c658J7Iu sDBXWC0miR8JimuGUdn+YI7dh+SWZqnyEyzvd0dU433sc4bGF93lZtqZzmx3jjmz1F bJVZRyykkYRO1ddZLjraj1wjLLjNsUFv1HSrMteI89F8d9HTOtMwqpuGKynFznJJL0 23v9Yuc/DdeNMcT2mV58cA6ITZx7cK/QA0qBXN+MA3Su70shRHNuWqWCZC+uC3q73A BzBuJlQvcnVEg== Date: Mon, 01 Jan 2024 15:34:35 +0000 To: waffl3x From: waffl3x Cc: Jason Merrill , "gcc-patches@gcc.gnu.org" Subject: Re: [PATCH v7 1/1] c++: Initial support for P0847R7 (Deducing This) [PR102609] Message-ID: In-Reply-To: References: <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,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: That was faster than I expected, the problem is exactly just that we aren't implementing [over.match.funcs.general.4] at all. The result of compparms for the 2 functions is false which I believe to be wrong. I believe we have a few choices here, but no matter what we go with it will be a bit of an overhaul. I will post a PR on bugzilla in a little bit as this problem feels somewhat out of the scope of my patch now. I think what I will do is instead of comparing the xobj parameter to the DECL_CONTEXT of the xobj function, I will compare it to the type of the iobj member function's object parameter. If I do it like this, it will work as expected if we rewrite functions that are introduced with a using declaration. This might still cause problems, I will look into how the this pointer for iobj member functions is determined again. Depending on how it is determined, it might be possible to change the function signature of iobj member functions without altering their behavior. It would be incorrect, and would change the meaning of code, if changing the function signature changed the type of the this pointer. Anyhow, this is a fairly big change to consider so I won't pretend I know what the right call is. But the way I've decided to implement correspondence checking will be consistent with how GCC currently (incorrectly) treats constraints on iobj member functions introduced with a using declaration, so I think doing it this way is the right choice for now. Some days feel really unproductive when the majority is investigation and thinking. This was one of them, but at least I'm confident that my conclusions are correct. Aren't edge cases fun? Alex On Monday, January 1st, 2024 at 8:17 AM, waffl3x w= rote: >=20 >=20 > I've been at this for a while, and I'm not sure what the proper way to > fix this is. >=20 > `struct S; struct B { void f(this S&) {} void g() {} }; struct S : B { us= ing B::f; using B::g; void f() {} void g(this S&) {} }; int main() { S s{};= s.f(); s.g(); }` >=20 > 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. >=20 > `/* 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 was = introduced with a using declaration, then the type of its object parameter = is still that of the class we are currently adding a member function to, 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 consid= ered to be a member of the derived class for the purpose of defining the ty= pe of the implicit object parameter. We don't get to bail yet out even if t= he 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_param))) return false;` >=20 > 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. >=20 > 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. >=20 > 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. >=20 > https://godbolt.org/z/EbGvjfG7E >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > Alex >=20 > On Tuesday, December 26th, 2023 at 9:37 AM, Jason Merrill jason@redhat.co= m wrote: >=20 >=20 >=20 > > On 12/23/23 02:10, waffl3x wrote: > >=20 > > > On Friday, December 22nd, 2023 at 10:26 AM, Jason Merrill jason@redha= t.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 patc= h, 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 misunderstandi= ng the > > > > > exchange. > > > > >=20 > > > > > In any case, let me know if I need to modify my test case or if t= his > > > > > 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 nee= ds > > > to be covered, mostly with dependent lambdas. Tests for xobj conversi= on > > > operators definitely need to be more fleshed out. I also need to > > > formulate some tests to make sure constraints are not being taking in= to > > > 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 > > Sounds good! Did you mean to include the updated patch? > >=20 > > Jason