GNU bug report logs - #53071
28.0.90; Emacs 28 regression: incorrect code generation for complex pcase forms?

Previous Next

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

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

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

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.90; Emacs 28 regression: incorrect code generation for complex
 pcase forms?
Date: Fri, 07 Jan 2022 10:36:03 +0100

I hit the following subtle Edebug regression in Emacs 28:

Create a file /tmp/pcase-edebug.el with these contents:

$ cat /tmp/pcase-edebug.el 
;; -*- lexical-binding: t; -*-
(require 'rx)
(defun f (a)
  (pcase a
    ((rx bos (let q (opt (let r nonl)) (let a nonl)))
     (message "%s" a))
    ((rx bos eos)
     (message "%s" a))))

Visit the file in Emacs:

$ emacs -Q -l rx /tmp/pcase-edebug.el

Move point into the `f' function and instrument it using C-u C-M-x.
Then, byte-compile `f' using M-: (byte-compile 'f).
In Emacs 28, this will generate the following warnings:

 Warning: Unused lexical variable `q'
 Warning: Unused lexical variable `r'
 Warning: reference to free variable ‘a’

The first two are expected, the third one is not.
Indeed, M-: (f "ab") and stepping through the code will signal an error:

   Symbol's value as variable is void: a

This doesn't happen in Emacs 27, so I think it should be fixed on the
release branch before releasing Emacs 28.


In GNU Emacs 28.0.90 (build 12, x86_64-pc-linux-gnu, GTK+ Version 3.24.30, cairo version 1.16.0)
 of 2022-01-05
Repository revision: c0cfbca311e6e07e9f8b9c1c9d0e2fe9792cd08c
Repository branch: emacs-28
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Debian GNU/Linux rodete

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

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG SECCOMP
SOUND THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE XIM XPM GTK3 ZLIB

Important settings:
  value of $LC_TIME: en_DK.utf8
  value of $LANG: en_US.utf8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-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
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug sendmail phst skeleton edmacro kmacro
pcase ffap thingatpt url url-proxy url-privacy url-expand url-methods
url-history url-cookie url-domsuf url-util url-parse url-vars mailcap rx
message rmc dired dired-loaddefs rfc822 mml mml-sec epa derived epg
rfc6068 epg-config gnus-util rmail rmail-loaddefs auth-source cl-seq
eieio eieio-core cl-macs eieio-loaddefs password-cache json map
time-date mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047
rfc2045 mm-util ietf-drums mail-prsvr mailabbrev mail-utils gmm-utils
mailheader gnutls puny elp 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 paren electric uniquify
ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-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 emoji-zwj 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 dbusbind inotify
dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 69586 8115)
 (symbols 48 8528 3)
 (strings 32 24811 2252)
 (string-bytes 1 802373)
 (vectors 16 15668)
 (vector-slots 8 207469 17113)
 (floats 8 29 46)
 (intervals 56 228 0)
 (buffers 992 11))

-- 
Google Germany GmbH
Erika-Mann-Straße 33
80636 München

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich.  Falls Sie diese fälschlicherweise erhalten haben
sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie
alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail
an die falsche Person gesendet wurde.

This e-mail is confidential.  If you received this communication by mistake,
please don’t forward it to anyone else, please erase all copies and
attachments, and please let me know that it has gone to the wrong person.

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

From: Philipp <p.stephani2 <at> gmail.com>
To: 53071 <at> debbugs.gnu.org
Subject: Re: bug#53071: 28.0.90; Emacs 28 regression: incorrect code
 generation for complex pcase forms?
Date: Wed, 12 Jan 2022 03:19:42 +0100

> Am 07.01.2022 um 10:36 schrieb Philipp Stephani <p.stephani2 <at> gmail.com>:
> 
> 
> I hit the following subtle Edebug regression in Emacs 28:
> 
> Create a file /tmp/pcase-edebug.el with these contents:
> 
> $ cat /tmp/pcase-edebug.el 
> ;; -*- lexical-binding: t; -*-
> (require 'rx)
> (defun f (a)
>  (pcase a
>    ((rx bos (let q (opt (let r nonl)) (let a nonl)))
>     (message "%s" a))
>    ((rx bos eos)
>     (message "%s" a))))
> 
> Visit the file in Emacs:
> 
> $ emacs -Q -l rx /tmp/pcase-edebug.el
> 
> Move point into the `f' function and instrument it using C-u C-M-x.
> Then, byte-compile `f' using M-: (byte-compile 'f).
> In Emacs 28, this will generate the following warnings:
> 
> Warning: Unused lexical variable `q'
> Warning: Unused lexical variable `r'
> Warning: reference to free variable ‘a’
> 
> The first two are expected, the third one is not.
> Indeed, M-: (f "ab") and stepping through the code will signal an error:
> 
>   Symbol's value as variable is void: a

'git bisect' claims that the following commit is the culprit:

commit 1362a9fec4dff341a84c881ac17dbf1ee2cf82fd
Author: Mattias Engdegård <mattiase <at> acm.org>
Date:   Fri Mar 5 20:21:01 2021 +0100

    Make lambda-lifting work again
    

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Philipp <p.stephani2 <at> gmail.com>
Cc: Mattias Engdegård <mattiase <at> acm.org>,
 53071 <at> debbugs.gnu.org
