GNU bug report logs - #48489
28.0.50; Incorrect Edebug instrumentation for old `when-let' form

Previous Next

Package: emacs;

Reported by: Philipp <p.stephani2 <at> gmail.com>

Date: Mon, 17 May 2021 22:09:02 UTC

Severity: normal

Found in version 28.0.50

Done: Philipp Stephani <p.stephani2 <at> gmail.com>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 48489 in the body.
You can then email your comments to 48489 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#48489; Package emacs. (Mon, 17 May 2021 22:09:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Philipp <p.stephani2 <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Mon, 17 May 2021 22:09:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Philipp <p.stephani2 <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; Incorrect Edebug instrumentation for old `when-let' form
Date: Tue, 18 May 2021 00:08:30 +0200
Insert the following form into *scratch*:

(defun f (a) (when-let (b (not a)) b))

Edebug-evaluate it using C-u M-C-x.

Now evaluate (f 1).  Edebug will not stop at the (not a) form, only the
`a' symbol.  The instrumented form is indeed incorrect:
(symbol-function 'f) gives

(closure
 (t)
 (a)
 (edebug-enter 'f
	       (list a)
	       #'(lambda nil
		   (edebug-after
		    (edebug-before 0)
		    3
		    (let*
			((b
			  (and t
			       (not
				(edebug-after 0 1 a)))))
		      (if b
			  (edebug-after 0 2 b)
			nil))))))

Note the missing edebug-before/after around the `not' form.

This can be rectified by swapping the two `&or' branches in the Edebug
specification for `if-let', which makes sense given the first branch is
often a superset of the second.  I don't mind doing that, but maybe
there are negative conseqences from that that I don't see?


In GNU Emacs 28.0.50 (build 120, aarch64-apple-darwin20.4.0, NS appkit-2022.44 Version 11.3.1 (Build 20E241))
 of 2021-05-17
Repository revision: f572735c5105a84da3175ae6cdad807fa103dfe1
Repository branch: master
Windowing system distributor 'Apple', version 10.3.2022
System Description:  macOS 11.3.1

Configured using:
 'configure --with-modules --without-xml2 --without-pop --with-mailutils
 --enable-gcc-warnings=warn-only --enable-checking=all
 --enable-check-lisp-object-type 'CFLAGS=-ggdb3 -O0''

Configured features:
ACL GNUTLS JSON LCMS2 MODULES NOTIFY KQUEUE NS PDUMPER PNG THREADS
TOOLKIT_SCROLL_BARS ZLIB

Important settings:
  value of $LANG: de_DE.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc dired dired-loaddefs rfc822
mml mml-sec epa epg epg-config gnus-util rmail rmail-loaddefs time-date
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
mail-utils phst skeleton derived edmacro kmacro pcase ffap thingatpt url
url-proxy url-privacy url-expand url-methods url-history url-cookie
url-domsuf url-util url-parse auth-source cl-seq eieio eieio-core
cl-macs eieio-loaddefs password-cache json map url-vars mailcap rx
gnutls puny dbus xml subr-x seq byte-opt gv bytecomp byte-compile cconv
compile text-property-search comint ansi-color ring cl-loaddefs cl-lib
iso-transl tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/ns-win ns-win ucs-normalize mule-util
term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads kqueue cocoa ns lcms2
multi-tty make-network-process emacs)

Memory information:
((conses 16 70904 5824)
 (symbols 48 8362 1)
 (strings 32 24249 2101)
 (string-bytes 1 793015)
 (vectors 16 16050)
 (vector-slots 8 212531 11281)
 (floats 8 26 28)
 (intervals 56 219 0)
 (buffers 992 10))




Reply sent to Philipp Stephani <p.stephani2 <at> gmail.com>:
You have taken responsibility. (Tue, 18 May 2021 07:30:02 GMT) Full text and rfc822 format available.

Notification sent to Philipp <p.stephani2 <at> gmail.com>:
bug acknowledged by developer. (Tue, 18 May 2021 07:30:02 GMT) Full text and rfc822 format available.

