From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-40134.protonmail.ch (mail-40134.protonmail.ch [185.70.40.134]) by sourceware.org (Postfix) with ESMTPS id 83C763858CDB for ; Sat, 25 Nov 2023 22:59:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 83C763858CDB 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 83C763858CDB Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=185.70.40.134 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700953186; cv=none; b=OkzCzUtGpPRf4dNIIWHEw4RBUMmqcCY9OTdWac49VbNoES2tYJosfDX9TQ47siT/YKJSGwUxW60PiKdupfiFkehzLIonHOqWj+u3cGcPajpVrfoZgBjalDiNRReeaRXwnOiiEF3N/tQJhfS/FhM2l8/pF5FvUCiLFxQME676bXE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700953186; c=relaxed/simple; bh=EnqsrQ+EMI8qywuC/YnN1X1SeYdBiOLpF/8Mslpx5Dg=; h=DKIM-Signature:Date:To:From:Subject:Message-ID:MIME-Version; b=biMGrb5GbgafhIJsCucgyGVTtZClk6yvhDwLq4gZEXbxyLokP5kDK/+ml2CXa2rYHZRxnAZn+gPVEFaCsl/8vwhUxoltH2UvBYmMt05+Ur+0O0xPhgfu9SxHVSrsA0FB5SQsWONxdamzSggFxcUcdftFA6fMr4zW9zSY6S6t0SU= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1700953181; x=1701212381; bh=EnqsrQ+EMI8qywuC/YnN1X1SeYdBiOLpF/8Mslpx5Dg=; 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=p7ZZMk2IkmOwamN44d3fNcSuPCeXG5MDjkHe64F+YACUWXJR8ggo1zefmJyUw9WZC hPRybmVoXFtpYRIrcbmmynKRHJpaiQBbgXQJE1wXOHwHCNp638neGzSWM/dsyR+hMd eRZOW7f5eV9cDx4RqlHydepBzTngetxSjtrXs3DYKZGTRYWiZ/JRk585HMhqk5GsfV F2RggEAuCMsq7IsxZ+R5hiwuUUrKZm7shkjX0jAVnxc16L6cSkMuvz3FzEMrqhqvZ4 wG3bso9ssbTij5HAuVNxacTCnigM6wgkwbfvyL4ujaTHo/N2fIC9GeNpcsvtEwznCd koNnHa7v6yKVw== Date: Sat, 25 Nov 2023 22:59:27 +0000 To: Jason Merrill From: waffl3x Cc: "gcc-patches@gcc.gnu.org" Subject: Re: [PATCH v5 1/1] c++: Initial support for P0847R7 (Deducing This) [PR102609] Message-ID: In-Reply-To: <5fa6074a-2b27-4093-bfc8-e0233bafdeb8@redhat.com> References: <1MdaTybBd_o4uw-Gb23fYyd5GNz7qFqoSe_f5h90LY_BdzM2ge2qPSyCuiCLYoYcZSjmVv13fw1LmjQC_M2L8raS1fydY5pEJ_vwvv5Z-0k=@protonmail.com> <9OlK_2c3Punfm3w-wEHqyHGyKGG8Gr_K0BUnDOuC9Aazur4mWlAM5WuL1Ea0AMLvFLl6LKFVTs813yY0zA7m0_ji_R9qhE52G7MZXrVPfZE=@protonmail.com> <5fa6074a-2b27-4093-bfc8-e0233bafdeb8@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=-8.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,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 don't think so, I'm concerned that it might eat the xobj parameter if we do it that way. Besides, all we want is the lambda type anyway, I don't want to build a whole new node just to do that. Upon further consideration I think my solution does work and shouldn't cause problems. The field that I'm using just doesn't get used anywhere else for function_type nodes, and we create a new node in tsubst_function_decl so we don't rely on that field anywhere after it's used in tsubst_function_decl. I think I will null out the member, consuming it, so that is clearly communicated. I am still having issues trying to figure out where exactly to emit errors from, it's really unclear how this stuff works during template instantiation. I tried emitting conditionally based on the complain parameter, but that seemed to suppress errors at all times. While at the same time, I seemed to observe emitting errors unconditionally (correctly) not not displaying the error when another candidate was selected. This leads me to believe that there's already a mechanism for discarding errors that occur during substitution. I don't really know what to do for it, but surely I will figure it out now that I'm asking for help, as tradition dictates. The other problem I'm having is auto f0 =3D [n =3D 5, &m](this auto const&){ n =3D 10; }; This errors just fine, the lambda is unconditionally const so LAMBDA_EXPR_MUTABLE_P flag is set for the closure. This on the other hand does not. The constness of the captures depends on (I assume) LAMBDA_EXPR_MUTABLE_P so all the captures are non-const here. auto f1 =3D [n =3D 5](this auto&& self){ n =3D 10; }; as_const(f1)(); I don't know the right way to solve this, I haven't even really tracked down where the tree is built up. At the moment I think that hacking something into instantiate_body to make them const is the right decision, as the type of the closure shouldn't be changing when instantiating it's call operator template. I'm not sure this is really actually the right call though because it's another thing that feels very much like a hack. As I near completion of the patch it feels like more and more of the solutions I'm finding are hacks, and I don't know if it's just a consequence of old assumptions or if I'm really just reaching for the easy(ier) solutions way too quickly now. These problems are the last few that I have and they are taking me way more time than I am comfortable with. I was going to close out this message there but I just realized why exactly you think erroring in instantiate_body is too late, it's because at that point an error is an error, while if we error a little bit earlier during substitution it's not a hard error. I'm glad I realized this now, because I am much more confident in how to implement the errors for unrelated type now. I'm still a little confused on what the exact protocol for emitting errors at this stage is, as there aren't many explicit errors written in. It seems to me like the errors are supposed to be emitted when calling back into non-template stages of the compiler with substituted types. It also seems like that hasn't always been strictly followed, and I hate to contribute to code debt but I'm not sure how I would do it in this case, nor if I actually have a valid understanding of how this all works. Given my above realization, I'm now more confident in figuring out how exactly to implement the errors for unrelated types. I guess I'm rubber ducking a little bit in these e-mails. On the other hand, if the conclusions I'm forming are incorrect, it's probably still helpful to know the journey I took to get to them. I'm thinking it's probably better I still include my initial concerns even though I feel like I know the answer now. One side note before I close up here, I don't like when *_P macros are used to set flags. Is this something else we should clean up in the future? I'm beginning to wonder if an overhaul that gets rid of the macros from the public interface is a good idea. I'm reluctant to suggest that as I've really warmed up to the macros a lot. They are used in a consistent and easy to understand way which is highly unlike the bad uses of macros that I've seen before that really obscure what's actually going on. But they are still macros, so maybe moving away from them is the right call, especially since there has started to be a mix-up of macros and functions for the same purposes. I'm mildly of the opinion that only one style should be used (in the public interface) because mixing them causes confusion, it did for me anyway. Perhaps I should open a thread on the general mail list and see what others think, get some input before I decide which direction to go with it. To be clear, when I say getting rid of macros, I want to emphasize I mean only in the public interface, I don't see any value in getting rid of macros under the hood as the way the checking macros are implemented is already really good and works. It would only cause problems to try to move away from that. I think I'll probably start to mess around with this idea as soon as this patch is done. That unrelated rambling aside, I will get back to work and try my best to finish the errors for unrelated types today. It feels kind of bad to work so hard on this since I've noticed that it's almost impossible to coerce the case other than overload resolution when taking the address of a lambdas operator. But that's not an excuse to leave a hole in the compiler so, it's still gotta get done. I don't think I will get rejection of mutation of captures done, especially since I'm uncertain of what the right way to do it is, but maybe I'll work fast. On Saturday, November 25th, 2023 at 10:32 AM, Jason Merrill wrote: >=20 >=20 > On 11/24/23 01:49, waffl3x wrote: >=20 > > > and this in tsubst_lambda_expr that assumes iobj: > > >=20 > > > /* Fix the type of 'this'. */ > > > fntype =3D build_memfn_type (fntype, type, > > > type_memfn_quals (fntype), > > > type_memfn_rqual (fntype)); > >=20 > > Unfortunately, putting a condition on this had some unforeseen > > consequences. I've been working on this about 8 hours today and I'm a > > little defeated after discovering this. > >=20 > > commit 39ade88fa1632c659c5c4ed065fa2b62d16a8670 > > Author: Jason Merrill jason@redhat.com > > Date: Tue Jan 24 15:29:35 2023 -0500 > >=20 > > c++: static lambda in template [PR108526] > >=20 > > tsubst_lambda_expr uses build_memfn_type to build a METHOD_TYPE for the= new > > lamba op(). This is not what we want for a C++23 static op(), but since= we > > also use that METHOD_TYPE to communicate the closure type down to > > tsubst_function_decl, let's wait and turn it back at that point. > >=20 > > PR c++/108526 > >=20 > > gcc/cp/ChangeLog: > >=20 > > gcc/cp/ChangeLog: > >=20 > > * pt.cc (tsubst_function_decl): Handle static lambda. > >=20 > > gcc/testsuite/ChangeLog: > >=20 > > * g++.dg/cpp23/static-operator-call5.C: New test. > >=20 > > diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc > > index 2a4d03c5e47..51fc246ed71 100644 > > --- a/gcc/cp/pt.cc > > +++ b/gcc/cp/pt.cc > > @@ -14306,6 +14306,11 @@ tsubst_function_decl (tree t, tree args, tsubs= t_flags_t complain, > > tree ctx =3D closure ? closure : DECL_CONTEXT (t); > > bool member =3D ctx && TYPE_P (ctx); > >=20 > > + /* If this is a static lambda, remove the 'this' pointer added in > > + tsubst_lambda_expr now that we know the closure type. */ > > + if (lambda_fntype && DECL_STATIC_FUNCTION_P (t)) > > + lambda_fntype =3D static_fn_type (lambda_fntype); >=20 >=20 > Ah, right. So the simplest thing would be to do the same thing here for > xob lambdas. >=20 > Jason