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, Andrea.
>
> On Sat, Jul 06, 2024 at 03:48:50 -0400, Andrea Corallo wrote:
>> Alan Mackenzie <acm@muc.de> writes:
>
>> > Hello, Stefan.
>
>> > On Fri, Jul 05, 2024 at 14:17:38 -0400, Stefan Monnier wrote:
>> >> > Not sure what you mean by "no such thing as a form ... like a closure".
>
>> >> A form that starts with `closure` is not a valid form because there is
>> >> no definition for `closure`: (fboundp 'closure) => nil.
>
>> >> > 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".
>
>> >> That error seems right according to the docstring:
>
>> >>    (defun native-compile (function-or-file &optional output)
>> >>      "Compile FUNCTION-OR-FILE into native code.
>> >>    This is the synchronous entry-point for the Emacs Lisp native
>> >>    compiler.  FUNCTION-OR-FILE is a function symbol, a form, or the
>> >>    filename of an Emacs Lisp source file.  If OUTPUT is non-nil, use
>> >>    it as the filename for the compiled object.  If FUNCTION-OR-FILE
>> >>    is a filename, if the compilation was successful return the
>> >>    filename of the compiled object.  If FUNCTION-OR-FILE is a
>> >>    function symbol or a form, if the compilation was successful
>> >>    return the compiled function."
>
>> >> (closure ...) is not a function symbol nor a valid form.  Instead it's
>> >> a function value and the docstring doesn't say such are
>> >> a valid arguments to `native-compile`.
>
>> > All very clever arguments, no doubt, but in the end it means you cannot
>> > native compile foo.  I've just tried it on emacs-30, and it doesn't work.
>> > But you could compile foo last summer after my fixes for bug #64646.
>> > Between last summer and now, something has gone badly wrong in Emacs's
>> > basic mechanisms.
>
>> (defconst foo (lambda (baz) (car baz)))
>> (native-compile #'foo)
>
>> Never worked AFAIR, ....
>
> No.  But (native-compile foo) did work.  It compiled the value of foo,
> producing an anonymous subr.
>
>> ....the functionality you added was:
>
>> (defun foo () "foo doc string"
>>        (lambda () "lambda doc string" 3))
>
>> (subr-native-elisp-p (funcall (native-compile 'foo)))
>
> Yes.
>
>> And this still works for me.
>
> It still works for me, too.
>
>> I'm probably missing something sorry.
>
> The fact that
>
> 	(defconst foo (lambda (baz) (car baz)))
> 	(native-compile foo)
>
> worked (as of 2023-11-08), but no longer does.  It was not the main topic
> of bug #64646 (for which see above), but was fixed in the commit for that
> bug anyway.  This was possibly not a good idea.  That commit was:
>
> commit 06e4ebc81a44c709b08ce72c746629c6c77e6f6e
> Author: Alan Mackenzie <acm@muc.de>
> Date:   Wed Nov 8 20:49:48 2023 +0000
>
>     With `native-compile', compile lambdas in a defun or lambda too

Thanks I see now, at least we never regressed over releases.

I think this functionaly passed under my radar at the time, otherwise I
would have asked for a test covering it, and BTW as a consequence Stefan
would have updated the implementation before upstreaming his patch :)

Anyway as
(defconst foo (lambda (baz) (car baz)))
(byte-compile foo)
works, I is nice to have it functional for native-comp as well.

Reintroducing it should not be too difficult, I can do it myself next
week if no-one does it before.

Thanks

  Andrea