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>]

Andrea Corallo <acorallo@gnu.org> writes:

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

Okay should be done with b9b9322a8e6 in master adding a test and
updating 'native-compile' doc-string.

Is there anything left to do for this bug?

  Andrea