From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 6EA733858D1E for ; Tue, 5 Dec 2023 05:55:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6EA733858D1E Authentication-Results: sourceware.org; dmarc=fail (p=quarantine dis=none) header.from=protonmail.com Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=protonmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 6EA733858D1E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:470:142:3::10 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701755728; cv=none; b=kX03bboBnyzNmJOFz2nNO5mi+1Ax+Ucup//T885rxoh/P7cHpttYddSoWPF9bWQmnNDE27aYs1OwkrxbEhH28npGxohep9M1wU/uiy06lreEn6Z6Gunas7RU2lKPNB1CNEt3IbV3c2zPBH1lFdb0iOthm7Pj9KtZNAsiuSHpssE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701755728; c=relaxed/simple; bh=kwAPNd/r3AmY0CYD4X+wU1oshDWqUSSHQ7j1XULdkmU=; h=DKIM-Signature:Date:To:From:Subject:Message-ID:MIME-Version; b=KLtWuqs6kJOvrkk87lQOfO8mX6sYphGawa7noT4G1UoDLEt05dXId1aEWu68E04JgLdojZ4Kg7ISDcHEYmDvQUPAPns+RwxuKc5eBkGDCwwww4lx6LBfIsZEUMjUrYJ/LqwdPvN04bLOmIoVGBZoa/F3KspmVeCEp/R4/mHP4F4= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from mail-40131.protonmail.ch ([185.70.40.131]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rAOOe-0008Aw-Vp for gcc-patches@gcc.gnu.org; Tue, 05 Dec 2023 00:55:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1701755663; x=1702014863; bh=kwAPNd/r3AmY0CYD4X+wU1oshDWqUSSHQ7j1XULdkmU=; 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=mCG1PPrQIYwfvSQs+4Tq9lQ982H9ho7JUZKdQTWo29uYKOItLx3Xg76BWXHJue6u1 B0lfeEgrB1oHGNUU7/1djMJ6JCz6Wdp7tY+t/q/u29/PUnTChU0d72earG0iri31BI z7TdcBUWIAb0KuvYdO9CEP1B98rxs85mZQWwDTc/aRPWG6sZk8GffNTE0R/LRxupsP i9vttK8pDlGx7fVmL+d3KKnSrWY9ekcye3B4jc4grX/QrAQsrJky0axT8yA/0O7EBA mu5RHlap29sbPaVQ8PQuiRDIKAayMPu74H6b/J3QYEOA9ltGc5UrUGuSqG2DGYTAr9 QUQNzfktSSiWg== Date: Tue, 05 Dec 2023 05:54:10 +0000 To: Jason Merrill From: waffl3x Cc: "gcc-patches@gcc.gnu.org" Subject: Re: [PATCH v6 1/1] c++: Initial support for P0847R7 (Deducing This) [PR102609] Message-ID: <61NBWPmN34lD25i-dND5emZReJ7UbgkAcSiy1eYvjwWO9ALSTArJ4NWvOqN5UDOvbmr_dTNdRFNBCkpuu5eL41dHdZfNcqH4UZru7JK2k50=@protonmail.com> In-Reply-To: <59LofhYhxl7MLEuElXwZcESRB6MpjdG-iq-89B63siDRo5k0j-y6z-PVa6Y3iE1xE5LkJwpwTFi82bd0RZjB1yZbSJptFdPTBWfvOGj1W78=@protonmail.com> References: <_e1O52EjoN_BFiH31iHE-0eYegNJhoOdDN2O0mduqtMmt7qTGpRWgduxNppnO1si01rORJ470oWcoM-_lk1ICFo9lhe_ylBKQsJ791qMm_k=@protonmail.com> <1b3b0259-5ce4-4193-a36d-60f09e1c7c92@redhat.com> <575c0bbe-a3d6-4a54-b299-edff64df84b1@redhat.com> <59LofhYhxl7MLEuElXwZcESRB6MpjdG-iq-89B63siDRo5k0j-y6z-PVa6Y3iE1xE5LkJwpwTFi82bd0RZjB1yZbSJptFdPTBWfvOGj1W78=@protonmail.com> Feedback-ID: 14591686:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=185.70.40.131; envelope-from=waffl3x@protonmail.com; helo=mail-40131.protonmail.ch X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9,DKIM_SIGNED=0.1,DKIM_VALID=-0.1,DKIM_VALID_AU=-0.1,DKIM_VALID_EF=-0.1,FREEMAIL_FROM=0.001,SPF_HELO_PASS=-0.001,SPF_PASS=-0.001,T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,SPF_HELO_PASS,SPF_SOFTFAIL,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 Monday, December 4th, 2023 at 9:39 PM, waffl3x = wrote: > On Monday, December 4th, 2023 at 9:35 PM, waffl3x waffl3x@protonmail.com = wrote: > > > > > > > @@ -15402,6 +15450,8 @@ tsubst_decl (tree t, tree args, tsubst_flag= s_t complain, > > > > > > gcc_checking_assert (TYPE_MAIN_VARIANT (TREE_TYPE (ve)) > > > > =3D=3D TYPE_MAIN_VARIANT (type)); > > > > SET_DECL_VALUE_EXPR (r, ve); > > > > + if (is_capture_proxy (t)) > > > > + type =3D TREE_TYPE (ve); > > > > > That should have close to the same effect as the lambda_proxy_type > > > adjustment I was talking about, since that function basically returns > > > the TREE_TYPE of the COMPONENT_REF. But the underlying problem is tha= t > > > finish_non_static_data_member assumes that 'object' is '*this', for > > > which you can trust the cv-quals; for auto&&, you can't. > > > capture_decltype has the same problem. I'm attaching a patch to addre= ss > > > this in both places. > > > > Regarding this, was my change actually okay, and was your change > > supposed to address it? I applied my patch to the latest commit in > > master yesterday and started tests and whatnot with this change > > commented out as I wasn't sure. It seems like my tests for constness of > > captures no longer works with or without this change commented out. > > > > If you wish I can go over everything again and figure out a new > > solution with your changes but stepping through all this code was quite > > a task that I'm weary of doing again. Even if the second time through > > won't be so arduous I would like to avoid it. > > > > You know what, I'll give it a go anyway but I don't want to spend too > > much time on it, I still have a few tests to clean up and this crash to > > fix. > > > > template void f() > > > > { > > int i; > > [=3D](this T&& self){ return i; }(); // error, unrelated > > } > > int main() { f(); } > > > > If this crash doesn't take too long (I don't think it will, it seems > > straightforward enough) then I'll look at fixing the captures with a > > const xobject parameter bug the correct way. > > > > Alex > > > WAIT Scratch that, I made a mistake, there's only a single case that is > broken, I read the test log wrong. Ah, I swear I'm cursed to realize > things the moment I hit the send button. > > I have to take a closer look, I'll get back to you when I know more, > just trying to make sure you don't waste your time on this due to my > mistake. > > Alex tl;dr it wasn't important, I just have to fix my test. Okay that was faster than I anticipated, but unfortunately I don't know how to handle it. I think your change in finish_non_static_data_member might have been too heavy handed, but I don't know if there's a middle ground. Or that's what I was going to say until I tested my assumption on godbolt. void f(auto const& a) { a =3D 5; } Clang, MSVC and GCC all accept this until it is actually instantiated. So, the true answer to my test failing is to just instantiate the template. The test in question that was failing looks like this. auto f2 =3D [n =3D 5](this auto const&){ n =3D 10; }; // { dg-error {} } With the way things were before, this actually worked, so what my assumption is now is that for us to actually diagnose this before a template is instantiated would take some significant reworking of how things are currently done. AND, I don't even know if it's legal for us to make this diagnostic before instantiation for either of these cases. Hah, come to think of it, we can't, there could be an overloaded operator=3D that this is valid for... how disappointing. We can for lambdas since the type is not dependent (on the lambda instantiation) but it just isn't worth the effort I reckon. Whatever, moving on, spending time on these things always drains me because I think "oh boy I can do something better" and finding out it's just not possible sucks. It's worse when it's because I overlooked something that's obvious in hindsight. Oh well, only that crash left I believe. Alex