Subject: bug#61880: closed (Re: bug#61880: Native compilation fails to generate trampolines on certain scenarios)

From: [email-masked] (GNU bug Tracking System)
Date: Thu, 09 Mar 2023 11:37:01 +0000

Your bug report

#61880: Native compilation fails to generate trampolines on certain scenarios

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

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

Subject: Re: bug#61880: Native compilation fails to generate trampolines on certain scenarios
From: Andrea Corallo <[email-masked]>
To: Eli Zaretskii <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Thu, 09 Mar 2023 11:36:33 +0000
List-Id: <debbugs-submit.debbugs.gnu.org>

Eli Zaretskii <[email-masked]> writes:

>> Cc: [email-masked], [email-masked]
>> Date: Sun, 05 Mar 2023 12:44:29 +0200
>> From: Eli Zaretskii <[email-masked]>
>> 
>> > From: Andrea Corallo <[email-masked]>
>> > Cc: [email-masked],  [email-masked]
>> > Date: Sun, 05 Mar 2023 10:08:12 +0000
>> > 
>> > Okay I pushed 9c18af0cfaf with a slightly reworded warning to address
>> > this, feel free to improve it if you fee.
>> 
>> Thanks.  I've changed the wording slightly.
>
> Is there anything else to do for this issue, or should we now close
> it?

Not that I'm aware.

I'm closing it now, happy to reopen if something more pops-up.

Best Regards

  Andrea

Subject: Native compilation fails to generate trampolines on certain scenarios
From: Sergio Durigan Junior <[email-masked]>
To: [email-masked]
Date: Tue, 28 Feb 2023 19:13:58 -0500
List-Id: <debbugs-submit.debbugs.gnu.org>

Hello,

While investigating a few bugs affecting Debian's and Ubuntu's Emacs
packages (for example,
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028725), I stumbled
upon a problem that's affecting native compilation on Emacs 28.1+,
currently reproducible with git master as well.

I haven't been able to fully understand why the problem is happening,
but when there are two primitive functions (that would become
trampolines) being used sequentially, Emacs doesn't generate the
corresponding .eln file for the second function.

I spent some time investigating the problem and came up with a "minimal"
reproducer:

--8<---------------cut here---------------start------------->8---
(require 'cl-lib)

(defmacro foo--flet (funcs &rest body)
  "Like `cl-flet' but with dynamic function scope."
  (declare (indent 1))                                                                                                                                                                    
  (let* ((names (mapcar #'car funcs))
         (lambdas (mapcar #'cdr funcs))
         (gensyms (cl-loop for name in names
                           collect (make-symbol (symbol-name name)))))
    `(let ,(cl-loop for name in names
                    for gensym in gensyms
                    collect `(,gensym (symbol-function ',name)))
       (unwind-protect
           (progn
             ,@(cl-loop for name in names
                        for lambda in lambdas
                        for body = `(lambda ,@lambda)
                        collect `(setf (symbol-function ',name) ,body))
             ,@body)
         ,@(cl-loop for name in names
                    for gensym in gensyms
                    collect `(setf (symbol-function ',name) ,gensym))))))

(defun bar (file)
  (and (file-exists-p file) (file-readable-p file)))

(defun test ()
  (foo--flet ((file-exists-p (file) t)
              (file-readable-p (file) nil))
    (message "%s" (bar "/home/sergio/.lesshst"))))
--8<---------------cut here---------------end--------------->8---

When I run it using the following Emacs:

--8<---------------cut here---------------start------------->8---
GNU Emacs 30.0.50
Development version 68cc286c0495 on master branch; build date 2023-02-28.
--8<---------------cut here---------------end--------------->8---

here is the output I see:

--8<---------------cut here---------------start------------->8---
$ emacs -batch -Q -l t.el -f test -L .
Error: native-lisp-load-failed ("file does not exists" "/home/sergio/.emacs.d/eln-cache/30.0.50-23de7b18/subr--trampoline-66696c652d7265616461626c652d70_file_readable_p_0.eln")
  debug-early-backtrace()
  debug-early(error (native-lisp-load-failed "file does not exists" "/home/sergio/.emacs.d/eln-cache/30.0.50-23de7b18/subr--trampoline-66696c652d7265616461626c652d70_file_readable_p_0.eln"))
  native-elisp-load("/home/sergio/.emacs.d/eln-cache/30.0.50-23de7b18/subr--trampoline-66696c652d7265616461626c652d70_file_readable_p_0.eln")
  comp-trampoline-search(file-readable-p)
  comp-subr-trampoline-install(file-readable-p)
  fset(file-readable-p (lambda (file) nil))
  (progn (fset 'file-exists-p #'(lambda (file) t)) (fset 'file-readable-p #'(lambda (file) nil)) (message "%s" (bar "/home/sergio/.lesshst")))
  (unwind-protect (progn (fset 'file-exists-p #'(lambda (file) t)) (fset 'file-readable-p #'(lambda (file) nil)) (message "%s" (bar "/home/sergio/.lesshst"))) (fset 'file-exists-p file-exist
s-p) (fset 'file-readable-p file-readable-p))
  (let ((file-exists-p (symbol-function 'file-exists-p)) (file-readable-p (symbol-function 'file-readable-p))) (unwind-protect (progn (fset 'file-exists-p #'(lambda (file) t)) (fset 'file-re
adable-p #'(lambda (file) nil)) (message "%s" (bar "/home/sergio/.lesshst"))) (fset 'file-exists-p file-exists-p) (fset 'file-readable-p file-readable-p)))
  test()
  command-line-1(("-l" "t.el" "-f" "test" "-L" "."))
  command-line()
  normal-top-level()
Native elisp load failed: "file does not exists", "/home/sergio/.emacs.d/eln-cache/30.0.50-23de7b18/subr--trampoline-66696c652d7265616461626c652d70_file_readable_p_0.eln"
--8<---------------cut here---------------end--------------->8---

Do note that this is already affecting a few packages, like buttercup
(see https://github.com/jorgenschaefer/emacs-buttercup/issues/230) and
emacs-web-server, for example.

Please let me know if you need more information regarding the problem.

Thank you,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/