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 473CA3858D1E for ; Mon, 1 Jan 2024 17:13:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 473CA3858D1E 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 473CA3858D1E 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=1704129195; cv=none; b=bhQPDhvr7kIUpf1eJfaMuM7tAD4FMLbPEc/GK0pHqZwaLXgl1RQk5REon4DoJUvFKdsXXXc2L9TK+GEwkTXsLhPalOpuj0Y2Vr+mz0UieRUJjMs6ZDTTi3OP1Z8Tqo9aAKG7WRyxilJ0FTUgkTegNib92DswPgS3uVa+MMd3Ucw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704129195; c=relaxed/simple; bh=X3YsKuJG3+Ar2s2BvtQVxF/kVwSrll88+mUWutyXhQs=; h=DKIM-Signature:Date:To:From:Subject:Message-ID:MIME-Version; b=SljwKwSKtOS2BoSO0vkRuB5BIonBsAnDWv6dE0NZp0Lw5oASCqaAE23i4y2YPJsTwAPmLFCWkBh3j8+yQcHdNfcoPfJM4grPMH7xTgRKE7FOPQldkieYflJqqt0It23eU0nQYeke1JdroKpUEBTzKyvRXCuOuLPeNy/gNGHahdE= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1704129191; x=1704388391; bh=X3YsKuJG3+Ar2s2BvtQVxF/kVwSrll88+mUWutyXhQs=; 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=bdaAuSx36iJ7O4/26InjdeA3IbvJCVb7sm+rHyzgw7QGVT3spZ58ehaU7AkxTA0ad IQN2vVUk0cf5DJ1Zj0ahiS2alKnijHhGeclTGRJYKGLR8efmTe/9VpS27TnJsWF8XG qLtZqUSBrUWu+j7jzZcImcWNR0IHBZQeDnGNSM9hUth2YSyIxGec/r4bUcV9IU+y4j WlH3scWpBtLe53VC1NwSJdQC8P7e7FI8kGJRBSuGSmnv/2uMfob5fRhj9T2XO85N1Y eeMcUAjAGBwD9FUpbpSNNgCWmMX/WlMo/XC9Wi1rdXVBZkxD0suv8MXZBfG7j5f5Mw uba76R1F70anQ== Date: Mon, 01 Jan 2024 17:12:43 +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=-3.0 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: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D113191 I've posted the report here, I ended up doing a bit more investigation, so the contents might interest you. I'm really starting to think that we want to do a more thorough re-engineering of how using declarations are handled, instead of handling it with little hacks like the one added to more_specialized_fn. As I note in the report, the addition of xobj member functions really makes [over.match.funcs.general.4] a lot more relevant, and I don't think we can get away with not following it more closely anymore. I know I'm wording myself here as if that passage has existed forever, but I recognize it might be as recent as C++23 that it was added. I don't mean to imply anything with how I'm wording it, it's just way easier to express it this way. Especially since we really could get away with these kinds of hacks if xobj member functions did not exist. Unfortunately, the type of the implicit object parameter is suddenly relevant for cases like this. Anyway, as I've stated a few times, I'm going to implement my function that checks correspondence of the object parameter of iobj and xobj member functions assuming that iobj member functions introduced by using declarations are handled properly. I think that's the best option for my patch right now. Well that investigation took the majority of my day. I'm just glad I'm certain of what direction to take now. Alex On Monday, January 1st, 2024 at 8:34 AM, waffl3x w= rote: >=20 >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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? >=20 > Alex >=20 > On Monday, January 1st, 2024 at 8:17 AM, waffl3x waffl3x@protonmail.com w= rote: >=20 >=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 { = using 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 ty= pe, if the xobj member function's object parameter is an unrelated type we = know they must not correspond to each other. If the iobj member function wa= s introduced with a using declaration, then the type of its object paramete= r 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.gener= al.4] For non-conversion functions that are implicit object member function= s nominated by a using-declaration in a derived class, the function is cons= idered to be a member of the derived class for the purpose 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 implicitl= y 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.= com wrote: > >=20 > > > On 12/23/23 02:10, waffl3x wrote: > > >=20 > > > > On Friday, December 22nd, 2023 at 10:26 AM, Jason Merrill jason@red= hat.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 pa= tch, 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 misunderstan= ding the > > > > > > exchange. > > > > > >=20 > > > > > > In any case, let me know if I need to modify my test case or if= this > > > > > > 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 equali= ty > > > > 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 n= eeds > > > > to be covered, mostly with dependent lambdas. Tests for xobj conver= sion > > > > 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 th= e > > > > 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 othe= r > > > > outstanding issues we had, and my notes don't mention anything othe= r > > > > than tests. So I'm assuming everything is good. > > >=20 > > > Sounds good! Did you mean to include the updated patch? > > >=20 > > > Jason