* bug#53071: 28.0.90; Emacs 28 regression: incorrect code generation for complex pcase forms?
@ 2022-01-07 9:36 Philipp Stephani
2022-01-12 2:19 ` Philipp
0 siblings, 1 reply; 9+ messages in thread
From: Philipp Stephani @ 2022-01-07 9:36 UTC (permalink / raw)
To: 53071
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#53071: 28.0.90; Emacs 28 regression: incorrect code generation for complex pcase forms?
2022-01-07 9:36 bug#53071: 28.0.90; Emacs 28 regression: incorrect code generation for complex pcase forms? Philipp Stephani
@ 2022-01-12 2:19 ` Philipp
2022-01-12 14:10 ` Michael Heerdegen
0 siblings, 1 reply; 9+ messages in thread
From: Philipp @ 2022-01-12 2:19 UTC (permalink / raw)
To: 53071
> Am 07.01.2022 um 10:36 schrieb Philipp Stephani <p.stephani2@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@acm.org>
Date: Fri Mar 5 20:21:01 2021 +0100
Make lambda-lifting work again
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#53071: 28.0.90; Emacs 28 regression: incorrect code generation for complex pcase forms?
2022-01-12 2:19 ` Philipp
@ 2022-01-12 14:10 ` Michael Heerdegen
2022-01-12 15:35 ` Mattias Engdegård
0 siblings, 1 reply; 9+ messages in thread
From: Michael Heerdegen @ 2022-01-12 14:10 UTC (permalink / raw)
To: Philipp; +Cc: Mattias Engdegård, 53071
Philipp <p.stephani2@gmail.com> writes:
> 'git bisect' claims that the following commit is the culprit:
>
> commit 1362a9fec4dff341a84c881ac17dbf1ee2cf82fd
> Author: Mattias Engdegård <mattiase@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@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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#53071: 28.0.90; Emacs 28 regression: incorrect code generation for complex pcase forms?
2022-01-12 14:10 ` Michael Heerdegen
@ 2022-01-12 15:35 ` Mattias Engdegård
2022-01-12 16:03 ` Mattias Engdegård
0 siblings, 1 reply; 9+ messages in thread
From: Mattias Engdegård @ 2022-01-12 15:35 UTC (permalink / raw)
To: Michael Heerdegen; +Cc: Philipp, Stefan Monnier, 53071
12 jan. 2022 kl. 15.10 skrev Michael Heerdegen <michael_heerdegen@web.de>:
>> commit 1362a9fec4dff341a84c881ac17dbf1ee2cf82fd
>> Author: Mattias Engdegård <mattiase@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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#53071: 28.0.90; Emacs 28 regression: incorrect code generation for complex pcase forms?
2022-01-12 15:35 ` Mattias Engdegård
@ 2022-01-12 16:03 ` Mattias Engdegård
2022-01-12 16:58 ` Eli Zaretskii
0 siblings, 1 reply; 9+ messages in thread
From: Mattias Engdegård @ 2022-01-12 16:03 UTC (permalink / raw)
To: Michael Heerdegen; +Cc: 53071-done, Philipp, Stefan Monnier, Paul Pogonyshev
12 jan. 2022 kl. 16.35 skrev Mattias Engdegård <mattiase@acm.org>:
>
> 12 jan. 2022 kl. 15.10 skrev Michael Heerdegen <michael_heerdegen@web.de>:
>
>>> commit 1362a9fec4dff341a84c881ac17dbf1ee2cf82fd
>>> Author: Mattias Engdegård <mattiase@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!
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#53071: 28.0.90; Emacs 28 regression: incorrect code generation for complex pcase forms?
2022-01-12 16:03 ` Mattias Engdegård
@ 2022-01-12 16:58 ` Eli Zaretskii
2022-01-12 19:09 ` Mattias Engdegård
0 siblings, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2022-01-12 16:58 UTC (permalink / raw)
To: Mattias Engdegård; +Cc: p.stephani2, 53071
> From: Mattias Engdegård <mattiase@acm.org>
> Date: Wed, 12 Jan 2022 17:03:44 +0100
> Cc: 53071-done@debbugs.gnu.org, Philipp <p.stephani2@gmail.com>,
> Stefan Monnier <monnier@iro.umontreal.ca>,
> Paul Pogonyshev <pogonyshev@gmail.com>
>
> >>> commit 1362a9fec4dff341a84c881ac17dbf1ee2cf82fd
> >>> Author: Mattias Engdegård <mattiase@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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#53071: 28.0.90; Emacs 28 regression: incorrect code generation for complex pcase forms?
2022-01-12 16:58 ` Eli Zaretskii
@ 2022-01-12 19:09 ` Mattias Engdegård
2022-01-12 19:33 ` Eli Zaretskii
2022-01-12 19:37 ` Philipp Stephani
0 siblings, 2 replies; 9+ messages in thread
From: Mattias Engdegård @ 2022-01-12 19:09 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Philipp, Paul Pogonyshev, 53071
12 jan. 2022 kl. 17.58 skrev Eli Zaretskii <eliz@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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#53071: 28.0.90; Emacs 28 regression: incorrect code generation for complex pcase forms?
2022-01-12 19:09 ` Mattias Engdegård
@ 2022-01-12 19:33 ` Eli Zaretskii
2022-01-12 19:37 ` Philipp Stephani
1 sibling, 0 replies; 9+ messages in thread
From: Eli Zaretskii @ 2022-01-12 19:33 UTC (permalink / raw)
To: Mattias Engdegård; +Cc: p.stephani2, pogonyshev, 53071
> From: Mattias Engdegård <mattiase@acm.org>
> Date: Wed, 12 Jan 2022 20:09:26 +0100
> Cc: 53071@debbugs.gnu.org, Philipp <p.stephani2@gmail.com>,
> Paul Pogonyshev <pogonyshev@gmail.com>
>
> 12 jan. 2022 kl. 17.58 skrev Eli Zaretskii <eliz@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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#53071: 28.0.90; Emacs 28 regression: incorrect code generation for complex pcase forms?
2022-01-12 19:09 ` Mattias Engdegård
2022-01-12 19:33 ` Eli Zaretskii
@ 2022-01-12 19:37 ` Philipp Stephani
1 sibling, 0 replies; 9+ messages in thread
From: Philipp Stephani @ 2022-01-12 19:37 UTC (permalink / raw)
To: Mattias Engdegård; +Cc: Paul Pogonyshev, 53071
Am Mi., 12. Jan. 2022 um 20:09 Uhr schrieb Mattias Engdegård <mattiase@acm.org>:
>
> 12 jan. 2022 kl. 17.58 skrev Eli Zaretskii <eliz@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.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2022-01-12 19:37 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-07 9:36 bug#53071: 28.0.90; Emacs 28 regression: incorrect code generation for complex pcase forms? Philipp Stephani
2022-01-12 2:19 ` Philipp
2022-01-12 14:10 ` Michael Heerdegen
2022-01-12 15:35 ` Mattias Engdegård
2022-01-12 16:03 ` Mattias Engdegård
2022-01-12 16:58 ` Eli Zaretskii
2022-01-12 19:09 ` Mattias Engdegård
2022-01-12 19:33 ` Eli Zaretskii
2022-01-12 19:37 ` Philipp Stephani
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).