* bug#55323: 29.0.50; Session-compiled interactive form gives (invalid-function #<symbol list at 476>)
@ 2022-05-08 19:29 Bob Rogers
2022-05-10 10:32 ` Alan Mackenzie
2022-05-11 15:20 ` Alan Mackenzie
0 siblings, 2 replies; 5+ messages in thread
From: Bob Rogers @ 2022-05-08 19:29 UTC (permalink / raw)
To: 55323; +Cc: Alan Mackenzie
In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0)
of 2022-05-08 built on orion
Repository revision: 278b18a460caf34e422847d10ac3f0b62bef4996
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12003000
System Description: openSUSE Leap 15.3
The problem occurs with an evaluated "interactive" form in a defun
that is compiled with compile-defun -- and it may have escaped notice
until now because it doesn't seem to happen if the source is part of
Emacs (i.e. is compiled in a file that git knows about).
1. emacs -Q
2. Find an elisp file with an interactive form that does not belong
to an Emacs working copy. I used the align-highlight-rule snippet
below, copied from lisp/align.el.
3. Evaluate the first two forms, and do "M-x compile-defun" to
compile the third.
4. Attempt to invoke the command via "M-x align-highlight-rule RET".
What you should see then is a backtrace that starts something like this:
Debugger entered--Lisp error: (invalid-function #<symbol list at 476>)
(#<symbol list at 476> (#<symbol region-beginning at 482>) ...)
call-interactively(align-highlight-rule record nil)
command-execute(align-highlight-rule record)
Disassembly shows that the interactive form is not compiled, and the
arglist is full of #<symbol X at Y>:
byte code for align-highlight-rule:
doc: Highlight the whitespace which a given rule would have modified. ...
args: (#<symbol beg at 49> #<symbol end at 53> #<symbol title at 57> ...)
interactive: (#<symbol list at 476> (#<symbol region-beginning at 482>) ...)
0 constant intern
1 varref title
2 call 1
3 varref align-mode-exclude-rules-list
Disassembling the in-tree version, whether from "M-x compile-defun" or
file compilation, shows neither of these problems (go figure).
And of course "M-x eval-defun" and "M-x byte-compile-file" continue
to DTRT, so I am not in any hurry for a fix. TIA,
-- Bob Rogers
http://www.rgrjr.com/
------------------------------------------------------------------------
(require 'align)
(setq debug-on-error t)
(defun align-highlight-rule (beg end title &optional rules exclude-rules)
"Highlight the whitespace which a given rule would have modified.
BEG and END mark the extent of the region. TITLE identifies the rule
that should be highlighted. If RULES or EXCLUDE-RULES is set to a
list of rules (see `align-rules-list'), it can be used to override the
default alignment rules that would have been used to identify the text
to be colored."
(interactive
(list (region-beginning) (region-end)
(completing-read
"Title of rule to highlight: "
(mapcar
(lambda (rule)
(list (symbol-name (car rule))))
(append (or align-mode-rules-list align-rules-list)
(or align-mode-exclude-rules-list
align-exclude-rules-list))) nil t)))
(let ((ex-rule (assq (intern title)
(or align-mode-exclude-rules-list
align-exclude-rules-list)))
face)
(align-unhighlight-rule)
(align-region
beg end 'entire
(or rules (if ex-rule
(or exclude-rules align-mode-exclude-rules-list
align-exclude-rules-list)
(or align-mode-rules-list align-rules-list)))
(unless ex-rule (or exclude-rules align-mode-exclude-rules-list
align-exclude-rules-list))
(lambda (b e mode)
(if (and mode (listp mode))
(if (equal (symbol-name (car mode)) title)
(setq face (cons align-highlight-change-face
align-highlight-nochange-face))
(setq face nil))
(when face
(let ((overlay (make-overlay b e)))
(setq align-highlight-overlays
(cons overlay align-highlight-overlays))
(overlay-put overlay 'face
(if mode
(car face)
(cdr face))))))))))
------------------------------------------------------------------------
Configured using:
'configure --with-dbus=no --with-gsettings=no --with-gif=ifavailable
--with-tiff=no --with-gnutls=yes --with-gconf=no'
Configured features:
ACL CAIRO FREETYPE GIF GLIB GMP GNUTLS HARFBUZZ JPEG LIBSELINUX LIBXML2
MODULES NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS
TOOLKIT_SCROLL_BARS X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB
Important settings:
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Major mode: Debugger
Minor modes in effect:
tooltip-mode: t
global-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
buffer-read-only: t
line-number-mode: t
indent-tabs-mode: t
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message mailcap yank-media rmc puny
dired dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg
rfc6068 epg-config gnus-util 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 help-fns radix-tree
cl-print debug backtrace help-mode find-func compile
text-property-search comint ansi-color ring align vc-git diff-mode
easy-mmode vc-dispatcher cl-loaddefs cl-lib seq gv subr-x byte-opt
bytecomp byte-compile cconv 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 nadvice simple 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 abbrev obarray oclosure
cl-preloaded button loaddefs faces cus-face macroexp files window
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget keymap hashtable-print-readable backquote threads inotify
dynamic-setting font-render-setting cairo move-toolbar gtk x-toolkit
xinput2 x multi-tty make-network-process emacs)
Memory information:
((conses 16 63054 8598)
(symbols 48 7628 1)
(strings 32 21891 2878)
(string-bytes 1 716772)
(vectors 16 15096)
(vector-slots 8 202859 11567)
(floats 8 28 36)
(intervals 56 345 0)
(buffers 992 13))
^ permalink raw reply [flat|nested] 5+ messages in thread* bug#55323: 29.0.50; Session-compiled interactive form gives (invalid-function #<symbol list at 476>) 2022-05-08 19:29 bug#55323: 29.0.50; Session-compiled interactive form gives (invalid-function #<symbol list at 476>) Bob Rogers @ 2022-05-10 10:32 ` Alan Mackenzie 2022-05-11 15:20 ` Alan Mackenzie 1 sibling, 0 replies; 5+ messages in thread From: Alan Mackenzie @ 2022-05-10 10:32 UTC (permalink / raw) To: Bob Rogers; +Cc: acm, 55323 Hello, Bob. On Sun, May 08, 2022 at 15:29:12 -0400, Bob Rogers wrote: > In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0) > of 2022-05-08 built on orion > Repository revision: 278b18a460caf34e422847d10ac3f0b62bef4996 > Repository branch: master > Windowing system distributor 'The X.Org Foundation', version 11.0.12003000 > System Description: openSUSE Leap 15.3 > The problem occurs with an evaluated "interactive" form in a defun > that is compiled with compile-defun -- and it may have escaped notice > until now because it doesn't seem to happen if the source is part of > Emacs (i.e. is compiled in a file that git knows about). > 1. emacs -Q > 2. Find an elisp file with an interactive form that does not belong > to an Emacs working copy. I used the align-highlight-rule snippet > below, copied from lisp/align.el. > 3. Evaluate the first two forms, and do "M-x compile-defun" to > compile the third. > 4. Attempt to invoke the command via "M-x align-highlight-rule RET". > What you should see then is a backtrace that starts something like this: > Debugger entered--Lisp error: (invalid-function #<symbol list at 476>) > (#<symbol list at 476> (#<symbol region-beginning at 482>) ...) > call-interactively(align-highlight-rule record nil) > command-execute(align-highlight-rule record) > Disassembly shows that the interactive form is not compiled, and the > arglist is full of #<symbol X at Y>: > byte code for align-highlight-rule: > doc: Highlight the whitespace which a given rule would have modified. ... > args: (#<symbol beg at 49> #<symbol end at 53> #<symbol title at 57> ...) > interactive: (#<symbol list at 476> (#<symbol region-beginning at 482>) ...) > 0 constant intern > 1 varref title > 2 call 1 > 3 varref align-mode-exclude-rules-list > Disassembling the in-tree version, whether from "M-x compile-defun" or > file compilation, shows neither of these problems (go figure). Thanks for taking the trouble to report this bug. I can reproduce it here. At a guess, the critical detail is having align-highlight-rule in a different file's buffer on doing M-x compile-defun. > And of course "M-x eval-defun" and "M-x byte-compile-file" continue > to DTRT, so I am not in any hurry for a fix. TIA, I hope to be able to fix this within a few days. > -- Bob Rogers > http://www.rgrjr.com/ [ .... ] -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#55323: 29.0.50; Session-compiled interactive form gives (invalid-function #<symbol list at 476>) 2022-05-08 19:29 bug#55323: 29.0.50; Session-compiled interactive form gives (invalid-function #<symbol list at 476>) Bob Rogers 2022-05-10 10:32 ` Alan Mackenzie @ 2022-05-11 15:20 ` Alan Mackenzie 2022-05-12 22:45 ` Bob Rogers 1 sibling, 1 reply; 5+ messages in thread From: Alan Mackenzie @ 2022-05-11 15:20 UTC (permalink / raw) To: Bob Rogers; +Cc: acm, 55323 Hello again, Bob. On Sun, May 08, 2022 at 15:29:12 -0400, Bob Rogers wrote: > In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0) > of 2022-05-08 built on orion > Repository revision: 278b18a460caf34e422847d10ac3f0b62bef4996 > Repository branch: master > Windowing system distributor 'The X.Org Foundation', version 11.0.12003000 > System Description: openSUSE Leap 15.3 > The problem occurs with an evaluated "interactive" form in a defun > that is compiled with compile-defun -- and it may have escaped notice > until now because it doesn't seem to happen if the source is part of > Emacs (i.e. is compiled in a file that git knows about). I think what's different is that the source has been copied into a different file, and that file doesn't have a ;; -*- lexical-binding:t -*- at the top. :-) > 1. emacs -Q > 2. Find an elisp file with an interactive form that does not belong > to an Emacs working copy. I used the align-highlight-rule snippet > below, copied from lisp/align.el. > 3. Evaluate the first two forms, and do "M-x compile-defun" to > compile the third. > 4. Attempt to invoke the command via "M-x align-highlight-rule RET". > What you should see then is a backtrace that starts something like this: > Debugger entered--Lisp error: (invalid-function #<symbol list at 476>) > (#<symbol list at 476> (#<symbol region-beginning at 482>) ...) > call-interactively(align-highlight-rule record nil) > command-execute(align-highlight-rule record) > Disassembly shows that the interactive form is not compiled, and the > arglist is full of #<symbol X at Y>: > byte code for align-highlight-rule: > doc: Highlight the whitespace which a given rule would have modified. ... > args: (#<symbol beg at 49> #<symbol end at 53> #<symbol title at 57> ...) > interactive: (#<symbol list at 476> (#<symbol region-beginning at 482>) ...) > 0 constant intern > 1 varref title > 2 call 1 > 3 varref align-mode-exclude-rules-list Yes. For some reason, the interactive form is not compiled when both lexical-binding is nil AND the form looks like (list .....). I don't know why this is, and suspect it's a remnant of a very old bug fix which is no longer relevant. > Disassembling the in-tree version, whether from "M-x compile-defun" or > file compilation, shows neither of these problems (go figure). See above. > And of course "M-x eval-defun" and "M-x byte-compile-file" continue > to DTRT, so I am not in any hurry for a fix. TIA, Would you please try out the following patch, which removes the positions from the symbols with positions in the arglist and the interactive form. Then please let me know how it goes. Thanks! diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el index 28237d67d2..c282d79446 100644 --- a/lisp/emacs-lisp/bytecomp.el +++ b/lisp/emacs-lisp/bytecomp.el @@ -3084,7 +3084,8 @@ byte-compile-lambda ;; which may include "calls" to ;; internal-make-closure (Bug#29988). lexical-binding) - (setq int `(,(car int) ,newform))))) + (setq int `(,(car int) ,newform)) + (setq int (byte-run-strip-symbol-positions int))))) ; for compile-defun. ((cdr int) ; Invalid (interactive . something). (byte-compile-warn-x int "malformed interactive spec: %s" int)))) @@ -3099,7 +3100,7 @@ byte-compile-lambda (byte-compile-make-lambda-lexenv arglistvars)) reserved-csts)) - (bare-arglist arglist)) + (bare-arglist (byte-run-strip-symbol-positions arglist))) ; for compile-defun. ;; Build the actual byte-coded function. (cl-assert (eq 'byte-code (car-safe compiled))) (let ((out > -- Bob Rogers > http://www.rgrjr.com/ -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply related [flat|nested] 5+ messages in thread
* bug#55323: 29.0.50; Session-compiled interactive form gives (invalid-function #<symbol list at 476>) 2022-05-11 15:20 ` Alan Mackenzie @ 2022-05-12 22:45 ` Bob Rogers 2022-05-18 9:30 ` Alan Mackenzie 0 siblings, 1 reply; 5+ messages in thread From: Bob Rogers @ 2022-05-12 22:45 UTC (permalink / raw) To: Alan Mackenzie; +Cc: 55323 From: Alan Mackenzie <acm@muc.de> Date: Wed, 11 May 2022 15:20:04 +0000 Hello again, Bob. On Sun, May 08, 2022 at 15:29:12 -0400, Bob Rogers wrote: . . . > The problem occurs with an evaluated "interactive" form in a defun > that is compiled with compile-defun -- and it may have escaped notice > until now because it doesn't seem to happen if the source is part of > Emacs (i.e. is compiled in a file that git knows about). I think what's different is that the source has been copied into a different file, and that file doesn't have a ;; -*- lexical-binding:t -*- at the top. :-) Aha! That makes much more sense. I first encountered this in some of my own code which I've been lazy about switching to "lexical-binding:t". . . . > Disassembly shows that the interactive form is not compiled, and the > arglist is full of #<symbol X at Y>: . . . Yes. For some reason, the interactive form is not compiled when both lexical-binding is nil AND the form looks like (list .....). I don't know why this is, and suspect it's a remnant of a very old bug fix which is no longer relevant. > And of course "M-x eval-defun" and "M-x byte-compile-file" continue > to DTRT, so I am not in any hurry for a fix. TIA, Would you please try out the following patch, which removes the positions from the symbols with positions in the arglist and the interactive form. Then please let me know how it goes. Thanks! . . . -- Alan Mackenzie (Nuremberg, Germany). The patch does work when I run my test case (though I get a different error because I'm not invoking align-highlight-rule appropriately). And (as you say) the "interactive" form is compiled when lexical-binding is nil. -- Bob ^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#55323: 29.0.50; Session-compiled interactive form gives (invalid-function #<symbol list at 476>) 2022-05-12 22:45 ` Bob Rogers @ 2022-05-18 9:30 ` Alan Mackenzie 0 siblings, 0 replies; 5+ messages in thread From: Alan Mackenzie @ 2022-05-18 9:30 UTC (permalink / raw) To: Bob Rogers; +Cc: 55323-done Hello, Bob. On Thu, May 12, 2022 at 18:45:00 -0400, Bob Rogers wrote: [ .... ] > The patch does work when I run my test case (though I get a different > error because I'm not invoking align-highlight-rule appropriately). And > (as you say) the "interactive" form is compiled when lexical-binding > is nil. Thanks for the testing. I've now committed the patch (slightly enhanced), and I'm closing the bug with this post. > -- Bob -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2022-05-18 9:30 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2022-05-08 19:29 bug#55323: 29.0.50; Session-compiled interactive form gives (invalid-function #<symbol list at 476>) Bob Rogers 2022-05-10 10:32 ` Alan Mackenzie 2022-05-11 15:20 ` Alan Mackenzie 2022-05-12 22:45 ` Bob Rogers 2022-05-18 9:30 ` Alan Mackenzie
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).