bug#71934: comp--spill-lap-function and closure (wad: bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects)

[Alan Mackenzie <acm@muc.de>]

Hello, Stefan.

On Fri, Jul 05, 2024 at 11:48:10 -0400, Stefan Monnier wrote:
> >> >> Andrea, can you take a look at this, please?
> >> > Yep, I believe that code does not require to be changed, the input of
> >> > comp--spill-lap-function is a form not an interpred function.
> >> But then why does it check for `closure`?
> > Back in 2023, one of the forms this function found itself unable to
> > compile was a closure.  So I fixed this for bug #64646.

> But there is no such thing as a *form* that looks like
> (closure ...), so if we found such a thing either it was a bug or it
> means that other function values like byte-code (or the new
> `interpreted-function`s) could appear there and should arguably be
> handled as well.

Not sure what you mean by "no such thing as a form ... like a closure".
I bumped into one last summer.

In particular (in my development repo fixing bug #64646) I put this into
*scratch*:

    (defconst foo (lambda (baz) (car baz)))

, evaluated it with C-x C-e and then M-: (native-compile foo).  This
threw the error "Cannot native-compile, form is not a lambda".

The value of foo had been turned into a form (closure ....).  So I fixed
comp--spill-lap-function (form version) so as to compile that form.

I've no idea how Emacs would handle that defconst now.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).