Subject: Re: bug#53071: 28.0.90; Emacs 28 regression: incorrect code
 generation for complex pcase forms?
Date: Wed, 12 Jan 2022 15:10:12 +0100

Philipp <p.stephani2 <at> gmail.com> writes:

> 'git bisect' claims that the following commit is the culprit:
>
> commit 1362a9fec4dff341a84c881ac17dbf1ee2cf82fd
> Author: Mattias Engdegård <mattiase <at> acm.org>
> Date:   Fri Mar 5 20:21:01 2021 +0100
>
>     Make lambda-lifting work again

Not that again.  Let's CC Mattias then.

> > Am 07.01.2022 um 10:36 schrieb Philipp Stephani <p.stephani2 <at> gmail.com>:
> > 
> > I hit the following subtle Edebug regression in Emacs 28:
> > 
> > Create a file /tmp/pcase-edebug.el with these contents:
> > 
> > $ cat /tmp/pcase-edebug.el 
> > ;; -*- lexical-binding: t; -*-
> > (require 'rx)
> > (defun f (a)
> >  (pcase a
> >    ((rx bos (let q (opt (let r nonl)) (let a nonl)))
> >     (message "%s" a))
> >    ((rx bos eos)
> >     (message "%s" a))))
> > 
> > Visit the file in Emacs:
> > 
> > $ emacs -Q -l rx /tmp/pcase-edebug.el
> > 
> > Move point into the `f' function and instrument it using C-u C-M-x.
> > Then, byte-compile `f' using M-: (byte-compile 'f).
> > In Emacs 28, this will generate the following warnings:
> > 
> > Warning: Unused lexical variable `q'
> > Warning: Unused lexical variable `r'
> > Warning: reference to free variable ‘a’
> > 
> > The first two are expected, the third one is not.
> > Indeed, M-: (f "ab") and stepping through the code will signal an error:
> > 
> >   Symbol's value as variable is void: a

Michael.

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

From: Mattias Engdegård <mattiase <at> acm.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: Philipp <p.stephani2 <at> gmail.com>, Stefan Monnier <monnier <at> iro.umontreal.ca>,
 53071 <at> debbugs.gnu.org
Subject: Re: bug#53071: 28.0.90; Emacs 28 regression: incorrect code
 generation for complex pcase forms?
Date: Wed, 12 Jan 2022 16:35:56 +0100

12 jan. 2022 kl. 15.10 skrev Michael Heerdegen <michael_heerdegen <at> web.de>:

>> commit 1362a9fec4dff341a84c881ac17dbf1ee2cf82fd
>> Author: Mattias Engdegård <mattiase <at> acm.org>
>> Date:   Fri Mar 5 20:21:01 2021 +0100
>> 
>>    Make lambda-lifting work again
> 
> Not that again.  Let's CC Mattias then.

Again? In any case, that change only fixed a typo in earlier code by Stefan. More likely to be a logic error in the parent change (a350ae058cae), or in edebug.

I'll give it a quick look just the same. The bug doesn't seem to be present on master.

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

From: Mattias Engdegård <mattiase <at> acm.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 53071-done <at> debbugs.gnu.org, Philipp <p.stephani2 <at> gmail.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>,
 Paul Pogonyshev <pogonyshev <at> gmail.com>
Subject: Re: bug#53071: 28.0.90; Emacs 28 regression: incorrect code
 generation for complex pcase forms?
Date: Wed, 12 Jan 2022 17:03:44 +0100

12 jan. 2022 kl. 16.35 skrev Mattias Engdegård <mattiase <at> acm.org>:
> 
> 12 jan. 2022 kl. 15.10 skrev Michael Heerdegen <michael_heerdegen <at> web.de>:
> 
>>> commit 1362a9fec4dff341a84c881ac17dbf1ee2cf82fd
>>> Author: Mattias Engdegård <mattiase <at> acm.org>
>>> Date:   Fri Mar 5 20:21:01 2021 +0100
>>> 
>>>   Make lambda-lifting work again
>> 
>> Not that again.  Let's CC Mattias then.
> 
> Again? In any case, that change only fixed a typo in earlier code by Stefan. More likely to be a logic error in the parent change (a350ae058cae), or in edebug.

No, you're right, it's bug#51982 again. I've backported the fix from master, which we should have done from the beginning. Paul, I'd like to say on record that listening to you would have saved us much time.

Thanks for bringing this to my attention!

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: p.stephani2 <at> gmail.com, 53071 <at> debbugs.gnu.org
Subject: Re: bug#53071: 28.0.90;
 Emacs 28 regression: incorrect code generation for complex pcase
 forms?
Date: Wed, 12 Jan 2022 18:58:45 +0200

