GNU bug report logs - #59358
29.0.50; failing to load .eln for init file sets user-init-file to warnings.el

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 59358 in the body.
You can then email your comments to 59358 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Bug-Gnu-Emacs <bug-gnu-emacs <at> gnu.org>
Subject: 29.0.50;
 failing to load .eln for init file sets user-init-file to warnings.el
Date: Fri, 18 Nov 2022 14:17:36 +0100

[Message part 1 (text/plain, inline)]

If you use ~/.emacs instead of ~.emacs.d/init.el, and happen to compile
.emacs, Emacs loads .emacs.elc (as it has always done), but the native
compiler does *not* know how to compile it (because it does not know how to
locate its source), so it gives a warning:

022-11-18 02:54:01+0100 Warning (comp): Cannot look up eln file as no
source file was found for d:/Home/.emacs.elc

and then it assigns the user-init-file to the native-compiled warnings.el,

"d:/Home/.emacs.d/native/29.0.50-a4a10996/warnings-28e75f4d-02da775e.eln"

which now, with the fix for bug#59334, ends up pointing to warnings.el:

ELISP> user-init-file
"d:/Devel/emacs/repo/trunk/lisp/emacs-lisp/warnings.el"

[Message part 2 (text/html, inline)]

Message #8 received at 59358 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 59358 <at> debbugs.gnu.org
Subject: Re: bug#59358: 29.0.50;
 failing to load .eln for init file sets user-init-file to warnings.el
Date: Fri, 18 Nov 2022 16:24:21 +0200

> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Fri, 18 Nov 2022 14:17:36 +0100
> 
> If you use ~/.emacs instead of ~.emacs.d/init.el, and happen to compile .emacs, Emacs loads .emacs.elc
> (as it has always done), but the native compiler does *not* know how to compile it (because it does not know
> how to locate its source), so it gives a warning:
> 
> 022-11-18 02:54:01+0100 Warning (comp): Cannot look up eln file as no source file was found for
> d:/Home/.emacs.elc

I think the solution to that is to special-case ".emacs", in
maybe_swap_for_eln, as a file name that doesn't have to have the .el
extension for this purpose.

> and then it assigns the user-init-file to the native-compiled warnings.el,
> 
> "d:/Home/.emacs.d/native/29.0.50-a4a10996/warnings-28e75f4d-02da775e.eln"
> 
> which now, with the fix for bug#59334, ends up pointing to warnings.el:
> 
> ELISP> user-init-file
> "d:/Devel/emacs/repo/trunk/lisp/emacs-lisp/warnings.el"

That is a separate bug, IMO.  Is this because in Fload we set 'found'
to the file name of warnings.el/.eln in this case?  If so, we should
prevent this nonsense.

Message #11 received at 59358 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 59358 <at> debbugs.gnu.org
Subject: Re: bug#59358: 29.0.50; failing to load .eln for init file sets
 user-init-file to warnings.el
Date: Sat, 19 Nov 2022 10:13:58 +0100

[Message part 1 (text/plain, inline)]

On Fri, Nov 18, 2022 at 3:24 PM Eli Zaretskii <eliz <at> gnu.org> wrote:


> That is a separate bug, IMO.  Is this because in Fload we set 'found'
> to the file name of warnings.el/.eln in this case?  If so, we should
> prevent this nonsense.
>

The bug is the consequence of maybe_swap_for_eln calling `display-warning',
which initiates a recursive Fload while user-init-file is still t, so Fload
"records" the current file name.

The easiest fix in my view is to use delayed warnings and avoid the
recursive Fload.

diff --git i/src/lread.c w/src/lread.c
index c28324dc35..2a57f72194 100644
--- i/src/lread.c
+++ w/src/lread.c
@@ -1742,10 +1742,13 @@ maybe_swap_for_eln (bool no_native, Lisp_Object
*filename, int *fd,
                                               Qnil, Qnil)))
                return;
-             call2 (intern_c_string ("display-warning"),
-                    Qcomp,
-                    CALLN (Fformat,
-                           build_string ("Cannot look up eln file as "
-                                         "no source file was found for
%s"),
-                           *filename));
+             Vdelayed_warnings_list
+               = Fcons (list2
+                        (Qcomp,
+                         CALLN (Fformat,
+                                build_string ("Cannot look up eln "
+                                              "file as no source file "
+                                              "was found for %s"),
+                                *filename)),
+                        Vdelayed_warnings_list);
              return;
            }

[Message part 2 (text/html, inline)]

Message #14 received at 59358 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>, Andrea Corallo <akrl <at> sdf.org>
Cc: 59358 <at> debbugs.gnu.org
Subject: Re: bug#59358: 29.0.50; failing to load .eln for init file sets
 user-init-file to warnings.el
Date: Sat, 19 Nov 2022 12:21:06 +0200

> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Sat, 19 Nov 2022 10:13:58 +0100
> Cc: 59358 <at> debbugs.gnu.org
> 
> On Fri, Nov 18, 2022 at 3:24 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
>  
>  That is a separate bug, IMO.  Is this because in Fload we set 'found'
>  to the file name of warnings.el/.eln in this case?  If so, we should
>  prevent this nonsense.
> 
> The bug is the consequence of maybe_swap_for_eln calling `display-warning', which initiates a recursive
> Fload while user-init-file is still t, so Fload "records" the current file name.
> 
> The easiest fix in my view is to use delayed warnings and avoid the recursive Fload.

Fine by me.

Andrea, do you agree?

Message #17 received at 59358 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <akrl <at> sdf.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Juanma Barranquero <lekktu <at> gmail.com>, 59358 <at> debbugs.gnu.org
Subject: Re: bug#59358: 29.0.50; failing to load .eln for init file sets
 user-init-file to warnings.el
Date: Sun, 20 Nov 2022 18:59:54 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Juanma Barranquero <lekktu <at> gmail.com>
>> Date: Sat, 19 Nov 2022 10:13:58 +0100
>> Cc: 59358 <at> debbugs.gnu.org
>> 
>> On Fri, Nov 18, 2022 at 3:24 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
>>  
>>  That is a separate bug, IMO.  Is this because in Fload we set 'found'
>>  to the file name of warnings.el/.eln in this case?  If so, we should
>>  prevent this nonsense.
>> 
>> The bug is the consequence of maybe_swap_for_eln calling
>> `display-warning', which initiates a recursive
>> Fload while user-init-file is still t, so Fload "records" the current file name.
>> 
>> The easiest fix in my view is to use delayed warnings and avoid the
>> recursive Fload.
>
> Fine by me.
>
> Andrea, do you agree?

Agreed.

Thanks

  Andrea

Message #22 received at 59358-done <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: 59358-done <at> debbugs.gnu.org
Date: Sun, 20 Nov 2022 23:14:58 +0100

[Message part 1 (text/plain, inline)]

The more serious bug is fixed with this commit:

8ec8decd9f  of  2022-11-20
Avoid native compiler setting user-init-file to warnings.el (bug#59358)

I'll open a new bug report with the first issue (the native compiler being
unable to compile .emacs).

[Message part 2 (text/html, inline)]

Previous Next

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