bug#64646: Master: Native compiler doesn't always compile lambda forms.

[Andrea Corallo]

Alan Mackenzie <acm@muc.de> writes:

> Hello, Andrea.
>
> On Mon, Jul 17, 2023 at 09:17:13 -0400, Andrea Corallo wrote:
>> Alan Mackenzie <acm@muc.de> writes:
>
>> > In the master branch:
>
>> > (i) emacs -Q
>> > (ii) C-x b foo.el <RET>
>> > (iii) Insert into foo.el:
>> >     ;; -*- lexical-binding:t -*-
>> > (iv) M-x emacs-lisp-mode
>> > (v) Insert into foo.el:
>> >     (defun foo () "foo doc string"
>> >       (lambda (bar) "lambda doc string" (car bar)))
>> > (vi) With point after the function, C-x C-e to evaluate it.
>
>> > (vii) M-: (native-compile 'foo)
>> > This returns #<subr foo>
>> > (viii) M-: (foo)
>> > This returns the lambda form as a byte-compiled function.  This is a bug:
>> > it should return the lambda form as a native-compiled function.
>
>> > Note: this bug is also in the emacs-29 branch.
>
>> Hi Alan,
>
>> I can reproduce, (native-compile 'foo) compiles only foo, compiling the
>> whole compilation unit with eg `emacs-lisp-native-compile-and-load'
>> compiles as expected also the inner lambda.
>
> Why would compiling a .el file compile inner lambda forms, but
> native-compile doesn't?
>
>> I'm not 100% convinced this behaviour is a bug tho.
>
> I don't understand that.  Why might it be incorrect to compile that inner
> lambda natively?

Hi Alan,

I'm not saying it would be incorrect.  I'm suggesting that if is not
specified what's the expected behaviour of compiling by name the outer
lambda it might not be a bug.

When we compile a whole compilation unit we indeed have to compile all
functions, in this case what we promised is I think not defined.

  Andrea