From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22]) by sourceware.org (Postfix) with ESMTPS id 74C9038582B7 for ; Tue, 28 Nov 2023 03:31:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 74C9038582B7 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 74C9038582B7 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=185.70.43.22 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701142280; cv=none; b=qs19BmEd+6lSwiTC7nV+Y+y2nAq0+t3ZP5V7uqBkE/yxlZa0rX3FiQz0Z+czlM9vfQfTFY2EYzaaUBYFJzVUA5sWmdXhhOlhDvA7ht40dDpn54ygvdogkgcXR/mJHmq/yUQI8v7O7qV+w1dd6h2nwptcGZu1dfjfjGFhQv+A3HE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701142280; c=relaxed/simple; bh=xTu9zDZahJBjN6pH70Z6jRgf6QeOC9QdhIlvy3adVYg=; h=DKIM-Signature:Date:To:From:Subject:Message-ID:MIME-Version; b=tmIrFHe0uPnEuQzqKYFxXBouMaXuMv1kHIrCWSR+UBlaShDT2rD7puZIBINAq4mjCd3BQVAdzUu46iVjrPI/K8WPd7K4HvgdoOlaGRJ389E2cK0sI08zRF0o5PQXUmnKfXOY+ssQ6sUfE/9ORs10dTHZDcZil79IAYF4c75nTtA= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1701142278; x=1701401478; bh=xTu9zDZahJBjN6pH70Z6jRgf6QeOC9QdhIlvy3adVYg=; 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=s7Ho6J+RSXZzOvlWkRSzGiDCWC8YkG1e77mhGYXvfVmFT3WCTkhWMYxcoHIKDewgJ uKJGQZBtg0jTYjmYhpZMX1Tsst5T790Ze7oaC0vRxGR30FQXX44e7xY05AiVOLpVwP Vb3v7AU3ky9kFtrxw/Ks3n1HN++O84oeARxw/L30NkhWmKw9guOwzqrbVuQJMTexS4 cIQJLzjVgW6EhT3+qcwWLKOMacxjLuvI7GO+aGlqrAQV+J24K1hX92e6hBr3SVEtUp U0q/gAZvDCAZ24swsuGhVd+H1sy4PihXtTVHmLoYR70BA8XK9hFe5LrmaujOUqRYYN HABTOII0i85Rw== Date: Tue, 28 Nov 2023 03:31:07 +0000 To: waffl3x From: waffl3x Cc: Jason Merrill , "gcc-patches@gcc.gnu.org" Subject: Re: [PATCH v6 1/1] c++: Initial support for P0847R7 (Deducing This) [PR102609] Message-ID: In-Reply-To: References: =?us-ascii?Q?____<7Xr5Vil7ptZzPaCtc=5FZCdcTPuUVY7dheOnklF-vVDb5=5Fjl8PivYWgTT=5Ff3cKLvg7IMnDruCDDrICRI6WVrUT3f8ZScGKAh4ATIkYSuRqPZc=3D@protonmail.com>__<-SP7aKgN1FZED-RAPr2FBDuCrcwnu9-UhHcRXNEsNZRwIzJXCdhVbtBP921Yn8g71d0WL7XpFRetUlBAStzRpZB8p4yj5moRS0DIE9D6cnY=3D@protonmail.com>_<7623e2db-ba29-42f2-85df-c2e796d7305b@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=-1.8 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=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Sunday, November 26th, 2023 at 7:40 PM, Jason Merrill = wrote: >=20 >=20 > On 11/26/23 20:44, waffl3x wrote: >=20 > > > > > > The other problem I'm having is > > > > > >=20 > > > > > > 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. > > > > > >=20 > > > > > > 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)(); > > > > >=20 > > > > > That sounds correct, why would this be an error? > > > > >=20 > > > > > The constness of the captures doesn't depend on LAMBDA_EXPR_MUTAB= LE_P, > > > > > it depends on the type of the object parameter, which in this cas= e is > > > > > non-const, so so are the captures. > > > >=20 > > > > Oops, I should have just made a less terse example, you missed the > > > > "as_const" in the call to the lambda. The object parameter should b= e > > > > deduced as const here. I definitely should have made that example > > > > better, my bad. > > >=20 > > > Ah, yes, I see it now. > >=20 > > I don't remember if I relayed my planned fix for this to you. My > > current idea is to modify the tree during instantiation of the lambda's > > body somewhere near tsubst and apply const to all it's members. This is > > unfortunately the best idea I have so far and it feels like an awful > > hack. I am open to better ideas, but I don't think we can do anything > > until the template is instantiated so I think it has to be there. >=20 >=20 > I think the answer should be in lambda_proxy_type. The case where we > build a DECLTYPE_TYPE may need to be expanded to cover this situation. >=20 > > Should I wait until I fix the issue in tsubst_lambda_expr before > > submitting the patch? I'm fine to do it either way, just whatever you > > prefer. If I finish cleaning up these tests before I hear back I'll go > > ahead and submit it and then start looking at different solutions in > > there. >=20 >=20 > Go ahead and submit. >=20 > Jason I'm going to need to sit down and set up a proper e-mail application once I'm done with all this, I missed your reply because it went off to another thread. Luckily, I decided to send the patch anyway, and when I noticed that my patch was not under the same thread I came looking for it. Ah well, what a pain, I guess getting used to these mail list things is just going to take time. > > It doesn't. The issue is messing with the type of (potentially) a lot > > of different functions. Even if it doesn't actually break anything, it > > seems like the kind of hidden mutation that you were objecting to. >=20 >=20 > Oh... yeah..., I see the issue now. I still don't think the solution > used for static lambdas will work, or be painless anyhow, but if I > can't find something better I will try to use that one. >=20 > > > Well, even so, I can just clear it after it gets used as we just need > > > it to pass the closure type down. Perhaps I should have led with this= , > > > but as it stands the version that uses TYPE_METHOD_BASETYPE bootstrap= s > > > with no regressions. I'll still look deeper but I'm pretty confident = in > > > my decision here, I really don't want to try to unravel what > > > build_memfn_type does, I would rather find a whole different way of > > > passing that information down. > >=20 > > But the existing code already works fine, it's just a question of > > changing the conditions so we handle xob lambdas the same way as static= . >=20 >=20 > I'm still concerned it wont cooperate with xobj parameters of unrelated > type, but like I said, you've indicated my solution is definitely wrong > so I'll look at fixing it. I spent some time looking at it, I've decided you're probably right that handling this the same way as the static lambda case is the best in the short term. I still don't like it, but I've gone ahead and made that change, and it seems to work just fine. I still find it icky, but once I realized we do in fact need lambda_fntype since it might have been substituted into in tsubst_lambda_expr, I don't see any better way of doing this at the moment. Since the added parameter just gets popped off by static_fn_type, and tsubst_lambda_expr doesn't touch the xobj parameter, I'm pretty sure it should behave properly. So no problems I guess, moving on to the captures bug. Alex