bug#55323: 29.0.50; Session-compiled interactive form gives (invalid-function #<symbol list at 476>)

[Alan Mackenzie <acm@muc.de>]

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).