Message #10 received at 48489-done <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: 48489-done <at> debbugs.gnu.org
Subject: Re: bug#48489: 28.0.50; Incorrect Edebug instrumentation for old
 `when-let' form
Date: Tue, 18 May 2021 09:29:13 +0200
Am Di., 18. Mai 2021 um 00:09 Uhr schrieb Philipp <p.stephani2 <at> gmail.com>:
> This can be rectified by swapping the two `&or' branches in the Edebug
> specification for `if-let', which makes sense given the first branch is
> often a superset of the second.  I don't mind doing that, but maybe
> there are negative conseqences from that that I don't see?

I guess the easiest way to find out is to make the change and see
whether anything breaks ;-)
Done with commit 9676d41b8301b84e07717e633059a3f2b5c4c9d8.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#48489; Package emacs. (Tue, 18 May 2021 15:00:02 GMT) Full text and rfc822 format available.

Message #13 received at 48489 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Philipp <p.stephani2 <at> gmail.com>
Cc: 48489 <at> debbugs.gnu.org
Subject: Re: bug#48489: 28.0.50;
 Incorrect Edebug instrumentation for old `when-let' form
Date: Tue, 18 May 2021 10:59:08 -0400
Philipp wrote:

> This can be rectified by swapping the two `&or' branches in the Edebug
> specification for `if-let', which makes sense given the first branch is
> often a superset of the second.  I don't mind doing that, but maybe
> there are negative conseqences from that that I don't see?

Since 9676d41, edebug-tests-duplicate-symbol-backtrack fails.
Ref eg https://hydra.nixos.org/build/143298928
Reproduced on CentOS 8.3.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#48489; Package emacs. (Tue, 18 May 2021 15:57:02 GMT) Full text and rfc822 format available.

Message #16 received at 48489 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 48489 <at> debbugs.gnu.org
Subject: Re: bug#48489: 28.0.50; Incorrect Edebug instrumentation for old
 `when-let' form
Date: Tue, 18 May 2021 17:55:57 +0200
Am Di., 18. Mai 2021 um 16:59 Uhr schrieb Glenn Morris <rgm <at> gnu.org>:
>
> Philipp wrote:
>
> > This can be rectified by swapping the two `&or' branches in the Edebug
> > specification for `if-let', which makes sense given the first branch is
> > often a superset of the second.  I don't mind doing that, but maybe
> > there are negative conseqences from that that I don't see?
>
> Since 9676d41, edebug-tests-duplicate-symbol-backtrack fails.
> Ref eg https://hydra.nixos.org/build/143298928
> Reproduced on CentOS 8.3.

Hmm, I can't reproduce this on Debian. But I don't see how this could
be OS-dependent.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#48489; Package emacs. (Tue, 18 May 2021 16:26:02 GMT) Full text and rfc822 format available.

Message #19 received at 48489 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: Glenn Morris <rgm <at> gnu.org>, 48489 <at> debbugs.gnu.org
Subject: Re: bug#48489: 28.0.50; Incorrect Edebug instrumentation for old
 `when-let' form
Date: Tue, 18 May 2021 18:25:00 +0200
Philipp Stephani <p.stephani2 <at> gmail.com> writes:

> Hmm, I can't reproduce this on Debian. But I don't see how this could
> be OS-dependent.

It reproduces fine here on Debian/bullseye, at least:

1 unexpected results:
   FAILED  edebug-tests-duplicate-symbol-backtrack



-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#48489; Package emacs. (Tue, 18 May 2021 16:28:01 GMT) Full text and rfc822 format available.

Message #22 received at 48489 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Glenn Morris <rgm <at> gnu.org>, 48489 <at> debbugs.gnu.org
Subject: Re: bug#48489: 28.0.50; Incorrect Edebug instrumentation for old
 `when-let' form
Date: Tue, 18 May 2021 18:27:36 +0200
Am Di., 18. Mai 2021 um 18:25 Uhr schrieb Lars Ingebrigtsen <larsi <at> gnus.org>:
>
> Philipp Stephani <p.stephani2 <at> gmail.com> writes:
>
> > Hmm, I can't reproduce this on Debian. But I don't see how this could
> > be OS-dependent.
>
> It reproduces fine here on Debian/bullseye, at least:
>
> 1 unexpected results:
>    FAILED  edebug-tests-duplicate-symbol-backtrack
>

Yeah, I can also reproduce it now. Not sure what changed in the
meantime on my system.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#48489; Package emacs. (Tue, 18 May 2021 16:35:02 GMT) Full text and rfc822 format available.

Message #25 received at 48489 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Glenn Morris <rgm <at> gnu.org>, 48489 <at> debbugs.gnu.org
Subject: Re: bug#48489: 28.0.50; Incorrect Edebug instrumentation for old
 `when-let' form
