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 88111386CE47 for ; Wed, 22 Nov 2023 22:45:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 88111386CE47 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 88111386CE47 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=1700693129; cv=none; b=ZBGBCnjIGATKgaKY6MfhbDkV67ZkBtI0iJmgaFeRfNrtvzviTfr4OHgcY+lqDyEz5D48fBqLBzsfrGndslxjyJzvxN20mJmFlb2gKW0NEFE7ftebsk5RXM5u2KMuQbyNJLhawRis9r8HOXTp8wF9yIC8QND6kXSBa1N9PanALN8= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700693129; c=relaxed/simple; bh=1jeMObR6Li38sHKPDy0lY6YJfH6enSbeOo1m+b7Gjpk=; h=DKIM-Signature:Date:To:From:Subject:Message-ID:MIME-Version; b=k4Omgl2DVmXHi8QJWMYGUrhWWqOED5eQdfJywo4zLvxlxwWQcuFscmIvUDd+XgmCv90unDvnHT2+frwI7PgmH4tNqSJ1r7N1DWPunyhFZx5gDcGyF/Hw6hf2iwovswMf37BR13IomeoIdkes3KeXlLy2jtY9NlYJwDHzOSySfYQ= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from mail-40134.protonmail.ch ([185.70.40.134]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r5vy8-0004gl-1b for gcc-patches@gcc.gnu.org; Wed, 22 Nov 2023 17:45:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1700693081; x=1700952281; bh=1jeMObR6Li38sHKPDy0lY6YJfH6enSbeOo1m+b7Gjpk=; 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=JibHwZvtmGS4lTWErW7EW/GYubgE1hSxFkqYboiebTkV0JWiTalcxoSUSd7AE3lPw 34DzsuyUt3HGyUeS641s9k5iDVp85QDgxO1X1g82PzAKRWpYx+gA0O5UjMalhmHYOB 44HYSt9ZgIx4V3rKGl/DNte0EXVBv/HDhnCww5O/8PVXNMqCM3/B8TdtBwtvRuDmUN +NLRSe7WKSl4g2c1UaGzanG4qQym6KUmG/bD4WO0rW+UWqah+4NwmJyTAQWTcEu7nb hlQmNhWHtOfy4BgWfLWXk3c+tC9kwAgKWUs4FHJUKv2ZY7j1jTbpKhiBuSav6APutO W03Qpez8ySJOw== Date: Wed, 22 Nov 2023 22:44:34 +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: References: <9890a007-755e-41e2-bc33-37ebf0755435@redhat.com> <1MdaTybBd_o4uw-Gb23fYyd5GNz7qFqoSe_f5h90LY_BdzM2ge2qPSyCuiCLYoYcZSjmVv13fw1LmjQC_M2L8raS1fydY5pEJ_vwvv5Z-0k=@protonmail.com> <9OlK_2c3Punfm3w-wEHqyHGyKGG8Gr_K0BUnDOuC9Aazur4mWlAM5WuL1Ea0AMLvFLl6LKFVTs813yY0zA7m0_ji_R9qhE52G7MZXrVPfZE=@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.134; envelope-from=waffl3x@protonmail.com; helo=mail-40134.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,RCVD_IN_MSPIKE_H5=0.001,RCVD_IN_MSPIKE_WL=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.4 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: > > > > /* Nonzero for FUNCTION_DECL means that this decl is a non-static > > > > - member function. */ > > > > + member function, use DECL_IOBJ_MEMBER_FUNC_P instead. */ > > > > #define DECL_NONSTATIC_MEMBER_FUNCTION_P(NODE) \ > > > > (TREE_CODE (TREE_TYPE (NODE)) =3D=3D METHOD_TYPE) > > > >=20 > > > > +/* Nonzero for FUNCTION_DECL means that this decl is an implicit o= bject > > > > + member function. */ > > > > +#define DECL_IOBJ_MEMBER_FUNC_P(NODE) \ > > > > + (TREE_CODE (TREE_TYPE (NODE)) =3D=3D METHOD_TYPE) > > >=20 > > > I was thinking to rename DECL_NONSTATIC_MEMBER_FUNCTION_P rather than > > > add a new, equivalent one. And then go through all the current uses o= f > > > the old macro to decide whether they mean IOBJ or OBJECT. > >=20 > > I figure it would be easier to make that transition if there's a clear > > line between old versus new. To be clear, my intention is for the old > > macro to be removed once all the uses of it are changed over to the new > > macro. I can still remove it for the patch if you like but having both > > and removing the old one later seems better to me. >=20 >=20 > Hmm, I think changing all the uses is a necessary part of this change. > I suppose it could happen before the main patch, if you'd prefer, but it > seems more straightforward to include it. >=20 I had meant to reply to this as well but forgot, I agree that it's likely necessary but I've only been changing them as I come across things that don't work right rather than trying to evaluate them through the code. Making changes to them without having a test case that demonstrates that the case is definitely being handled incorrectly is risky, especially for me since I don't have a full understanding of the code base. I would rather only change ones that are evidently wrong, and defer the rest to someone else who knows the code base better. With that said, I have been neglecting replacing uses of the old macro, but I now realize that's just creating more work for whoever is evaluating the rest of them. Going forward I will make sure I replace the old macro when I am fairly certain it should be. Alex