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 33EE33858D33 for ; Wed, 18 Oct 2023 11:46:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 33EE33858D33 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 33EE33858D33 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=1697629594; cv=none; b=nbWG1O22Slu5YA2hc2oyeVqLN4pPnLiLP2BbTWtCTMt+FlbJn3cW8BCirqNLPWRluNTyrd6i6D9n398u3guSrouxlAknQbZKvZTWigAW07xLVs0ezZu9JHOW05hPSnA3QZg8MRBXQ80YOKJIHZNLfgW3ud2ACR1AzloM4xyPlkg= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1697629594; c=relaxed/simple; bh=d4qQEULYeg6owvsoCf7nNa+9Nbufrt55Vq9Z9+xfSC8=; h=DKIM-Signature:Date:To:From:Subject:Message-ID:MIME-Version; b=ksBkZaux4OKWYZfIIRG7v6NmD0wEZQYOcWKe/Z7zWKvkfTHWbiuJ3RGkM/qXswup29fxfyVKi9bruPnczmr7cXN1QKsOBHMtl7kj3wKROXjvMFtMWzcYEIb+gZYFdfzKPknGNoTZdTA74OmuQOz4iu3pbKoQcBT7ck3xapGbQKQ= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1697629591; x=1697888791; bh=4aFSWIp0mIOr18grX8HjTuICiIVqBGoWPVf6W6jjUAM=; 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=Obxyn+j5wOJLZ9b/uQ3cWR4qGV0ESyhtsSPAY4e1tfkbhpTNeOcmqYhI/hWAttu5X GGPnSZ6JhH/I0EplyLOVEIPJaUHCFD+LvEGrcz74tbGHkQAvRVlUBC7MaM/e+3UIvQ BEyPoXUFKsn8bMCvviWF7TAIAv3wLxPtY5mojJukdEbtW2vGk6sKqeJx4LIlTmkMvK aXDxk+cz/rt0CocISXKHmKZlE40veNY967lxrLBqvgP740xWzVRBowVcwJ7Dn8od1K 4BhLGEgCyMGaztyjOZAwFrTJngW/XO+HhvMQsgSA+PjDyyY+s2ja/oLEq1SMioHtbk dSa48A3MaRRFg== Date: Wed, 18 Oct 2023 11:46:18 +0000 To: Jason Merrill From: waffl3x Cc: Jakub Jelinek , "gcc-patches@gcc.gnu.org" Subject: Re: [PATCH v3 1/2] c++: Initial support for P0847R7 (Deducing This) [PR102609] Message-ID: In-Reply-To: References: <3ec4cf47-ccd8-fc55-c4fc-d97402552b92@redhat.com> <9evl-z9cAecBNAGVh82igdeO_HCFYbASO5fS0ngotJBqdpab09FTYaMiAjlZUliISedO0mV66BldzWQtylI4Dax0yC2gdKWuM55xDaG6RQM=@protonmail.com> <09e57c81-5231-16e8-6e57-18c37663c325@redhat.com> <2024d9f2-7560-eb9e-e9d9-de8769a06a8b@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,TXREP 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: > Any progress on this, or do I need to coax the process along? :) Yeah, I've been working on it since the copyright assignment process has finished, originally I was going to note that on my next update which I had hoped to finish today or tomorrow. Well, in truth I was hoping to send one the same day that copyright assignment finished, but I found a nasty bug so I spent all day adding test cases for all the relevant overloadable operators. Currently, it crashes when calling a subscript operator declared with an explicit object parameter in a dependent context. I haven't looked into the fix yet, but I plan to. Also, before I forget, what is the process for confirming my copyright assignment on your end? Do you just need to check in with the FSF to see if it went through? Let me know if there's anything you need from me regarding that. Aside from the bug that's currently present in the first patch, I only have like 1 or 2 little things I want to change about it. I will make those few changes to patch 1, finish patch 2 (diagnostics) which will also include test cases for the new bug I found. After I am done that I plan on adding the things that are missing, because I suspect that looking into that will get me close to finding the fix for the crash. > Hmm, is it? I see that clang thinks so, but I don't know where they get > that idea from. The grammar certainly allows it: >=20 > > attribute-specifier-seqopt decl-specifier-seq declarator =3D initialize= r-clause >=20 >=20 > and I don't see anything else that prohibits it. You would be right for P0847R7, but CWG DR 2653 changed that. You can find the updated grammar in dcl.fct section 3 (subsection? I'm not really sure to be honest.) I've also included a copy of the grammar here for your convenience. https://eel.is/c++draft/dcl.fct#nt:parameter-declaration parameter-declaration: attribute-specifier-seqopt thisopt decl-specifier-seq declarator attribute-specifier-seqopt decl-specifier-seq declarator =3D initializer-= clause attribute-specifier-seqopt thisopt decl-specifier-seq abstract-declarator= opt attribute-specifier-seqopt decl-specifier-seq abstract-declaratoropt =3D = initializer-clause=20 > I was thinking to set a TREE_LANG_FLAG on the TREE_LIST node. I did figure this is originally what you meant, and I can still change it to go this route since I'm sure it's likely just as good. But I do recall something I didn't like in the implementation that nudged me towards using the purpose member instead. Either way, not a big deal. I think I just liked not having to mess with a linked list as I am not used to them as a data structure, it might have been that simple. :^) I will try to get something done today, but I was struggling with writing some of the tests, there's also a lot more of them now. I also wrote a bunch of musings in comments that I would like feedback on. My most concrete question is, how exactly should I be testing a pedwarn, I want to test that I get the correct warning and error with the separate flags, do I have to create two separate tests for each one? I'm just going to include the little wall I wrote in decl.cc regarding pedwarn, just in case I can't get this done tonight so I can get some feedback regarding it. On the other hand, it might just not be very relevant to this patch in particular as I kind of noted, but maybe there's some way to do what I was musing about that I've overlooked. It does end up a bit ranty I guess, hopefully that doesn't make it confusing. ``` /* I believe we should make a switch for this feature specifically, I recall seeing discussion regarding enabling newer language features when set to older standards. I would advocate for a specific flag for each specific feature. Maybe they should all be under an override flag? -foverride-dialect=3Dxobj,ifconstexpr (?) I dont think it makes sense to give each feature override it's own flag. I don't recall what the consensus was around this discussion either though. For the time being it's controlled by pedantic. I am concerned that tying this to pedantic going forward that one might want to enable -pedantic-errors while also enabling select features from newer dialects. It didn't look like this use case is supported to me. I suppose this will require redesign work to support, so for the purposes of this patch, emitting a pedwarn seems correct. I just don't like that it can't be suppressed on an individual basis. */ if (xobj_parm && cxx_dialect < cxx23) pedwarn(DECL_SOURCE_LOCATION (xobj_parm), OPT_Wpedantic, ""); ``` That's all for now, I will try, (but I am very much not promising,) to have an update by the end of today (6-8 hours for me.) If I manage to get that out, I will (finally) start moving forward on implementing the missing and broken features, and the aforementioned bug. Alex