Date: Tue, 18 May 2021 18:34:35 +0200
Am Di., 18. Mai 2021 um 18:27 Uhr schrieb Philipp Stephani
<p.stephani2 <at> gmail.com>:
>
> Am Di., 18. Mai 2021 um 18:25 Uhr schrieb Lars Ingebrigtsen <larsi <at> gnus.org>:
> >
> > Philipp Stephani <p.stephani2 <at> gmail.com> writes:
> >
> > > Hmm, I can't reproduce this on Debian. But I don't see how this could
> > > be OS-dependent.
> >
> > It reproduces fine here on Debian/bullseye, at least:
> >
> > 1 unexpected results:
> >    FAILED  edebug-tests-duplicate-symbol-backtrack
> >
>
> Yeah, I can also reproduce it now. Not sure what changed in the
> meantime on my system.

Ah. See the FIXME in the test:

                     ;; FIXME: There are twice as many inner
                     ;; definitions as expected due to Bug#42701.
                     ;; Once that bug is fixed, remove the duplicates.

Bug#42701 still isn't fixed, but the fix to bug#48489 has "suppressed"
its symptom in this case. We can therefore resolve this FIXME.
However, then the edebug-tests-duplicate-symbol-backtrack doesn't
really test any more what it should be testing. So I'll see that I can
change it to restore the previous behavior (which requires
backtracking and overlapping &or branches).




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#48489; Package emacs. (Tue, 18 May 2021 16:51:02 GMT) Full text and rfc822 format available.

Message #28 received at 48489 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Glenn Morris <rgm <at> gnu.org>, 48489 <at> debbugs.gnu.org
Subject: Re: bug#48489: 28.0.50; Incorrect Edebug instrumentation for old
 `when-let' form
Date: Tue, 18 May 2021 18:49:59 +0200
Am Di., 18. Mai 2021 um 18:34 Uhr schrieb Philipp Stephani
<p.stephani2 <at> gmail.com>:
>
> Am Di., 18. Mai 2021 um 18:27 Uhr schrieb Philipp Stephani
> <p.stephani2 <at> gmail.com>:
> >
> > Am Di., 18. Mai 2021 um 18:25 Uhr schrieb Lars Ingebrigtsen <larsi <at> gnus.org>:
> > >
> > > Philipp Stephani <p.stephani2 <at> gmail.com> writes:
> > >
> > > > Hmm, I can't reproduce this on Debian. But I don't see how this could
> > > > be OS-dependent.
> > >
> > > It reproduces fine here on Debian/bullseye, at least:
> > >
> > > 1 unexpected results:
> > >    FAILED  edebug-tests-duplicate-symbol-backtrack
> > >
> >
> > Yeah, I can also reproduce it now. Not sure what changed in the
> > meantime on my system.
>
> Ah. See the FIXME in the test:
>
>                      ;; FIXME: There are twice as many inner
>                      ;; definitions as expected due to Bug#42701.
>                      ;; Once that bug is fixed, remove the duplicates.
>
> Bug#42701 still isn't fixed, but the fix to bug#48489 has "suppressed"
> its symptom in this case. We can therefore resolve this FIXME.
> However, then the edebug-tests-duplicate-symbol-backtrack doesn't
> really test any more what it should be testing. So I'll see that I can
> change it to restore the previous behavior (which requires
> backtracking and overlapping &or branches).

Done with commit 63e4ed1c8f1c5bbf59c366134d379bae972201f9.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Wed, 16 Jun 2021 11:24:07 GMT) Full text and rfc822 format available.

This bug report was last modified 3 years and 362 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.