Re: Question about native compilation (bug?)

[Andrea Corallo]

Drew Adams <drew.adams@oracle.com> writes:

> I don't have native compilation for my laptop, but I received a bug report 
> from a user of one of my libraries, and I get the feeling that native 
> compilation (which this user has) is interfering and perhaps bugged.
>
> 1. My code, when loaded, saves the original definitions of some functions, 
> such as `read-buffer', by creating a `defalias' for each of them, such as 
> this one:
>
> (defalias 'ORIG-read-buffer
>           (symbol-function 'read-buffer)
>
> 2. I define a global minor mode that, when turned on, redefines those saved 
> functions, such as `read-buffer', using `fset', to using definitions 
> appropriate to the minor mode.  
>
> 3. When the minor mode is turned off I reset those function definitions to 
> the saved (`defalias'ed) versions, using `fset'.
>
> (I do this dance because I want the library to work properly also with older 
> Emacs versions.  No comments, please, about its fragility or other 
> weaknesses.)
> ___
>
> This is the problem, reported in Emacs 28.2 with native compilation:
>
> Emacs 28 added an additional optional arg to function `read-buffer' (which is 
> defined in C).  My substitute version of `read-buffer', which is used when my 
> minor mode is turned on, has only 1 required arg and 2 optional, not 1 
> required and 3 optional.
>
> Obviously, for any code that will try to pass 4 args, I need to update my 
> code to accommodate the 4th arg.  I haven't done that yet.
>
> But my question is about code that ostensibly passes 3 or fewer args.  An 
> error is nevertheless raised, saying that 4 args were passed and only 3 were 
> allowed.  The standard code, whose vanilla source definition (in `window.el') 
> passes only 3 args, in actuality, at runtime, passes 4 args, the 4th one 
> being explicitly nil.
>
> Recipe: the minor mode is turned on, and `C-x 5 b' is tried.  An error is 
> raised:
>
> Debugger entered--Lisp error: (wrong-number-of-arguments #<subr 
> my-read-buffer> 4)
>   read-buffer("Switch to buffer in other frame: " #<buffer foo> 
> confirm-after-completion nil)
>   read-buffer-to-switch("Switch to buffer in other frame: ")
>   byte-code("\300\301!C\207" [read-buffer-to-switch "Switch to buffer in 
> other frame: "] 2)
>   call-interactively(switch-to-buffer-other-frame nil nil)
>   command-execute(switch-to-buffer-other-frame)
>
> I wouldn't have a clue to what is going on here from that backtrace, since 
> function `my-read-buffer' accepts 3 args and the source code for 
> `read-buffer-to-switch' passes 3 args.
>
> I got a glue (I think), from this: For the reporting user `C-h k C-x 5 b' 
> says this:
>
> C-x 5 b runs the command switch-to-buffer-other-frame (found in global-map), 
> which is an interactive native-compiled Lisp function in 
> '/var/lib/snapd/snap/emacs/2031/usr/share/emacs/28.2/lisp/window.el'.
>
> It's that "native-compiled" that makes me wonder.  If the user loads the Lisp 
> source file, `window.el', there's no problem.  But it looks kinda like native 
> compilation has "baked-in" the call to `read-buffer', passing an explicit 4th 
> arg, nil, instead of passing only the 3 args that the source code says to 
> pass.
>
> Passing 4 args, the last of which is nil, isn't the same thing as passing 3 
> args, but it looks like native compilation takes a shortcut, assuming that 
> it's the same thing.
>
> Is this a native-compilation bug?  Is it some other Emacs bug?  Or is this 
> just the way things are going to be from now on - "situation normale, rien à 
> signaler"?
>
> Let me know, if my guesses are near the target, or if I'm missing something.

Redefining a primitive (thing that is not recommended but often done)
one must at least use the same signature as the original one.  I don't
think we support the case where the new definition is of a different
signature.  Native compilation might be just more sensitive in this
unsupported condition.

  Andrea