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

[Andrea Corallo <acorallo@gnu.org>]

Alan Mackenzie <acm@muc.de> writes:

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

I'm a little confused, I believe #64646 was about:

(defun foo ())
(native-compile 'foo)

Which still works for me on emacs-30, no?

  Andrea