--- Begin Message ---
|
Subject: |
28.0.50; [feature/native-comp] autoload behavior different in the presence of errors |
|
Date: |
Wed, 13 Jan 2021 23:52:29 -0300 |
The example is a bit convoluted, but it is a reduced example from
another error I saw in the wild. It's not a big problem, but since this
might be a bug I thought a report could be useful. I wish I could reduce
it further, but hopefully this is enough.
Suppose I have three files as below (I've appended an x to the original package
names to avoid conflict):
* File 1: transientx.el
;;; transientx.el --- x -*- lexical-binding: t; -*-
;; Package-Requires: ((emacs "25.1"))
;; Package-Version: 0
(require 'cl-lib)
(require 'eieio)
(defclass transient-suffix () ())
(cl-defmethod transient--init-suffix-key ((obj transient-suffix)))
;; (provide 'transientx) commented on purpose to cause an error when requiring
;;; transientx.el ends here
* File 2: git-commitx.el
;;; git-commitx.el --- x -*- lexical-binding: t; -*-
;; Package-Requires: ((emacs "25.1") (transientx "20200601"))
;; Package-Version: 20210102.1242
(require 'transientx)
;;;###autoload
(define-minor-mode global-git-commit-mode
"desc"
:global t
:initialize (lambda (symbol exp)
(add-hook 'find-file-hook 'git-commit-setup-check-buffer)))
;;;###autoload
(defun git-commit-setup-check-buffer ())
(provide 'git-commitx)
;;; git-commitx.el ends here
* File 3: elpa2nix.el
(require 'package)
(package-initialize)
(defun elpa2nix-install-package ()
(pcase command-line-args-left
(`(,archive)
(with-temp-buffer
(insert-file-contents archive)
(package-unpack (package-buffer-info))))))
Then running the following two commands in order produces the stack
trace below on the native-comp branch:
$ emacs --batch -Q -l ~/elpa2nix.el -f elpa2nix-install-package transientx.el
$ emacs --batch -Q -l ~/elpa2nix.el -f elpa2nix-install-package git-commitx.el
git-commitx.el:6:1: Error: Loading file
/home/collares/.emacs.d/elpa/transientx-0/transientx.elc failed to provide
feature ‘transientx’
Done (Total of 0 files compiled, 1 failed, 2 skipped)
Debugger entered--Lisp error: (error "transient--init-suffix-key is already
defined as s...")
error("%s is already defined as something else than a gen..."
transient--init-suffix-key)
cl-generic-ensure-function(transient--init-suffix-key)
cl-generic-define-method(transient--init-suffix-key nil ((obj
transient-suffix)) nil #f(compiled-function (obj) #<bytecode
0x1bd084804d24a6d3>))
require(transientx)
load-with-code-conversion("/home/collares/.emacs.d/elpa/git-commitx-20210102...."
"/home/collares/.emacs.d/elpa/git-commitx-20210102...." nil t)
git-commit-setup-check-buffer()
run-hooks(find-file-hook)
after-find-file(nil t)
find-file-noselect-1(#<buffer git-commitx.el> "~/git-commitx.el" nil nil
"~/git-commitx.el" (7340496 65025))
find-file-noselect("/home/collares/git-commitx.el")
command-line-1(("-l" "/home/collares/elpa2nix.el" "-f"
"elpa2nix-install-package" "/home/collares/git-commitx.el"))
command-line()
normal-top-level()
The transient--init-suffix-key error does not appear on trunk (the
"failed to provide feature" error appears as expected). Reverting commit
7d7bfbf0346114b116e14a4338ea235d12674f13 makes the change of behaviour
disappear, but I suspect it's not the true cause of the difference.
Things that might be relevant: package-native-compile is nil, but when
package-unpack is called on git-commitx.el the (require 'transientx)
causes native compilation to happen. The above stacktrace seems to come
from the "(package--load-files-for-activation new-desc :reload)" call in
package.el's package-unpack.
Let me know if I can provide more information.
Best,
Mauricio
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#45854: 28.0.50; [feature/native-comp] autoload behavior different in the presence of errors |
|
Date: |
Mon, 01 Feb 2021 14:00:22 +0000 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
Mauricio Collares <mauricio@collares.org> writes:
> Andrea Corallo <akrl@sdf.org> writes:
>> Here I'm,
>>
>> I can see the same exact behavior on current master as on a native-comp
>> build so I believe this is not a misbehavior. I did the two experiments
>> starting from a clean .emacs.d to avoid state issues.
>
> Hi Andrea,
>
> Yes, I now agree. Starting with "HOME=~/tmp", a git bisect says that
> master changed behaviour at 9973019764250ac1f4d77a6b426cdd9c241151c5
> too. So this is not a problem with native-compilation and the bug I
> reported is invalid. Truly sorry for the confusion. I took care to
> delete ~/.emacs.d/elpa and the eln-cache directories between tests but
> there must be additional state that interfered with my initial testing.
No problem.
> I have one last question to ask you. The original investigation started
> because failure to compile a trampoline (due to an empty
> comp-eln-load-path, say) previously didn't interrupt package
> installation, and after changes on master it now does. So the remaining
> question is: Is triggering trampoline compilation expected even when
> running emacs non-interactively in a context (such as in the above
> testcase with an uncommented (provide 'transientx)) that otherwise does
> not generate .eln files? If this is the intended behaviour, would it
> make sense to make trampoline compilation failure emit a warning instead
> of an error in those contexts?
A trampoline is requested each time a primitive function gets redefined
or advised, if this is not available it gets synthesized. Each eln
might make use of this, not only the one being compiled or installed
therfore is mandatory to have in interactive sessions as well as in non
interactive. If we cannot satisfy this condition for any reason I think
is correct to have an error as Emacs might misbehave.
I'm not sure about what's going on in this specific case but if the
trampoline is requested means a primitive is being redefined or advised.
Okay I'm closing this bug.
Thanks
Andrea
--- End Message ---