From unknown Sat Jun 21 05:16:31 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#59213 <59213@debbugs.gnu.org> To: bug#59213 <59213@debbugs.gnu.org> Subject: Status: Emacs 29: Edebug fails to instrument a parameter whose name begins with _ Reply-To: bug#59213 <59213@debbugs.gnu.org> Date: Sat, 21 Jun 2025 12:16:31 +0000 retitle 59213 Emacs 29: Edebug fails to instrument a parameter whose name b= egins with _ reassign 59213 emacs submitter 59213 Alan Mackenzie severity 59213 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 12 04:36:17 2022 Received: (at submit) by debbugs.gnu.org; 12 Nov 2022 09:36:17 +0000 Received: from localhost ([127.0.0.1]:47336 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1otmvx-0003kH-5b for submit@debbugs.gnu.org; Sat, 12 Nov 2022 04:36:17 -0500 Received: from lists.gnu.org ([209.51.188.17]:59520) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1otmvw-0003kA-8i for submit@debbugs.gnu.org; Sat, 12 Nov 2022 04:36:16 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1otmvv-0008FA-A2 for bug-gnu-emacs@gnu.org; Sat, 12 Nov 2022 04:36:16 -0500 Received: from mx3.muc.de ([193.149.48.5]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1otmvt-0005xS-6n for bug-gnu-emacs@gnu.org; Sat, 12 Nov 2022 04:36:15 -0500 Received: (qmail 85735 invoked by uid 3782); 12 Nov 2022 10:35:59 +0100 Received: from acm.muc.de (p4fe15c31.dip0.t-ipconnect.de [79.225.92.49]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 12 Nov 2022 10:35:59 +0100 Received: (qmail 3373 invoked by uid 1000); 12 Nov 2022 09:35:58 -0000 Date: Sat, 12 Nov 2022 09:35:58 +0000 To: bug-gnu-emacs@gnu.org Subject: Emacs 29: Edebug fails to instrument a parameter whose name begins with _ Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.5; envelope-from=acm@muc.de; helo=mx3.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) Hello, Emacs. In Emacs 29 (not started with -Q, but...), I instrumented for edebug a function which looked like: (defun c-trim-found-types (beg end _old-len) ....) , the compilation being with lexical-binding: t. During the edebug session, I attempted e _old-len RET. Instead of giving me the value of _old-len (which was 3) it gave the error message Error: Symbol's value as variable is void: _old-len .. This is a bug. Just because a function doesn't use a particular argument (here _old-len) doesn't mean the person debugging it isn't interested in its value. In this particular case, it was extremely interesting, because beg and end were unequal, and _old-len was 3. In the end, I found out the info with the d command (backtrace), but I shouldn't have to. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 13 21:49:06 2022 Received: (at 59213) by debbugs.gnu.org; 14 Nov 2022 02:49:06 +0000 Received: from localhost ([127.0.0.1]:48737 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ouPWy-0002HU-Ld for submit@debbugs.gnu.org; Sun, 13 Nov 2022 21:49:06 -0500 Received: from mout.web.de ([212.227.17.11]:59853) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ouPWs-0002Gv-E7 for 59213@debbugs.gnu.org; Sun, 13 Nov 2022 21:49:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=s29768273; t=1668394126; bh=Tkycd0qUa4Yeu48X0+pqgbMa+qTEIcUU/D0OhwbOz8Y=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date; b=Hu/SStRYG0+P6/NBQ0QSvnS+/xEGhUirF+cXO7PcfBcNlJLu94sVSG6+NiNTL+F/G v2zlgQS0MDCdwS+D+3zPtAFdWvqkSSJqhN+lozn6bpvvCezkB8YZU7E9QXAXfIoKPL hyjNVgJ6h6T3ZH8WXTa/NXTmptePbR8iMlwwXM54qmMS40JC6m3/i+bQClvsX3Vp6G hBfrx39RknbYyMQoYAKj3IOWtlXOnRDQpldO9kHDgWbyFEwGElN7oEo63KVmF13CKj Hexp1uZrwxh7JTE135XQuan3T5Y0YUKfv+Tma/8tB/HjiHi6fRyCvm1n1UZWRWJmWU y2s6FWucMvMfQ== X-UI-Sender-Class: 814a7b36-bfc1-4dae-8640-3722d8ec6cd6 Received: from drachen.dragon ([88.66.71.129]) by smtp.web.de (mrweb106 [213.165.67.124]) with ESMTPSA (Nemesis) id 1MLAVc-1odQuC2G4Q-00IN55; Mon, 14 Nov 2022 03:48:46 +0100 From: Michael Heerdegen To: Alan Mackenzie Subject: Re: bug#59213: Emacs 29: Edebug fails to instrument a parameter whose name begins with _ In-Reply-To: (Alan Mackenzie's message of "Sat, 12 Nov 2022 09:35:58 +0000") References: Date: Mon, 14 Nov 2022 03:48:45 +0100 Message-ID: <87h6z2tfn6.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:S++hxiCtFKrSgVaKjzp3xy2v9Ar0tF0C5jlTLcXTNmz9AuQ4lcU 7Dq93aOmNhtLd5Qrg4sbvXyPYL7xnJknHCRWVLuyIcnMlvEZYDRLSyL7Q25k0xz3/wYolc9 Xhv/s3QAMox/Nr5DSXwSfwnUfbA455Nx118YdwnUqeG0BUdEw4eXgr/TbMRKVfwwuZY84d6 9PcxDezp8B+sRx5OaVDCQ== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:zWPOT1EgiR4=;hOMhJLTXgGoZb9PtyACVbE7i/gD bcoKxjo9OmrjEYzPArn27HrG9CVv/qhNClBbQHAzUKN2Had13KDjAKTjE46tHhLw/aMepernv SkLVzslBoExN4oefg0mH0NcEYlPpviu8SgM99xD9kVV2UQxrYxwuNbkMte9XsnYyuEY756t+X 2y7dZmj8OwRpD5Qpn3/yMoCI4htSR2ZZ6hehqf1AY1gkA43eLedu16iuJsSypqVfOuzoZz0QU /yaQVLLlzJM3y01F8oB4z++NKPS5awbM31OwB8gBxULjBBfaA5NwGFxOobkAiWDWob6ZumgvD J2jqyLu+FqwT41lV921TVzNuPIA5XV0h+u5i4uE7l11SVKAKJxrNtFoHq1k/aTVTNqDlNTq3z C+UTkRP7jW3bE/PH2O1aHuxyakjMeSJXBmA1iGTO8TMnEFNT3y4HJHenxg2ogb+WSxB0ZSD9r oW6rGMJbZ6bukkIkvHn6UtFU2wMSbnLZ4C7CkZTa6YaOzS18jN/6biWnxAIx6qAP99jAsuCHL wVayxV3tFdnMXCVkf6zBsC223x9Ardto160EX0cGN7caRaBGRwobLX5Ud802Uy/4y2RpwKF1t KjrAuHbaXNZ2ZrajM8Y47UayBVA7ZNIajat5htE3Rel5OOuQZSrS3xG9+2d2ndlnAfOYP0Wjb k/aPGPmZMzpNkJg1eOOeq5of35XEPp0OdWhdN9T+mJFJ7qxfEupikAceNuQvWCA2zZhVpRWS1 rLkWrTdszRWaFBIu1AeL2LDwG0wIHhq2e4/az8OIwm/WR7kz1L9VuN9J/MnCeXqRxf2aB5yGZ Z+pauQOolZ2ERteJZctFZs7GsjWxLaheiDYhv2d18sMI28kwAt6jUPSnAP2T3eE+Zd3mfQrft BbgfpFntI4IIhJZoavuBvKYyAMVDSfVS+8/v5zO/ki1rf8STeVpwBFz5t2M4V095f6be859xD XkiEiutRmTaryyW1RlFkyrQJx88= X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 59213 Cc: Stefan Monnier , 59213@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Alan Mackenzie writes: > During the edebug session, I attempted > > e _old-len RET. > > Instead of giving me the value of _old-len (which was 3) it gave the > error message > > Error: Symbol's value as variable is void: _old-len Here is a test case: (defun test (a b _c) (+ a b)) Instrument, etc., and e _c RET gives you the void variable error. I don't think this behavior is intended. When I change (defun edebug-eval (expr) (backtrace-eval expr 0 'edebug-after)) to (defun edebug-eval (expr) (backtrace-eval expr 1 'edebug-after)) ;; ^ a binding of _c is being printed. Let's CC Stefan who is the real expert and ask whether this change would make sense. I'm not sure when and in which frames a binding is or should be visible. Note: when _c is used in the function body a binding _is_ visible also in the 0th frame. Michael. From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 13 22:53:23 2022 Received: (at 59213) by debbugs.gnu.org; 14 Nov 2022 03:53:23 +0000 Received: from localhost ([127.0.0.1]:48782 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ouQXD-0003tz-8A for submit@debbugs.gnu.org; Sun, 13 Nov 2022 22:53:23 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:47754) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ouQXC-0003tj-Dk for 59213@debbugs.gnu.org; Sun, 13 Nov 2022 22:53:22 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 6E381805E3; Sun, 13 Nov 2022 22:53:16 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id CE00480401; Sun, 13 Nov 2022 22:53:14 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1668397994; bh=MkbJB4+qt3m+YOXOjRBqXWaR8ayvUf5p1yNqSgC15xA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Yax0PVntwBokxN5J3CRjWilMYGHLBQvP4iOzkWM0Tmz9zZA35l2Oj1TSY6S+exY0Y 2HwfwNMpNRhfKrSnV+NwGEJNHcGpq5ZeK181cZ2DsY0FqQpD/uvou1mhNuE3KS+lLV 3QN8NB5exGnSCvecnQUz4gwCYSxQi55FUvTaULlJ9s4TA6ATa0+RoTZVl6himtMcXA eNBrsQe3fbqXig3p8eGsDEtbyuAIvJBUpLUX+J0RfEyBQ6u2Xgj+R83Le/jmHcMT4K 2MmNKC1TciV59zKihH940Xpk2DUsgpHgQ4Sl7pHSOzvMRM4UeX2HVkkvR9OljZUXn3 gsvaznMiGS5Bw== Received: from pastel (unknown [104.247.241.157]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 9C80E120DCC; Sun, 13 Nov 2022 22:53:14 -0500 (EST) From: Stefan Monnier To: Alan Mackenzie Subject: Re: bug#59213: Emacs 29: Edebug fails to instrument a parameter whose name begins with _ In-Reply-To: (Alan Mackenzie's message of "Sat, 12 Nov 2022 09:35:58 +0000") Message-ID: References: Date: Sun, 13 Nov 2022 22:53:12 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.087 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 59213 Cc: 59213@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > In Emacs 29 (not started with -Q, but...), > > I instrumented for edebug a function which looked like: > > (defun c-trim-found-types (beg end _old-len) ....) > > , the compilation being with lexical-binding: t. > > During the edebug session, I attempted > > e _old-len RET. The behavior depends on where you are in the *Backtrace* buffer, because each line in the backtrace can be in a different lexical scope. So please clarify on which line you were when you did the above. > Instead of giving me the value of _old-len (which was 3) it gave the > error message > > Error: Symbol's value as variable is void: _old-len > > .. This is a bug. Could be. Or could be that you were trying to use `_old-len` in a lexical context where there is no such variable. > Just because a function doesn't use a particular argument (here I think the leading underscore is purely incidental and you'd get the same behavior with `beg` and `end`. Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 14 05:28:39 2022 Received: (at 59213) by debbugs.gnu.org; 14 Nov 2022 10:28:39 +0000 Received: from localhost ([127.0.0.1]:48963 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ouWhj-0005Uk-0E for submit@debbugs.gnu.org; Mon, 14 Nov 2022 05:28:39 -0500 Received: from mx3.muc.de ([193.149.48.5]:60400) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ouWhg-0005UX-LZ for 59213@debbugs.gnu.org; Mon, 14 Nov 2022 05:28:37 -0500 Received: (qmail 42307 invoked by uid 3782); 14 Nov 2022 11:28:30 +0100 Received: from acm.muc.de (p4fe15810.dip0.t-ipconnect.de [79.225.88.16]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 14 Nov 2022 11:28:29 +0100 Received: (qmail 4599 invoked by uid 1000); 14 Nov 2022 10:28:29 -0000 Date: Mon, 14 Nov 2022 10:28:29 +0000 To: Stefan Monnier Subject: Re: bug#59213: Emacs 29: Edebug fails to instrument a parameter whose name begins with _ Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 59213 Cc: 59213@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Stefan. On Sun, Nov 13, 2022 at 22:53:12 -0500, Stefan Monnier wrote: > > In Emacs 29 (not started with -Q, but...), > > I instrumented for edebug a function which looked like: > > (defun c-trim-found-types (beg end _old-len) ....) > > , the compilation being with lexical-binding: t. > > During the edebug session, I attempted > > e _old-len RET. > The behavior depends on where you are in the *Backtrace* buffer, because > each line in the backtrace can be in a different lexical scope. > So please clarify on which line you were when you did the above. I wasn't in the backtrace. I was stepping through the code in edebug. More precisely, with this defun: (defun add (a b _c) (+ a b)) , instrument it for edebug. Call M-: (add 1 2 6). The source code with active edebug now looks like: (defun add (a b _c) =>(+ a b)) .. e a now returns 1. e b returns 2. e _c gives the error message: Error: Symbol's value as variable is void: _c .. I repeat, this is a bug. It should have returned 6. > > Instead of giving me the value of _old-len (which was 3) it gave the > > error message > > Error: Symbol's value as variable is void: _old-len > > .. This is a bug. > Could be. Or could be that you were trying to use `_old-len` in > a lexical context where there is no such variable. _c is in the same lexical context as a and b, surely? > > Just because a function doesn't use a particular argument (here > I think the leading underscore is purely incidental and you'd get the > same behavior with `beg` and `end`. No, beg and end returned their values. I admit I'm speculating about the leading underscore, but I still say there's a bug, somewhere here. > Stefan -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 14 07:50:22 2022 Received: (at 59213) by debbugs.gnu.org; 14 Nov 2022 12:50:22 +0000 Received: from localhost ([127.0.0.1]:49098 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ouYus-0007UX-Gg for submit@debbugs.gnu.org; Mon, 14 Nov 2022 07:50:22 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:23587) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ouYur-0007UL-FQ for 59213@debbugs.gnu.org; Mon, 14 Nov 2022 07:50:21 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id B41EA10011A; Mon, 14 Nov 2022 07:50:15 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 48ED7100091; Mon, 14 Nov 2022 07:50:14 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1668430214; bh=p4Hp1MtgZUOGH36fPlveM0DnRUDg9wlesL9T9Kf1T5I=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=i73swm3BrqhbF1HYW/4lP7FJ+f7rek5S/xsyeXfCqxcRN5iZOJ8z5TJVHjVTToRWM wdO83JNRmU6zWBeGiAVd/NyWmnzv7Bmtsfr+UvEUxB24A541zRmK1qWxFt1eRroPJR HmuMQuTEfd6nM18Nz2/lLa/lsVCMvJr8P6F3Sej3p+1YbpRKa0tKAiOuHdWxx/+JWM 3NhZei5aYKlVjSa/hZ7uXBBkI1smefvf84HLg1d95DQijbO3mXXnTAI1Kq624zpG/c TlJEdafVTyijae6dcjlZx+uKKccomXk0R32dBwoSseu7mnkwtA1OVs5rdu0f1WDcTK CLAckNbsSA4cg== Received: from pastel (unknown [104.247.241.157]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 12181120247; Mon, 14 Nov 2022 07:50:14 -0500 (EST) From: Stefan Monnier To: Alan Mackenzie Subject: Re: bug#59213: Emacs 29: Edebug fails to instrument a parameter whose name begins with _ In-Reply-To: (Alan Mackenzie's message of "Mon, 14 Nov 2022 10:28:29 +0000") Message-ID: References: Date: Mon, 14 Nov 2022 07:50:13 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.061 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 59213 Cc: 59213@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> The behavior depends on where you are in the *Backtrace* buffer, because >> each line in the backtrace can be in a different lexical scope. >> So please clarify on which line you were when you did the above. > > I wasn't in the backtrace. I was stepping through the code in edebug. Oh, duh! I was misaligned, sorry. Let me reboot myself. I'll be back shortly. Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 14 07:56:44 2022 Received: (at 59213) by debbugs.gnu.org; 14 Nov 2022 12:56:45 +0000 Received: from localhost ([127.0.0.1]:49108 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ouZ12-0007dX-LN for submit@debbugs.gnu.org; Mon, 14 Nov 2022 07:56:44 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:33854) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ouZ11-0007dL-5S for 59213@debbugs.gnu.org; Mon, 14 Nov 2022 07:56:43 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id B9817440801; Mon, 14 Nov 2022 07:56:37 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 8A7F84407EA; Mon, 14 Nov 2022 07:56:36 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1668430596; bh=A4QU61IVsQGDwCsHduCytfewd1+wKLdNSnBUQuVBeAE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=gadoEBFcktWXBLQ+A+yK2L2wRJn3dFXh6SBND98hEmLDeoriRpuWJCvEIIkickb7E Aa9iHOaYg546r5jBxjAxcjn+nZ5rmiyohg6Cf+xpk4pEr30bhGKrruCGHS9ormFk6j Ey8BUcV3RqRs6Boc1yPXXuVfqaHIh2IZMn1bOo8EQvMTb2iGD1yUdYlMnHBGhFP1SH Kb43uBgZnU+9GrYYRAlxdfqetXw40eHfmCBiaFoQHmllx5mZwhJpEvmfogmx8FZfKm CbYyihPcqBalt6QXY72HwMySMSyncDyH1v9/Z6tCkq8k320MQEYxSElCwj+0pBwo8K sdPYHwN/D4XFw== Received: from pastel (unknown [104.247.241.157]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 3C2521201A4; Mon, 14 Nov 2022 07:56:36 -0500 (EST) From: Stefan Monnier To: Alan Mackenzie Subject: Re: bug#59213: Emacs 29: Edebug fails to instrument a parameter whose name begins with _ In-Reply-To: (Alan Mackenzie's message of "Mon, 14 Nov 2022 10:28:29 +0000") Message-ID: References: Date: Mon, 14 Nov 2022 07:56:34 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.055 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 59213 Cc: 59213@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > More precisely, with this defun: > > (defun add (a b c) > (+ a b)) > > , instrument it for edebug. Call M-: (add 1 2 6). > > The source code with active edebug now looks like: > > (defun add (a b c) > =>(+ a b)) > > .. `e a` now returns 1. `e b` returns 2. `e c` gives the error message: > > Error: Symbol's value as variable is void: c > > .. I repeat, this is a bug. It should have returned 6. [ Well, GDB does the same and claims it's not a bug, instead it says the variable has been optimized away or something to that effect. ] Agreed. Edebug should be careful to prevent unused vars from being optimized away. I'll try and come up with a good patch for that, Stefan From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 15 08:08:38 2022 Received: (at 59213) by debbugs.gnu.org; 15 Nov 2022 13:08:38 +0000 Received: from localhost ([127.0.0.1]:53352 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ouvg4-0001r5-V5 for submit@debbugs.gnu.org; Tue, 15 Nov 2022 08:08:38 -0500 Received: from eggs.gnu.org ([209.51.188.92]:55712) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ouvfv-0001qk-8T for 59213@debbugs.gnu.org; Tue, 15 Nov 2022 08:08:35 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ouvfp-0006fQ-K2; Tue, 15 Nov 2022 08:08:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=4yTNkN3FK5PxkE39mb4WtO1/aQprM6xTPKXYJT6hAsk=; b=I1utlMTXjlII GUchlrtuAWcEzdyJO+/B35qPin0VpYAb63b9eqVjAx1XC82oaSuvCsDzf09TcZIQa4XKRcMBwNgpU UF+NTymBR8pS3dHDfeeCx2iZxixBVkyQT0oA13gSVOcmHEgam00nYkVQvZRJ3hSdARpDpNBgqmGsH Wr3ARrnwUC4XvFLsy+6TkQ4qpIOjrg/JgMxA4G3Oy/akW+RyPbXKu9oJbuojGA/ErBvAtPOWgqCR3 8ehr7h/SSGWqpQPGOaidP2ijLZODjgFx36gISt5qg0SSGYGEH/ZBysdRttx15ya4EP/S1iSy2OKSv stlF1dLKFSmiST/wh4uZKw==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ouvfo-0007yU-Rz; Tue, 15 Nov 2022 08:08:21 -0500 Date: Tue, 15 Nov 2022 15:08:33 +0200 Message-Id: <83mt8sicvi.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (bug-gnu-emacs@gnu.org) Subject: Re: bug#59213: Emacs 29: Edebug fails to instrument a parameter whose name begins with _ References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 59213 Cc: acm@muc.de, 59213@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 59213@debbugs.gnu.org > Date: Sun, 13 Nov 2022 22:53:12 -0500 > From: Stefan Monnier via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > > In Emacs 29 (not started with -Q, but...), > > > > I instrumented for edebug a function which looked like: > > > > (defun c-trim-found-types (beg end _old-len) ....) > > > > , the compilation being with lexical-binding: t. > > > > During the edebug session, I attempted > > > > e _old-len RET. > > The behavior depends on where you are in the *Backtrace* buffer, because > each line in the backtrace can be in a different lexical scope. > So please clarify on which line you were when you did the above. > > > Instead of giving me the value of _old-len (which was 3) it gave the > > error message > > > > Error: Symbol's value as variable is void: _old-len > > > > .. This is a bug. > > Could be. Or could be that you were trying to use `_old-len` in > a lexical context where there is no such variable. Could you please document this in the "Edebug Eval" node of the ELisp reference manual? I don't think the text there has any hints about this subtle aspect. It should also be mentioned in "Backtraces" and in "Debugger Commands" (the latter says something vague about this, but it's too vague, IMO). TIA From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 10 13:51:48 2023 Received: (at 59213) by debbugs.gnu.org; 10 Feb 2023 18:51:48 +0000 Received: from localhost ([127.0.0.1]:38142 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pQYUu-0004fC-4G for submit@debbugs.gnu.org; Fri, 10 Feb 2023 13:51:48 -0500 Received: from mx3.muc.de ([193.149.48.5]:61624) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pQYUr-0004eu-EE for 59213@debbugs.gnu.org; Fri, 10 Feb 2023 13:51:47 -0500 Received: (qmail 49287 invoked by uid 3782); 10 Feb 2023 19:51:38 +0100 Received: from acm.muc.de (pd953a764.dip0.t-ipconnect.de [217.83.167.100]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 10 Feb 2023 19:51:38 +0100 Received: (qmail 29759 invoked by uid 1000); 10 Feb 2023 18:51:37 -0000 Date: Fri, 10 Feb 2023 18:51:37 +0000 To: Stefan Monnier Subject: Re: bug#59213: Emacs 29: Edebug fails to instrument a parameter whose name begins with _ Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 59213 Cc: 59213@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Stefan. On Mon, Nov 14, 2022 at 07:56:34 -0500, Stefan Monnier wrote: > > More precisely, with this defun: > > (defun add (a b c) > > (+ a b)) > > , instrument it for edebug. Call M-: (add 1 2 6). > > The source code with active edebug now looks like: > > (defun add (a b c) > > =>(+ a b)) > > .. `e a` now returns 1. `e b` returns 2. `e c` gives the error message: > > Error: Symbol's value as variable is void: c > > .. I repeat, this is a bug. It should have returned 6. > [ Well, GDB does the same and claims it's not a bug, instead it says the > variable has been optimized away or something to that effect. ] > Agreed. Edebug should be careful to prevent unused vars from being > optimized away. I'll try and come up with a good patch for that, I've been looking at this the past few days (actually, many days), and now understand what's happening. With an `add' instrumented for edebug, and evaluating `add', this causes edebug to create the form beginning "(function ...". Ffunction in eval.c delegates the creation of a closure to cconv-make-interpreted-closure. That function analyses `add', decides that c is not used, and thus creates a lexical environment containing bindings only for a and b. This last is the error. When instrumenting for edebug, EVERY lexical variable is potentially going to be read, so cconv-make-interpreted-closure should not remove any elements from the lexical environment. The included patch fixes this: edebug binds the (new) variable cconv-dont-trim-unused-variables to non-nil around the generated calls to edebug-enter. cconv-make-interpreted-closure tests this variable, and when non-nil it copies the lexical environment without change. Also, there's a consequential change in testcover.el, where it analyses the forms it is instrumenting, and needs to handle the new code around edebug-enter. This works. What do you think? diff --git a/lisp/emacs-lisp/cconv.el b/lisp/emacs-lisp/cconv.el index 570c9e66060..d61ff221ecb 100644 --- a/lisp/emacs-lisp/cconv.el +++ b/lisp/emacs-lisp/cconv.el @@ -113,6 +113,10 @@ cconv--interactive-form-funs (defvar cconv--dynbound-variables nil "List of variables known to be dynamically bound.") +(defvar cconv-dont-trim-unused-variables nil + "When bound to non-nil, don't remove unused variables from the environment. +This is intended for use by edebug and similar.") + ;;;###autoload (defun cconv-closure-convert (form &optional dynbound-vars) "Main entry point for closure conversion. @@ -834,10 +838,13 @@ cconv-analyze-form (define-obsolete-function-alias 'cconv-analyse-form #'cconv-analyze-form "25.1") (defun cconv-fv (form lexvars dynvars) - "Return the list of free variables in FORM. -LEXVARS is the list of statically scoped vars in the context -and DYNVARS is the list of dynamically scoped vars in the context. -Returns a pair (LEXV . DYNV) of those vars actually used by FORM." + "Return the free variables used in FORM. +FORM is usually a function #\\='(lambda ...), but may be any valid +form. LEXVARS is a list of symbols, each of which is lexically +bound in FORM's context. DYNVARS is a list of symbols, each of +which is dynamically bound in FORM's context. +Returns a cons (LEXV . DYNV), the car and cdr being lists of the +lexically and dynamically bound symbols actually used by FORM." (let* ((fun ;; Wrap FORM into a function because the analysis code we ;; have only computes freevars for functions. @@ -875,15 +882,24 @@ cconv-fv (cons fvs dyns))))) (defun cconv-make-interpreted-closure (fun env) + "Make a closure for the interpreter. +This function is evaluated both at compile time and run time. +FUN, the closure's function, must be a lambda form. +ENV, the closure's environment, is a mixture of lexical bindings of the form +(SYMBOL . VALUE) and symbols which indicate dynamic bindings of those +symbols." (cl-assert (eq (car-safe fun) 'lambda)) (let ((lexvars (delq nil (mapcar #'car-safe env)))) (if (null lexvars) ;; The lexical environment is empty, so there's no need to ;; look for free variables. + ;; Attempting to replace ,(cdr fun) by a macroexpanded version + ;; causes bootstrap to fail. `(closure ,env . ,(cdr fun)) ;; We could try and cache the result of the macroexpansion and ;; `cconv-fv' analysis. Not sure it's worth the trouble. - (let* ((form `#',fun) + (let* (newenv + (form `#',fun) (expanded-form (let ((lexical-binding t) ;; Tell macros which dialect is in use. ;; Make the macro aware of any defvar declarations in scope. @@ -896,11 +912,14 @@ cconv-make-interpreted-closure (pcase expanded-form (`#'(lambda . ,cdr) cdr) (_ (cdr fun)))) - - (dynvars (delq nil (mapcar (lambda (b) (if (symbolp b) b)) env))) - (fvs (cconv-fv expanded-form lexvars dynvars)) - (newenv (nconc (mapcar (lambda (fv) (assq fv env)) (car fvs)) - (cdr fvs)))) + + (dynvars (delq nil (mapcar (lambda (b) (if (symbolp b) b)) env)))) + (if cconv-dont-trim-unused-variables + (setq newenv (copy-alist env)) + (let ((fvs (cconv-fv expanded-form lexvars dynvars))) + (setq newenv + (nconc (mapcar (lambda (fv) (assq fv env)) (car fvs)) + (cdr fvs))))) ;; Never return a nil env, since nil means to use the dynbind ;; dialect of ELisp. `(closure ,(or newenv '(t)) . ,expanded-fun-cdr))))) diff --git a/lisp/emacs-lisp/edebug.el b/lisp/emacs-lisp/edebug.el index 2f7d03e9d79..735a358cdba 100644 --- a/lisp/emacs-lisp/edebug.el +++ b/lisp/emacs-lisp/edebug.el @@ -1217,16 +1217,16 @@ edebug-make-enter-wrapper (setq edebug-old-def-name nil)) (setq edebug-def-name (or edebug-def-name edebug-old-def-name (gensym "edebug-anon"))) - `(edebug-enter - (quote ,edebug-def-name) - ,(if edebug-inside-func - `(list - ;; Doesn't work with more than one def-body!! - ;; But the list will just be reversed. - ,@(nreverse edebug-def-args)) - 'nil) - (function (lambda () ,@forms)) - )) + `(let ((cconv-dont-trim-unused-variables t)) + (edebug-enter + (quote ,edebug-def-name) + ,(if edebug-inside-func + `(list + ;; Doesn't work with more than one def-body!! + ;; But the list will just be reversed. + ,@(nreverse edebug-def-args)) + 'nil) + (function (lambda () ,@forms))))) (defvar edebug-form-begin-marker) ; the mark for def being instrumented diff --git a/lisp/emacs-lisp/testcover.el b/lisp/emacs-lisp/testcover.el index ed31b90ca32..1212905f08a 100644 --- a/lisp/emacs-lisp/testcover.el +++ b/lisp/emacs-lisp/testcover.el @@ -442,6 +442,11 @@ testcover-analyze-coverage (let ((testcover-vector (get sym 'edebug-coverage))) (testcover-analyze-coverage-progn body))) + (`(let ((cconv-dont-trim-unused-variables t)) + (edebug-enter ',sym ,_ (function (lambda nil . ,body)))) + (let ((testcover-vector (get sym 'edebug-coverage))) + (testcover-analyze-coverage-progn body))) + (`(edebug-after ,(and before-form (or `(edebug-before ,before-id) before-id)) ,after-id ,wrapped-form) > Stefan -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 10 17:05:45 2023 Received: (at 59213) by debbugs.gnu.org; 10 Feb 2023 22:05:46 +0000 Received: from localhost ([127.0.0.1]:38242 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pQbWb-00017P-H0 for submit@debbugs.gnu.org; Fri, 10 Feb 2023 17:05:45 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:47636) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pQbWZ-000179-1Q for 59213@debbugs.gnu.org; Fri, 10 Feb 2023 17:05:44 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id B7F3D4414EE; Fri, 10 Feb 2023 17:05:36 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id B6F954414D4; Fri, 10 Feb 2023 17:05:34 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1676066734; bh=kNFrHUiaXzzddNTmiXGHeIQ4DgrhNPXREmUmCCSUxS4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=hBBkaqqvkH2whDjsT2xbHBRFVkuapEX5oxTmThjBe9XimqBPu0mXZwnGxBMX8bDnv mR3XKPj83qbBNIqwuG4Yb+FH206LR/v/cB1pdEYLKTyuv5PhBHHMOguLFSeldLmsIT rnx3sTvcvtB8kdWIHirITiPMGAo+RT2U9usmKzQjnmjqPPXDy8yYPZaYnExV0qN9o9 +hCcAaIG7ZM5LQKFUfeH8LAcqQgfx6YM2ENtaXNZuPiERoXiqxkElNbcX9AVVulkV+ aS8BMXzkA4Y+yhSGng5fmtD8W/QZDh/esSDeEt9bPv/TCETcEm4gsc73q7zgj3oTUX GZ2v7XpRS8azg== Received: from pastel (unknown [104.247.245.112]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 5DDE1120334; Fri, 10 Feb 2023 17:05:34 -0500 (EST) From: Stefan Monnier To: Alan Mackenzie Subject: Re: bug#59213: Emacs 29: Edebug fails to instrument a parameter whose name begins with _ In-Reply-To: (Alan Mackenzie's message of "Fri, 10 Feb 2023 18:51:37 +0000") Message-ID: References: Date: Fri, 10 Feb 2023 17:05:32 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.032 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 59213 Cc: 59213@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > With an `add' instrumented for edebug, and evaluating `add', this causes > edebug to create the form beginning "(function ...". Ffunction in eval.c > delegates the creation of a closure to cconv-make-interpreted-closure. > That function analyses `add', decides that c is not used, and thus > creates a lexical environment containing bindings only for a and b. > > This last is the error. When instrumenting for edebug, EVERY lexical > variable is potentially going to be read, so > cconv-make-interpreted-closure should not remove any elements from the > lexical environment. Yup. > The included patch fixes this: edebug binds the (new) variable > cconv-dont-trim-unused-variables to non-nil around the generated calls to > edebug-enter. cconv-make-interpreted-closure tests this variable, and > when non-nil it copies the lexical environment without change. > > Also, there's a consequential change in testcover.el, where it analyses > the forms it is instrumenting, and needs to handle the new code around > edebug-enter. > > This works. > > What do you think? I think that's good enough for `emacs-29`, yes. I don't like the use of a dynbound variable to control this, but it's not clear how to do better. One thing that occurred to me right now is that we could mark the Edebug closures themselves, e.g. by replacing (function (lambda () ,@forms)) with (function (lambda () :closure-dont-trim-context ,@forms)) and then have `cconv-make-interpreted-closure` look for this tell-tale sign. A few minor comments about your patch below. > +(defvar cconv-dont-trim-unused-variables nil > + "When bound to non-nil, don't remove unused variables from the environment. > +This is intended for use by edebug and similar.") This variable name sounds like it controls the closure conversion code (e.g. `cconv-convert`). I don't have a better suggestion, tho :-( > @@ -875,15 +882,24 @@ cconv-fv > (cons fvs dyns))))) > > (defun cconv-make-interpreted-closure (fun env) > + "Make a closure for the interpreter. > +This function is evaluated both at compile time and run time. > +FUN, the closure's function, must be a lambda form. > +ENV, the closure's environment, is a mixture of lexical bindings of the form > +(SYMBOL . VALUE) and symbols which indicate dynamic bindings of those > +symbols." > (cl-assert (eq (car-safe fun) 'lambda)) > (let ((lexvars (delq nil (mapcar #'car-safe env)))) > (if (null lexvars) > ;; The lexical environment is empty, so there's no need to > ;; look for free variables. > + ;; Attempting to replace ,(cdr fun) by a macroexpanded version > + ;; causes bootstrap to fail. > `(closure ,env . ,(cdr fun)) > ;; We could try and cache the result of the macroexpansion and > ;; `cconv-fv' analysis. Not sure it's worth the trouble. > - (let* ((form `#',fun) > + (let* (newenv > + (form `#',fun) > (expanded-form > (let ((lexical-binding t) ;; Tell macros which dialect is in use. > ;; Make the macro aware of any defvar declarations in scope. > @@ -896,11 +912,14 @@ cconv-make-interpreted-closure > (pcase expanded-form > (`#'(lambda . ,cdr) cdr) > (_ (cdr fun)))) > - > - (dynvars (delq nil (mapcar (lambda (b) (if (symbolp b) b)) env))) > - (fvs (cconv-fv expanded-form lexvars dynvars)) > - (newenv (nconc (mapcar (lambda (fv) (assq fv env)) (car fvs)) > - (cdr fvs)))) > + > + (dynvars (delq nil (mapcar (lambda (b) (if (symbolp b) b)) env)))) > + (if cconv-dont-trim-unused-variables > + (setq newenv (copy-alist env)) > + (let ((fvs (cconv-fv expanded-form lexvars dynvars))) > + (setq newenv > + (nconc (mapcar (lambda (fv) (assq fv env)) (car fvs)) > + (cdr fvs))))) > ;; Never return a nil env, since nil means to use the dynbind > ;; dialect of ELisp. > `(closure ,(or newenv '(t)) . ,expanded-fun-cdr))))) Hmm... any reason why we can't just replace (if (null lexvars) with (if (or cconv-dont-trim-unused-variables (null lexvars)) and be done with it? Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 11 02:26:54 2023 Received: (at 59213) by debbugs.gnu.org; 11 Feb 2023 07:26:54 +0000 Received: from localhost ([127.0.0.1]:38559 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pQkHe-0007zM-6M for submit@debbugs.gnu.org; Sat, 11 Feb 2023 02:26:54 -0500 Received: from eggs.gnu.org ([209.51.188.92]:50176) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pQkHc-0007z9-38 for 59213@debbugs.gnu.org; Sat, 11 Feb 2023 02:26:53 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pQkHW-00065z-83; Sat, 11 Feb 2023 02:26:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=ccLa16p+IFMEgM5f6zqtOFNsxVRbnzsk7l93GITxFyo=; b=X+obyJJ7XpZC hzec9zXHI7XeNjFoSfnKiCJ7jpGTz7bJ+NyMY5q9wv+JgonrTRn+65kAc9WRtVwvsm046K2BdatF8 iOP6/AytDT81TIehbilwDqsB8x6F3jtvcqtVSzeYh6EpI95FciXDGax5TzChabyktH5DTKByFPNeO zMPzJRAxfsb4QtPXzKOrNFpAYis4K3GfYDvcRUc65OwaNgyp+YO4l83lHOEfoXOXli0jbOgXBaGdi Bzu4A5scFusYa5aYbe2gHDYRp0t82CXL76syQmSgp+xDNWICztA9ITbBSDAgmiWZuFbiGzz/QT2g0 4BTNgz+dPWb9ZUuLpHsU1A==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pQkHO-0003Du-2V; Sat, 11 Feb 2023 02:26:44 -0500 Date: Sat, 11 Feb 2023 09:26:08 +0200 Message-Id: <83sffck6i7.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (bug-gnu-emacs@gnu.org) Subject: Re: bug#59213: Emacs 29: Edebug fails to instrument a parameter whose name begins with _ References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 59213 Cc: acm@muc.de, 59213@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 59213@debbugs.gnu.org > Date: Fri, 10 Feb 2023 17:05:32 -0500 > From: Stefan Monnier via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > I think that's good enough for `emacs-29`, yes. Why do we have to fix this in Emacs 29? The problem doesn't sound very important to me: variables that are ignored should not be a subject of scrutiny in Edebug too frequently, and I cannot even imagine a use case where it would be important for debugging. So I'd prefer to fix this on master instead. From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 11 06:17:37 2023 Received: (at 59213-done) by debbugs.gnu.org; 11 Feb 2023 11:17:37 +0000 Received: from localhost ([127.0.0.1]:39106 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pQnsu-00008v-OV for submit@debbugs.gnu.org; Sat, 11 Feb 2023 06:17:37 -0500 Received: from mx3.muc.de ([193.149.48.5]:34895) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pQnsp-00008e-PS for 59213-done@debbugs.gnu.org; Sat, 11 Feb 2023 06:17:35 -0500 Received: (qmail 5741 invoked by uid 3782); 11 Feb 2023 12:17:25 +0100 Received: from acm.muc.de (p4fe15206.dip0.t-ipconnect.de [79.225.82.6]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 11 Feb 2023 12:17:25 +0100 Received: (qmail 11041 invoked by uid 1000); 11 Feb 2023 11:17:24 -0000 Date: Sat, 11 Feb 2023 11:17:24 +0000 To: Stefan Monnier Subject: Re: bug#59213: Emacs 29: Edebug fails to instrument a parameter whose name begins with _ Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 59213-done Cc: 59213-done@debbugs.gnu.org, Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Stefan. On Fri, Feb 10, 2023 at 17:05:32 -0500, Stefan Monnier wrote: [ .... ] > > What do you think? > I think that's good enough for `emacs-29`, yes. I've committed the fix (with modifications) to master, as requested by Eli, and I'm closing the bug with this post. > I don't like the use of a dynbound variable to control this, but it's > not clear how to do better. One thing that occurred to me right now is > that we could mark the Edebug closures themselves, e.g. by replacing > (function (lambda () ,@forms)) > with > (function (lambda () :closure-dont-trim-context ,@forms)) > and then have `cconv-make-interpreted-closure` look for this > tell-tale sign. Interesting. Isn't there a good chance this would foul up programs which analyse the structure of a closure? (A bit like testcover-analyze-coverage analyses the calling structure of edebug-enter). > A few minor comments about your patch below. [ .... ] > Hmm... any reason why we can't just replace > (if (null lexvars) > with > (if (or cconv-dont-trim-unused-variables (null lexvars)) > and be done with it? No, no reason at all. I think I was concerned to preserve the macro expansion, but seeing as how that wouldn't even be in the uninstrumented form, this is clearly not a valid concern. So I modified the patch to do that before committing it. Thanks! > Stefan -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 12 22:27:05 2023 Received: (at 59213) by debbugs.gnu.org; 13 Feb 2023 03:27:05 +0000 Received: from localhost ([127.0.0.1]:47291 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pRPUe-0007EQ-U2 for submit@debbugs.gnu.org; Sun, 12 Feb 2023 22:27:05 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:16416) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pRPUd-0007Dw-IJ for 59213@debbugs.gnu.org; Sun, 12 Feb 2023 22:27:03 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 13E7C804BC; Sun, 12 Feb 2023 22:26:58 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id C3325802B7; Sun, 12 Feb 2023 22:26:56 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1676258816; bh=vRVaw35QHFHAnVZ+j7qaFemVGwxDs2fs67vxkvL+V/s=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Auqq2JE2aa2OYdfD/p5mH5M3DPwDlp7Kf8RtTjgeSufhHoPcXvglYNk7vAj8maK6h 27OcE/RIZVm79ROBRWZfF0vztj9kYmmDzj7LTNEhbG0vFZSkJf2YOibpQivjUG4KJJ 8Nk/Mbon8YWM2LJpwFVlOUB473JXFnQlAbuQWN0oHUQYKk9VhMKmKwS7Cz1nbkAAmQ CEiHE5+U/kz2OnzYuZFQ9eUxuQCLbIYsuvcPB6/NwfV6rUklV0Wg6b9dt/VasIrxfU z44w5bTeSJODvGdr6UvKER59Arc1el95g6WWU7Vyo5TQUJFzgEcFQhSMU48ywbQhwF aYCb6VaVOYVWw== Received: from pastel (unknown [216.154.2.68]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 8E87712311B; Sun, 12 Feb 2023 22:26:56 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#59213: Emacs 29: Edebug fails to instrument a parameter whose name begins with _ In-Reply-To: <83sffck6i7.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 11 Feb 2023 09:26:08 +0200") Message-ID: References: <83sffck6i7.fsf@gnu.org> Date: Sun, 12 Feb 2023 22:26:55 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 59213 Cc: acm@muc.de, 59213@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> I think that's good enough for `emacs-29`, yes. > > Why do we have to fix this in Emacs 29? The problem doesn't sound > very important to me: variables that are ignored should not be a > subject of scrutiny in Edebug too frequently, and I cannot even > imagine a use case where it would be important for debugging. > > So I'd prefer to fix this on master instead. The reason I was thinking of `emacs-29` was that it's a regression in Emacs-29. But I agree that it's not super important, so it can go to `master` (we may want to try and remember to backport it for Emacs-29.2, tho). Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 13 07:55:39 2023 Received: (at 59213) by debbugs.gnu.org; 13 Feb 2023 12:55:39 +0000 Received: from localhost ([127.0.0.1]:47925 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pRYMt-0000SU-Ej for submit@debbugs.gnu.org; Mon, 13 Feb 2023 07:55:39 -0500 Received: from eggs.gnu.org ([209.51.188.92]:56708) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pRYMo-0000SF-OG for 59213@debbugs.gnu.org; Mon, 13 Feb 2023 07:55:38 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pRYMh-0000W2-Na; Mon, 13 Feb 2023 07:55:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=U/am0W9xxD20bHGehVtBSGg32EORS3XVIclZK07UM40=; b=jgoE+xD1IwG5 VgfOp7bQlDKPuNjXZbkWsfu+aTzOOCO3qzQGvKRrgrT7vzEZPUq7vxzWlRYnjsXUzbtQRuXdXAnEG /eoblSXLmGy9F+rWyc3SPck04ggflXUwa9o3xPQHu+JobknzUrjgaYJWne9XKoId1FfAm04nylU3G X7afTLPdDOuSRmB0n2f3qqxvN8NVwvi8u4JeBDqnqytZE1UC9+ndt9/uAEbmQwBeJFAOyIhwbjCQl Nmo6u7lhsN6ahHF7MGim+OarI/70ZKOg4T3baxpGXiBEueeifCRFtLNOQvrQyt71/sDmYRuNcDunY 2tj/GHn18Rd1+MjEVr7f5g==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pRYMU-0006hu-R0; Mon, 13 Feb 2023 07:55:27 -0500 Date: Mon, 13 Feb 2023 14:54:50 +0200 Message-Id: <83lel1g1yd.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Sun, 12 Feb 2023 22:26:55 -0500) Subject: Re: bug#59213: Emacs 29: Edebug fails to instrument a parameter whose name begins with _ References: <83sffck6i7.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 59213 Cc: acm@muc.de, 59213@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: acm@muc.de, 59213@debbugs.gnu.org > Date: Sun, 12 Feb 2023 22:26:55 -0500 > > >> I think that's good enough for `emacs-29`, yes. > > > > Why do we have to fix this in Emacs 29? The problem doesn't sound > > very important to me: variables that are ignored should not be a > > subject of scrutiny in Edebug too frequently, and I cannot even > > imagine a use case where it would be important for debugging. > > > > So I'd prefer to fix this on master instead. > > The reason I was thinking of `emacs-29` was that it's a regression in > Emacs-29. But I agree that it's not super important, so it can go to > `master` (we may want to try and remember to backport it for > Emacs-29.2, tho). Right. Emacs 29.1 will have enough exciting new regressions anyway. From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 14 16:47:13 2023 Received: (at 59213-done) by debbugs.gnu.org; 14 Feb 2023 21:47:13 +0000 Received: from localhost ([127.0.0.1]:57222 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pS38r-0007Lf-EV for submit@debbugs.gnu.org; Tue, 14 Feb 2023 16:47:13 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:53667) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pS38p-0007LS-Gc for 59213-done@debbugs.gnu.org; Tue, 14 Feb 2023 16:47:11 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 14C5710002F; Tue, 14 Feb 2023 16:47:06 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 9E31A10001C; Tue, 14 Feb 2023 16:47:04 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1676411224; bh=fkgQ+wxmHm58ag1qiDb5qrNnr+DSg8QBi31MXmsXL6c=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=HddywaIRqI105voZTuZjFfgYrdgk1ma5GT37Ptso5lBW1k5M/QeeZCz9EhZ3bMqcS HnGleQtCbE+EkTUphWPmbsprg7z7UQknkN5rzcnhLi41O+YAlFaXIfq7DsG9u6iX1R RBo0rto4XfU9R7V5w3DIYgdmiCrRG/2rxowwzopmeuaIkrqvFWKdM15RQLE0TgrvAV sQTxeqdn+VmQMnIN1njN+fxiX4+XAp5zI9BPtsRCt/I/75ZE3/S2klQbj7LmLd5flp a7UEduu/zIbdhUBWo9UIaRCmqf9ZenEjVxYYixorRQfEVJFFbHBDrnbXn4o/f7w0bH wU+LD+mM76vkA== Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 8BF8B12305D; Tue, 14 Feb 2023 16:47:04 -0500 (EST) From: Stefan Monnier To: Alan Mackenzie Subject: Re: bug#59213: Emacs 29: Edebug fails to instrument a parameter whose name begins with _ In-Reply-To: (Alan Mackenzie's message of "Sat, 11 Feb 2023 11:17:24 +0000") Message-ID: References: Date: Tue, 14 Feb 2023 16:47:03 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.027 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 59213-done Cc: 59213-done@debbugs.gnu.org, Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> (function (lambda () ,@forms)) >> with >> (function (lambda () :closure-dont-trim-context ,@forms)) >> and then have `cconv-make-interpreted-closure` look for this >> tell-tale sign. > Interesting. Isn't there a good chance this would foul up programs which > analyse the structure of a closure? It's possible, indeed. Such programs should be quite rare, tho. I'd expect packages which analyse such code would either: A) be Edebug-specific and would have to handle any values of `forms`, in which case having `:closure-dont-trim-context` prepended to it would not affect them. B) be non-Edebug specific in which case they should be looking for a specific pattern somewhere inside `forms` and they should presumably not find the above transformation worse than the other transformations applied by Edebug in general. > (A bit like testcover-analyze-coverage analyses the calling structure > of edebug-enter). Indeed, it's only such code I have found so far. I know there are other tools out there that use Edebug's instrumentation in creative ways, but I can't remember where they are. And, AFAICT in the case of `testcover.el`, the above suggestion would "just work" (fall into case (A)) whereas your approach required a tweak. I'll try it on `master`. Stefan From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 14 17:19:24 2023 Received: (at 59213) by debbugs.gnu.org; 14 Feb 2023 22:19:24 +0000 Received: from localhost ([127.0.0.1]:57274 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pS3dz-00028w-Vq for submit@debbugs.gnu.org; Tue, 14 Feb 2023 17:19:24 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:40407) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pS3dx-00028i-Q6 for 59213@debbugs.gnu.org; Tue, 14 Feb 2023 17:19:22 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id D4C1B800A8; Tue, 14 Feb 2023 17:19:15 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id D421C80148; Tue, 14 Feb 2023 17:19:13 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1676413153; bh=0XcZUzI9vMxbR/GnfkjSiNK8FuIEezVauh/sox4PcMw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Zfkpa78GsCR9yXlzyrmRcYrLhVKZSVgTOLeKnLCyvAuUQdgDRr608icTO0UsG6vML a3+1esATdH4hqVDmVvIN/m7o+2dJJ13l3S1TZddpRpPX2ciz8ErZDX2P4P7AsxA7Yc 06cm0He6JUNSzltLre0/LMIcw5ppzjnsc64HyAkvwcpWHKcxqF/gS3JYTzxbXJC39m 0n2SrlxeiPuOd+3EbXUWVgacIUsrdCpykGCakVBp7bgCsHQKUitLqQ5H21eynGweYx Y3l86UqQpMALNrT2t46P4ghi5M4aiM0O715yNI5wfYcn+7ec0UtxjbC3GQ3dkoHKlx +gT9Oy7cGMMyg== Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id B133D1231AD; Tue, 14 Feb 2023 17:19:13 -0500 (EST) From: Stefan Monnier To: Alan Mackenzie Subject: Re: bug#59213: Emacs 29: Edebug fails to instrument a parameter whose name begins with _ In-Reply-To: (Alan Mackenzie's message of "Fri, 10 Feb 2023 18:51:37 +0000") Message-ID: References: Date: Tue, 14 Feb 2023 17:19:12 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.068 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 59213 Cc: 59213@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Hi Alan, > (defun cconv-make-interpreted-closure (fun env) > + "Make a closure for the interpreter. > +This function is evaluated both at compile time and run time. > +FUN, the closure's function, must be a lambda form. > +ENV, the closure's environment, is a mixture of lexical bindings of the form > +(SYMBOL . VALUE) and symbols which indicate dynamic bindings of those > +symbols." BTW, what did you mean by "This function is evaluated both at compile time and run time"? Also, I append the current state of the patch I plan to install on `master`. Stefan diff --git a/lisp/emacs-lisp/cconv.el b/lisp/emacs-lisp/cconv.el index b8121aeba55..d055026cb1a 100644 --- a/lisp/emacs-lisp/cconv.el +++ b/lisp/emacs-lisp/cconv.el @@ -113,10 +113,6 @@ cconv--interactive-form-funs (defvar cconv--dynbound-variables nil "List of variables known to be dynamically bound.") -(defvar cconv-dont-trim-unused-variables nil - "When bound to non-nil, don't remove unused variables from the environment. -This is intended for use by edebug and similar.") - ;;;###autoload (defun cconv-closure-convert (form &optional dynbound-vars) "Main entry point for closure conversion. @@ -886,11 +882,16 @@ cconv-make-interpreted-closure This function is evaluated both at compile time and run time. FUN, the closure's function, must be a lambda form. ENV, the closure's environment, is a mixture of lexical bindings of the form -(SYMBOL . VALUE) and symbols which indicate dynamic bindings of those +\(SYMBOL . VALUE) and symbols which indicate dynamic bindings of those symbols." (cl-assert (eq (car-safe fun) 'lambda)) (let ((lexvars (delq nil (mapcar #'car-safe env)))) - (if (or cconv-dont-trim-unused-variables (null lexvars)) + (if (or (null lexvars) + ;; Functions of the form (lambda (..) :closure-dont-trim-context ..) + ;; should keep their whole context untrimmed (bug#59213). + (and (eq :closure-dont-trim-context (nth 2 fun)) + ;; Check the function doesn't just return the magic keyword. + (nthcdr 3 fun))) ;; The lexical environment is empty, or needs to be preserved, ;; so there's no need to look for free variables. ;; Attempting to replace ,(cdr fun) by a macroexpanded version diff --git a/lisp/emacs-lisp/edebug.el b/lisp/emacs-lisp/edebug.el index 735a358cdba..4b625dd076e 100644 --- a/lisp/emacs-lisp/edebug.el +++ b/lisp/emacs-lisp/edebug.el @@ -1217,16 +1217,17 @@ edebug-make-enter-wrapper (setq edebug-old-def-name nil)) (setq edebug-def-name (or edebug-def-name edebug-old-def-name (gensym "edebug-anon"))) - `(let ((cconv-dont-trim-unused-variables t)) - (edebug-enter - (quote ,edebug-def-name) - ,(if edebug-inside-func - `(list - ;; Doesn't work with more than one def-body!! - ;; But the list will just be reversed. - ,@(nreverse edebug-def-args)) - 'nil) - (function (lambda () ,@forms))))) + `(edebug-enter + (quote ,edebug-def-name) + ,(if edebug-inside-func + `(list + ;; Doesn't work with more than one def-body!! + ;; But the list will just be reversed. + ,@(nreverse edebug-def-args)) + 'nil) + ;; Make sure `forms' is not nil so we don't accidentally return + ;; the magic keyword. + #'(lambda () :closure-dont-trim-context ,@(or forms '(nil))))) (defvar edebug-form-begin-marker) ; the mark for def being instrumented diff --git a/lisp/emacs-lisp/testcover.el b/lisp/emacs-lisp/testcover.el index 1212905f08a..ed31b90ca32 100644 --- a/lisp/emacs-lisp/testcover.el +++ b/lisp/emacs-lisp/testcover.el @@ -442,11 +442,6 @@ testcover-analyze-coverage (let ((testcover-vector (get sym 'edebug-coverage))) (testcover-analyze-coverage-progn body))) - (`(let ((cconv-dont-trim-unused-variables t)) - (edebug-enter ',sym ,_ (function (lambda nil . ,body)))) - (let ((testcover-vector (get sym 'edebug-coverage))) - (testcover-analyze-coverage-progn body))) - (`(edebug-after ,(and before-form (or `(edebug-before ,before-id) before-id)) ,after-id ,wrapped-form) diff --git a/test/lisp/emacs-lisp/cconv-tests.el b/test/lisp/emacs-lisp/cconv-tests.el index 83013cf46a9..349ffeb7e47 100644 --- a/test/lisp/emacs-lisp/cconv-tests.el +++ b/test/lisp/emacs-lisp/cconv-tests.el @@ -364,5 +364,18 @@ cconv-tests--intern-all (call-interactively f)) '((t 51696) (nil 51695) (t 51697))))))) +(ert-deftest cconv-safe-for-space () + (let* ((magic-string "This-is-a-magic-string") + (safe-p (lambda (x) (not (string-match magic-string (format "%S" x)))))) + (should (funcall safe-p (lambda (x) (+ x 1)))) + (should (funcall safe-p (eval '(lambda (x) (+ x 1)) + `((y . ,magic-string))))) + (should (funcall safe-p (eval '(lambda (x) :closure-dont-trim-context) + `((y . ,magic-string))))) + (should-not (funcall safe-p + (eval '(lambda (x) :closure-dont-trim-context (+ x 1)) + `((y . ,magic-string))))))) + + (provide 'cconv-tests) ;;; cconv-tests.el ends here From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 18 13:08:24 2023 Received: (at 59213-done) by debbugs.gnu.org; 18 Feb 2023 18:08:24 +0000 Received: from localhost ([127.0.0.1]:44933 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTRdH-0005mh-T5 for submit@debbugs.gnu.org; Sat, 18 Feb 2023 13:08:24 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:21327) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTRdF-0005mS-Lg for 59213-done@debbugs.gnu.org; Sat, 18 Feb 2023 13:08:22 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 0489F1000D6; Sat, 18 Feb 2023 13:08:15 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 8563A100098; Sat, 18 Feb 2023 13:08:13 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1676743693; bh=DSGVwXq2Y0rZ6NaD79BXFSIUEWjs3D5ApeP/WF9zRWw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=JcI5YQihstmx9gWorDScWo9L8WdQW6d6JCMgyCzpeCRPxmMPP5MyZvRcXf4D2gbX3 2I4dtkJlmEAZVqX12mVKxu3lCVfgoJIgcQ0yF4s3EkXoq7skV78xYyIhoskvs26ehx +EUazIbjD0xcNLTUhQLnlRI/afuWZEr7JF+7lR+L2C8l2QhVY8lZ61KglvA1z2K53q iKuzaQzQza3nOPnK/jFNAv8zRf/2ZkRYxQ19Q88savtkVb2tG2QcotdcQEQ7jThD7X 1/ssFIjTi9trnPU97RU7OpxpNXLYjvRXUGR+0GZDot8pg0+0kWzK/oRD5tXvwZ2T4n 5EubeIb6hrZWQ== Received: from pastel (unknown [216.154.34.24]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 5A6C4123211; Sat, 18 Feb 2023 13:08:13 -0500 (EST) From: Stefan Monnier To: Alan Mackenzie Subject: Re: bug#59213: Emacs 29: Edebug fails to instrument a parameter whose name begins with _ In-Reply-To: (Stefan Monnier's message of "Tue, 14 Feb 2023 17:19:12 -0500") Message-ID: References: Date: Sat, 18 Feb 2023 13:08:11 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.216 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 59213-done Cc: 59213-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> (defun cconv-make-interpreted-closure (fun env) >> + "Make a closure for the interpreter. >> +This function is evaluated both at compile time and run time. >> +FUN, the closure's function, must be a lambda form. >> +ENV, the closure's environment, is a mixture of lexical bindings of the form >> +(SYMBOL . VALUE) and symbols which indicate dynamic bindings of those >> +symbols." > > BTW, what did you mean by "This function is evaluated both at compile > time and run time"? I still have no idea what you mean by that. I just a put a FIXME for that in the mean time. > Also, I append the current state of the patch I plan to install on > `master`. Pushed. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 18 13:46:58 2023 Received: (at 59213) by debbugs.gnu.org; 18 Feb 2023 18:46:58 +0000 Received: from localhost ([127.0.0.1]:44957 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTSEc-0006l6-6C for submit@debbugs.gnu.org; Sat, 18 Feb 2023 13:46:58 -0500 Received: from mx3.muc.de ([193.149.48.5]:13289) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTSEZ-0006kl-W4 for 59213@debbugs.gnu.org; Sat, 18 Feb 2023 13:46:56 -0500 Received: (qmail 14657 invoked by uid 3782); 18 Feb 2023 19:46:49 +0100 Received: from acm.muc.de (p4fe151f6.dip0.t-ipconnect.de [79.225.81.246]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 18 Feb 2023 19:46:48 +0100 Received: (qmail 1907 invoked by uid 1000); 18 Feb 2023 18:46:47 -0000 Date: Sat, 18 Feb 2023 18:46:47 +0000 To: Stefan Monnier Subject: Re: bug#59213: Emacs 29: Edebug fails to instrument a parameter whose name begins with _ Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 59213 Cc: 59213@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Stefan, Sorry you needed to ping me to get an answer to this. On Tue, Feb 14, 2023 at 17:19:12 -0500, Stefan Monnier wrote: > Hi Alan, > > (defun cconv-make-interpreted-closure (fun env) > > + "Make a closure for the interpreter. > > +This function is evaluated both at compile time and run time. > > +FUN, the closure's function, must be a lambda form. > > +ENV, the closure's environment, is a mixture of lexical bindings of the form > > +(SYMBOL . VALUE) and symbols which indicate dynamic bindings of those > > +symbols." > BTW, what did you mean by "This function is evaluated both at compile > time and run time"? It was my state of gradually diminishing confusion (which started at a high level) as I worked through the bug. It took me some while before it occurred to me that the creation of closures was happening at run time, not compile time. Of course, it's got to, because the lexical environment only exists at run time. But I would have got through all this faster if there had been a comment saying cconv-make-interpreted-closure is called at run time. So I put such a comment in for the next highly confused hacker. As for the "at compile time", I saw this happening whilst I was running things in gdb. I'm not actually sure about this anymore, since these calls to c-m-i-closure might well have been run time for bits of the compiler, not compile time. So maybe the words "both compile time and" should be removed. What do you say? > Also, I append the current state of the patch I plan to install on > `master`. Thanks. I'm not sure what advantages this approach has, but it certainly gets rid of the ugly cconv-dont-trim-unused-variables. I'm sure it will work, too, which is the main thing. > Stefan > diff --git a/lisp/emacs-lisp/cconv.el b/lisp/emacs-lisp/cconv.el > index b8121aeba55..d055026cb1a 100644 > --- a/lisp/emacs-lisp/cconv.el > +++ b/lisp/emacs-lisp/cconv.el > @@ -113,10 +113,6 @@ cconv--interactive-form-funs > (defvar cconv--dynbound-variables nil > "List of variables known to be dynamically bound.") > -(defvar cconv-dont-trim-unused-variables nil > - "When bound to non-nil, don't remove unused variables from the environment. > -This is intended for use by edebug and similar.") > - > ;;;###autoload > (defun cconv-closure-convert (form &optional dynbound-vars) > "Main entry point for closure conversion. > @@ -886,11 +882,16 @@ cconv-make-interpreted-closure > This function is evaluated both at compile time and run time. > FUN, the closure's function, must be a lambda form. > ENV, the closure's environment, is a mixture of lexical bindings of the form > -(SYMBOL . VALUE) and symbols which indicate dynamic bindings of those > +\(SYMBOL . VALUE) and symbols which indicate dynamic bindings of those > symbols." > (cl-assert (eq (car-safe fun) 'lambda)) > (let ((lexvars (delq nil (mapcar #'car-safe env)))) > - (if (or cconv-dont-trim-unused-variables (null lexvars)) > + (if (or (null lexvars) > + ;; Functions of the form (lambda (..) :closure-dont-trim-context ..) > + ;; should keep their whole context untrimmed (bug#59213). > + (and (eq :closure-dont-trim-context (nth 2 fun)) > + ;; Check the function doesn't just return the magic keyword. > + (nthcdr 3 fun))) > ;; The lexical environment is empty, or needs to be preserved, > ;; so there's no need to look for free variables. > ;; Attempting to replace ,(cdr fun) by a macroexpanded version > diff --git a/lisp/emacs-lisp/edebug.el b/lisp/emacs-lisp/edebug.el > index 735a358cdba..4b625dd076e 100644 > --- a/lisp/emacs-lisp/edebug.el > +++ b/lisp/emacs-lisp/edebug.el > @@ -1217,16 +1217,17 @@ edebug-make-enter-wrapper > (setq edebug-old-def-name nil)) > (setq edebug-def-name > (or edebug-def-name edebug-old-def-name (gensym "edebug-anon"))) > - `(let ((cconv-dont-trim-unused-variables t)) > - (edebug-enter > - (quote ,edebug-def-name) > - ,(if edebug-inside-func > - `(list > - ;; Doesn't work with more than one def-body!! > - ;; But the list will just be reversed. > - ,@(nreverse edebug-def-args)) > - 'nil) > - (function (lambda () ,@forms))))) > + `(edebug-enter > + (quote ,edebug-def-name) > + ,(if edebug-inside-func > + `(list > + ;; Doesn't work with more than one def-body!! > + ;; But the list will just be reversed. > + ,@(nreverse edebug-def-args)) > + 'nil) > + ;; Make sure `forms' is not nil so we don't accidentally return > + ;; the magic keyword. > + #'(lambda () :closure-dont-trim-context ,@(or forms '(nil))))) > (defvar edebug-form-begin-marker) ; the mark for def being instrumented > diff --git a/lisp/emacs-lisp/testcover.el b/lisp/emacs-lisp/testcover.el > index 1212905f08a..ed31b90ca32 100644 > --- a/lisp/emacs-lisp/testcover.el > +++ b/lisp/emacs-lisp/testcover.el > @@ -442,11 +442,6 @@ testcover-analyze-coverage > (let ((testcover-vector (get sym 'edebug-coverage))) > (testcover-analyze-coverage-progn body))) > - (`(let ((cconv-dont-trim-unused-variables t)) > - (edebug-enter ',sym ,_ (function (lambda nil . ,body)))) > - (let ((testcover-vector (get sym 'edebug-coverage))) > - (testcover-analyze-coverage-progn body))) > - > (`(edebug-after ,(and before-form > (or `(edebug-before ,before-id) before-id)) > ,after-id ,wrapped-form) > diff --git a/test/lisp/emacs-lisp/cconv-tests.el b/test/lisp/emacs-lisp/cconv-tests.el > index 83013cf46a9..349ffeb7e47 100644 > --- a/test/lisp/emacs-lisp/cconv-tests.el > +++ b/test/lisp/emacs-lisp/cconv-tests.el > @@ -364,5 +364,18 @@ cconv-tests--intern-all > (call-interactively f)) > '((t 51696) (nil 51695) (t 51697))))))) > +(ert-deftest cconv-safe-for-space () > + (let* ((magic-string "This-is-a-magic-string") > + (safe-p (lambda (x) (not (string-match magic-string (format "%S" x)))))) > + (should (funcall safe-p (lambda (x) (+ x 1)))) > + (should (funcall safe-p (eval '(lambda (x) (+ x 1)) > + `((y . ,magic-string))))) > + (should (funcall safe-p (eval '(lambda (x) :closure-dont-trim-context) > + `((y . ,magic-string))))) > + (should-not (funcall safe-p > + (eval '(lambda (x) :closure-dont-trim-context (+ x 1)) > + `((y . ,magic-string))))))) > + > + > (provide 'cconv-tests) > ;;; cconv-tests.el ends here -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 20 17:21:34 2023 Received: (at 59213) by debbugs.gnu.org; 20 Feb 2023 22:21:34 +0000 Received: from localhost ([127.0.0.1]:53872 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pUEXN-0007yn-Jo for submit@debbugs.gnu.org; Mon, 20 Feb 2023 17:21:33 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:40906) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pUEXJ-0007yY-PY for 59213@debbugs.gnu.org; Mon, 20 Feb 2023 17:21:31 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id D1B361000DC; Mon, 20 Feb 2023 17:21:23 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 1DD2A100098; Mon, 20 Feb 2023 17:21:22 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1676931682; bh=BloaaBM7zotFYsImpYU+jjdgDzq2RmrxM5tXhLzrA0k=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=U7z/sv0VcxS3Mi6AwFIPEDRcMRAMWeu+vwgGf/U+P+PW/UTJx3Nna3JBM9L72I31e 4QIOrCnuSMcw3rqsMnJKgKBUNAtWjDa8uBse/a6Ycdl0m2FwEG0tY/61M/zm5qcx1n HsyZ90r5QTeqFFDWxjfs1s1HE05lHa5ZRQWKV8TUipXbtZ5r1S7uPnIgISn0yloxl9 s6ZEhlYjmeVdMDI/jqsvuKbVwctTAvihh7Y6Yxk3HXmO4yU/Tzr2rw7vi5ecfl/IuL OSki0U0VA9V0DTT/B1M+QQggmwrtIxBPux4UnoxjfKkaK4fwkGMCMO7hmaLYuNTckR E4QdR5td/WNGA== Received: from pastel (unknown [216.154.34.24]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D6535123217; Mon, 20 Feb 2023 17:21:21 -0500 (EST) From: Stefan Monnier To: Alan Mackenzie Subject: Re: bug#59213: Emacs 29: Edebug fails to instrument a parameter whose name begins with _ In-Reply-To: (Alan Mackenzie's message of "Sat, 18 Feb 2023 18:46:47 +0000") Message-ID: References: Date: Mon, 20 Feb 2023 17:21:20 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.113 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 59213 Cc: 59213@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> BTW, what did you mean by "This function is evaluated both at compile >> time and run time"? > > It was my state of gradually diminishing confusion (which started at a > high level) as I worked through the bug. It took me some while before it > occurred to me that the creation of closures was happening at run time, > not compile time. Of course, it's got to, because the lexical > environment only exists at run time. But I would have got through all > this faster if there had been a comment saying > cconv-make-interpreted-closure is called at run time. So I put such a > comment in for the next highly confused hacker. Thanks. I found that part more confusing, so I reworked it in a way that I hope doesn't make it too much worse. > As for the "at compile time", I saw this happening whilst I was running > things in gdb. I'm not actually sure about this anymore, since these > calls to c-m-i-closure might well have been run time for bits of the > compiler, not compile time. That'd be my guess, yes. Tho it can also be due to execution of (not yet byte-compiled) macros. > Thanks. I'm not sure what advantages this approach has, but it certainly > gets rid of the ugly cconv-dont-trim-unused-variables. Getting rid of the dynamically scoped `cconv-dont-trim-unused-variables` is the whole point. In theory it's also "more correct" since it marks the actual lambdas for which we care to preserve the full environment, regardless of *when* we'll manipulate it. E.g. if we ever get to byte-compile the Edebug-instrumented code, the compiler will get to see this marker so it can do the right thing, whereas it wouldn't see the `cconv-dont-trim-unused-variables` because that war was only active when the code was actually executed [ Of course, this is moot in practice since the byte-compiler currently doesn't know what to do with this marker. ] Stefan From unknown Sat Jun 21 05:16:31 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Tue, 21 Mar 2023 11:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator