Subject: bug#64646: closed (Re: bug#64646: Master: Native compiler doesn't always compile lambda forms.)

From: [email-masked] (GNU bug Tracking System)
Date: Wed, 08 Nov 2023 21:01:02 +0000

Your bug report

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

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
64646: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=64646
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#64646: Master: Native compiler doesn't always compile lambda forms.
From: Alan Mackenzie <[email-masked]>
To: Andrea Corallo <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Wed, 8 Nov 2023 20:59:42 +0000
List-Id: <debbugs-submit.debbugs.gnu.org>

Hello, Andrea.

On Thu, Nov 02, 2023 at 13:32:21 -0400, Andrea Corallo wrote:
> Alan Mackenzie <[email-masked]> writes:

> > This bug doesn't seem to be moving, so ....

> > On Wed, Jul 26, 2023 at 10:57:01 -0400, Andrea Corallo wrote:
> >> Alan Mackenzie <[email-masked]> writes:

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

> > I still don't understand that.  The doc string for native-compile says:

> >     Compile FUNCTION-OR-FILE into native code.

> > ..  I can't see any reason not also to compile inner lambda functions
> > natively.

> > Anyhow, to fix this bug (if such it be) is easy:

> > diff --git a/lisp/emacs-lisp/comp.el b/lisp/emacs-lisp/comp.el
> > index 181e5ca96a1..2360fbaa494 100644
> > --- a/lisp/emacs-lisp/comp.el
> > +++ b/lisp/emacs-lisp/comp.el
> > @@ -1359,7 +1359,12 @@ comp-add-func-to-ctxt
> >                (comp-ctxt-top-level-forms comp-ctxt)
> >                (list (make-byte-to-native-func-def :name function-name
> >                                                    :c-name c-name)))
> > -        (comp-add-func-to-ctxt func))))
> > +        (comp-add-func-to-ctxt func))
> > +      ;; Handle any lambda functions in BYTE-CODE.
> > +      (maphash (lambda (key val)
> > +                 (unless (eq key (aref byte-code 1))
> > +                   (comp-intern-func-in-ctxt key val)))
> > +               byte-to-native-lambdas-h)))

> >  (cl-defmethod comp-spill-lap-function ((form list))
> >    "Byte-compile FORM, spilling data from the byte compiler."

> > What do you say?

> LGTM as long as indeed it does not regress any test. Speaking of which
> with the patch I guess we want a test to cover this.

Thanks.  I've committed a patch for this, including two extra tests which
test that a nested lambda function also gets native compiled.

I'm closing the bug with this post.

> > Incidentally, the code in the various comp-spill-lap-function methods
> > together with comp-intern-func-in-ctxt appears to have some code
> > duplication.  Would it be possible to have the symbol and list methods of
> > comp-spill-lap-function simply call comp-intern-func-in-ctxt the way the
> > string method does?  That would simplify those two methods quite a bit.

> Mmmh maybe, I think one has to try to see if the result is satisfactory.

I've done this refactoring too.  The symbol and list methods for
comp-spill-lap-function now have 17 and 15 lines respectively.  I hope
you like it!

> Thanks

>   Andrea

-- 
Alan Mackenzie (Nuremberg, Germany).

Subject: Master: Native compiler doesn't always compile lambda forms.
From: Alan Mackenzie <[email-masked]>
To: [email-masked]
Date: Sat, 15 Jul 2023 12:10:06 +0000
List-Id: <debbugs-submit.debbugs.gnu.org>

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.

-- 
Alan Mackenzie (Nuremberg, Germany).