> From: Mattias Engdegård <mattiase <at> acm.org>
> Date: Wed, 12 Jan 2022 17:03:44 +0100
> Cc: 53071-done <at> debbugs.gnu.org, Philipp <p.stephani2 <at> gmail.com>,
>  Stefan Monnier <monnier <at> iro.umontreal.ca>,
>  Paul Pogonyshev <pogonyshev <at> gmail.com>
> 
> >>> commit 1362a9fec4dff341a84c881ac17dbf1ee2cf82fd
> >>> Author: Mattias Engdegård <mattiase <at> acm.org>
> >>> Date:   Fri Mar 5 20:21:01 2021 +0100
> >>> 
> >>>   Make lambda-lifting work again
> >> 
> >> Not that again.  Let's CC Mattias then.
> > 
> > Again? In any case, that change only fixed a typo in earlier code by Stefan. More likely to be a logic error in the parent change (a350ae058cae), or in edebug.
> 
> No, you're right, it's bug#51982 again. I've backported the fix from master, which we should have done from the beginning. Paul, I'd like to say on record that listening to you would have saved us much time.

Emacs 28 is in a very good shape, and no serious problems were
reported in several weeks.  We could release Emacs 28.1 in a few
weeks, fingers crossed.

So I'm about to revert this backport, but I'm prepared to hear
arguments why shouldn't I.

From my POV, the regression is very minor, and it doesn't justify such
a non-trivial change in such a central place.  If you think the
problem is serious, I'd rather revert the change we did which produced
the regression in the first place (assuming it's not too complicated).

Thanks.

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

From: Mattias Engdegård <mattiase <at> acm.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Philipp <p.stephani2 <at> gmail.com>, Paul Pogonyshev <pogonyshev <at> gmail.com>,
 53071 <at> debbugs.gnu.org
Subject: Re: bug#53071: 28.0.90; Emacs 28 regression: incorrect code
 generation for complex pcase forms?
Date: Wed, 12 Jan 2022 20:09:26 +0100

12 jan. 2022 kl. 17.58 skrev Eli Zaretskii <eliz <at> gnu.org>:

> So I'm about to revert this backport, but I'm prepared to hear
> arguments why shouldn't I.

I broke protocol by pushing it to the stable branch in this phase without permission. Sorry about that; the change has now been reverted. Will be more careful in the future.

> From my POV, the regression is very minor, and it doesn't justify such
> a non-trivial change in such a central place.

I personally don't care much about it since I don't use Emacs 28 but would certainly not prefer at least two known, documented and harmful bugs reported by our users over some vague hypothetical conjectured problem that might arise.

>  If you think the
> problem is serious, I'd rather revert the change we did which produced
> the regression in the first place (assuming it's not too complicated).

That would be inadvisable as it would introduce yet another bug, the fix of which was the immediate cause of the regression.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: p.stephani2 <at> gmail.com, pogonyshev <at> gmail.com, 53071 <at> debbugs.gnu.org
Subject: Re: bug#53071: 28.0.90; Emacs 28 regression: incorrect code
 generation for complex pcase forms?
Date: Wed, 12 Jan 2022 21:33:38 +0200

> From: Mattias Engdegård <mattiase <at> acm.org>
> Date: Wed, 12 Jan 2022 20:09:26 +0100
> Cc: 53071 <at> debbugs.gnu.org, Philipp <p.stephani2 <at> gmail.com>,
>         Paul Pogonyshev <pogonyshev <at> gmail.com>
> 
> 12 jan. 2022 kl. 17.58 skrev Eli Zaretskii <eliz <at> gnu.org>:
> 
> > So I'm about to revert this backport, but I'm prepared to hear
> > arguments why shouldn't I.
> 
> I broke protocol by pushing it to the stable branch in this phase without permission. Sorry about that; the change has now been reverted. Will be more careful in the future.
> 
> > From my POV, the regression is very minor, and it doesn't justify such
> > a non-trivial change in such a central place.
> 
> I personally don't care much about it since I don't use Emacs 28 but would certainly not prefer at least two known, documented and harmful bugs reported by our users over some vague hypothetical conjectured problem that might arise.
> 
> >  If you think the
> > problem is serious, I'd rather revert the change we did which produced
> > the regression in the first place (assuming it's not too complicated).
> 
> That would be inadvisable as it would introduce yet another bug, the fix of which was the immediate cause of the regression.

Fine by me, then let's leave emacs-28 at its present state.

Thanks.

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

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Paul Pogonyshev <pogonyshev <at> gmail.com>,
 53071 <at> debbugs.gnu.org
Subject: Re: bug#53071: 28.0.90; Emacs 28 regression: incorrect code
 generation for complex pcase forms?
Date: Wed, 12 Jan 2022 20:37:21 +0100

Am Mi., 12. Jan. 2022 um 20:09 Uhr schrieb Mattias Engdegård <mattiase <at> acm.org>:
>
> 12 jan. 2022 kl. 17.58 skrev Eli Zaretskii <eliz <at> gnu.org>:
>
> > So I'm about to revert this backport, but I'm prepared to hear
> > arguments why shouldn't I.
>
> I broke protocol by pushing it to the stable branch in this phase without permission. Sorry about that; the change has now been reverted. Will be more careful in the future.

Is there a workaround? Seems like renaming the shadowed variables
would help, but I'm not 100% sure.

Previous Next

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