From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#46573: 28.0.50; Error when edebugging setting unbound place Date: Tue, 16 Feb 2021 19:00:45 -0500 Message-ID: References: <87v9ar1w4l.fsf@web.de> <87mtw3r5hr.fsf@gnus.org> <8735xvr4o2.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7626"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Michael Heerdegen , Gemini Lasswell , 46573@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Feb 17 01:01:40 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lCAHi-0001rG-Ly for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 17 Feb 2021 01:01:38 +0100 Original-Received: from localhost ([::1]:50440 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lCAHh-0006lT-P2 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 16 Feb 2021 19:01:37 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54214) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lCAH8-0006lJ-EC for bug-gnu-emacs@gnu.org; Tue, 16 Feb 2021 19:01:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:58717) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lCAH8-0004tF-6y for bug-gnu-emacs@gnu.org; Tue, 16 Feb 2021 19:01:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lCAH8-0007Z0-5o for bug-gnu-emacs@gnu.org; Tue, 16 Feb 2021 19:01:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 17 Feb 2021 00:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 46573 X-GNU-PR-Package: emacs Original-Received: via spool by 46573-submit@debbugs.gnu.org id=B46573.161352005628743 (code B ref 46573); Wed, 17 Feb 2021 00:01:02 +0000 Original-Received: (at 46573) by debbugs.gnu.org; 17 Feb 2021 00:00:56 +0000 Original-Received: from localhost ([127.0.0.1]:42030 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lCAH2-0007T8-3P for submit@debbugs.gnu.org; Tue, 16 Feb 2021 19:00:56 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:19241) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lCAH0-0007Ml-8R for 46573@debbugs.gnu.org; Tue, 16 Feb 2021 19:00:54 -0500 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id A476480C11; Tue, 16 Feb 2021 19:00:48 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 2147C8022C; Tue, 16 Feb 2021 19:00:47 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1613520047; bh=rfd8mxm+g1MfZS0LliYxfsqwfTScBCIl6hOWy1XrHUY=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=HfIfVuBmAqS8M3o+ch90SJdR66TnHISHTJwh97WNMSZUDL7Yiq3ncSFvzZTeZ8JdU QN7Bni9aHrCuzurkSj0b30eXGgQUS9cPd6H9pxD/w1g1o2hjZw+SeuMsb2jtNVBVZm B006WPJi+7afIQ/v0vpVIjbd21ZVx2e8rv/IoIYJp0ojuJLZ/2EOLYx13Hm+dECHDO pQr0S6r1BfroZ8UaiHWAW8Yi+HAfH7BRj2zScQ5UfC4DYJdlVf4NfSQ6qzblhA99/r 9W/YDW3sisp29US1GzVBw+T3fuu8u9Pq4EISwYT+fqIzuEEhzicgAPYwkJfqIlELKN OwbTYYly9VtSg== Original-Received: from alfajor (unknown [216.154.41.47]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 9BBE712045A; Tue, 16 Feb 2021 19:00:46 -0500 (EST) In-Reply-To: <8735xvr4o2.fsf@gnus.org> (Lars Ingebrigtsen's message of "Wed, 17 Feb 2021 00:09:17 +0100") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:200179 Archived-At: >>> (put 'gv-place 'edebug-form-spec '(form)) ;So-called "indirect spec". >>> >>> That's certainly not correct for the simplest forms like >> >> This has been there since the introduction of `gv`, so I think it >> *is* correct. The problem is elsewhere (likely introduced by some of >> my recent changes to Edebug). > > Darn! I thought I had finally learned how to read edebug specs. :-/ I > though `form' meant that it's going to be instrumented? Hm... but it's > `(form)' which means, er, uhm. Yes, it means Edebug rewrites (setf x 5) to something like: (edebug-after (edebug-before 1) 3 (setf (edebug-after 0 2 x) 5)) Whose behavior then depends on the definition of (edebug-after N1 N2 EXP) as a "place", which is here: (put 'edebug-after 'gv-expander (lambda (do before index place) (gv-letplace (getter setter) place (funcall do `(edebug-after ,before ,index ,getter) (lambda (store) `(progn (edebug-after ,before ,index ,getter) ,(funcall setter store))))))) and indeed, there's the bug, introduced by Gemini's commit d79cf638f278e50c22feb53d6ba556f5ce9d7853 which does (among various other things): [...] * lisp/emacs-lisp/gv.el: Modify edebug-after's gv-expander to instrument in the setter as well as the getter. [...] diff --git a/lisp/emacs-lisp/gv.el b/lisp/emacs-lisp/gv.el --- a/lisp/emacs-lisp/gv.el +++ b/lisp/emacs-lisp/gv.el @@ -302,5 +302,7 @@ (put 'edebug-after 'gv-expander (lambda (do before index place) (gv-letplace (getter setter) place (funcall do `(edebug-after ,before ,index ,getter) - setter)))) + (lambda (store) + `(progn (edebug-after ,before ,index ,getter) + ,(funcall setter store))))))) Gemini, how important is it to instrument the setter? It is definitely undesirable for Edebug, which you end up seeing the result of computations which don't take place at all during un-instrumented execution. How 'bout using something like `(edebug-after ,before ,index ,(funcall setter store)) instead? Stefan