GNU bug report logs - #71934
31.0.50; edebug--called-interactively-skip vs. new fun objects

Previous Next

Full log

View this message in rfc822 format

From: Andrea Corallo <acorallo <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>, 71934 <at> debbugs.gnu.org
Subject: bug#71934: comp--spill-lap-function and closure (wad: bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects)
Date: Sat, 06 Jul 2024 03:48:50 -0400

Alan Mackenzie <acm <at> 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, the functionality you added was:

(defun foo () "foo doc string"
       (lambda () "lambda doc string" 3))

(subr-native-elisp-p (funcall (native-compile 'foo)))

And this still works for me.

I'm probably missing something sorry.

  Andrea

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.