bug#74368: 31.0.50; Different warnings between native-compile and native-compile-async

bug#74368: 31.0.50; Different warnings between native-compile and native-compile-async

[Sean Devlin]

Hi folks,

I'm not sure if this is a bug, but I noticed a difference in behavior
when compiling with native-compile and native-compile-async.

Recipe:

1. mkdir /tmp/emacs-test
2. printf ";; -*- lexical-binding: t; -*-\n\n(vertico-mode)\n" > /tmp/emacs-test/test.el
2. HOME=/tmp/emacs-test emacs
3. M-x package-install RET vertico RET
4. M-: (native-compile "/tmp/emacs-test/test.el") RET
5. M-! touch /tmp/emacs-test/test.el RET
6. M-: (native-compile-async "/tmp/emacs-test/test.el") RET

There is no warning when compiling synchronously, but there is a warning
during asynchronous compilation:

test.el:3:2: Warning: the function ‘vertico-mode’ is not known to be
defined.

I guess maybe the asynchronous compiler has not processed the autoloads
from installed packages, whereas the synchronous compiler has.

Is this difference in behavior expected? Or is one of the compilers
behaving incorrectly?

Thanks!


In GNU Emacs 31.0.50 (build 1, aarch64-apple-darwin24.2.0, NS
appkit-2575.30 Version 15.2 (Build 24C5079e)) of 2024-11-15 built on
beatrix.local
Repository revision: 1f8fbae8df764e9d24f1b824de7369d82e36abae
Repository branch: master
Windowing system distributor 'Apple', version 10.3.2575
System Description:  macOS 15.2

Configured using:
'configure --with-ns --with-modules --with-native-compilation
--with-libgmp --with-tree-sitter --with-sqlite3 --without-imagemagick
--without-dbus CPPFLAGS=-I/opt/homebrew/include
LDFLAGS=-L/opt/homebrew/lib
PKG_CONFIG_PATH=/opt/homebrew/lib/pkgconfig'

Configured features:
ACL GMP GNUTLS LIBXML2 MODULES NATIVE_COMP NOTIFY KQUEUE NS PDUMPER
SQLITE3 THREADS TOOLKIT_SCROLL_BARS TREE_SITTER ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Dired by name

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-regexp-mode: t
  buffer-read-only: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug pcmpl-unix comp comp-cstr cl-extra
help-mode vertico-flat warnings vertico pcase compat info
vertico-autoloads easy-mmode loaddefs-gen lisp-mnt radix-tree tar-mode
arc-mode archive-mode cus-edit pp cus-start cus-load wid-edit mm-archive
message sendmail yank-media rfc822 mml mml-sec epa derived epg rfc6068
gnus-util mailabbrev gmm-utils mailheader mm-decode mm-bodies mm-encode
mail-utils gnutls network-stream url-cache url-http url-auth mail-parse
rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr url-gw nsm puny
epg-config finder-inf package browse-url url url-proxy url-privacy
url-expand url-methods url-history url-cookie generate-lisp-file
url-domsuf url-util mailcap url-handlers url-parse auth-source cl-seq
eieio eieio-core cl-macs icons password-cache json map byte-opt gv
url-vars shell pcomplete time-date compile text-property-search comint
subr-x ansi-osc ansi-color ring comp-run bytecomp byte-compile
comp-common rx dired-aux cl-loaddefs cl-lib dired dired-loaddefs rmc
iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook
vc-hooks lisp-float-type elisp-mode mwheel term/ns-win ns-win
ucs-normalize mule-util term/common-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads kqueue cocoa ns multi-tty
make-network-process native-compile emacs)

Memory information:
((conses 16 236347 29747) (symbols 48 13790 0) (strings 32 64721 4130)
(string-bytes 1 1850967) (vectors 16 38194)
(vector-slots 8 401520 17463) (floats 8 88 82) (intervals 56 692 0)
(buffers 992 20))

bug#74368: 31.0.50; Different warnings between native-compile and native-compile-async

[Eli Zaretskii]

tags 74368 notabug
thanks

> From: Sean Devlin <spd@toadstyle.org>
> Date: Fri, 15 Nov 2024 12:04:42 -0500
> 
> I'm not sure if this is a bug, but I noticed a difference in behavior
> when compiling with native-compile and native-compile-async.
> 
> Recipe:
> 
> 1. mkdir /tmp/emacs-test
> 2. printf ";; -*- lexical-binding: t; -*-\n\n(vertico-mode)\n" > /tmp/emacs-test/test.el
> 2. HOME=/tmp/emacs-test emacs
> 3. M-x package-install RET vertico RET
> 4. M-: (native-compile "/tmp/emacs-test/test.el") RET
> 5. M-! touch /tmp/emacs-test/test.el RET
> 6. M-: (native-compile-async "/tmp/emacs-test/test.el") RET
> 
> There is no warning when compiling synchronously, but there is a warning
> during asynchronous compilation:
> 
> test.el:3:2: Warning: the function ‘vertico-mode’ is not known to be
> defined.
> 
> I guess maybe the asynchronous compiler has not processed the autoloads
> from installed packages, whereas the synchronous compiler has.
> 
> Is this difference in behavior expected? Or is one of the compilers
> behaving incorrectly?

This is indeed expected, and not a bug.  The asynchronous JIT
native-compilation runs in a separate batch Emacs session, which
doesn't load any of your init files.  To avoid these warnings, you
should make sure all of the *.el files that are natively compiled have
all the requisite 'require's and/or 'eval-when-compile' to load all
the dependency libraries when compiling the file as a stand-alone Lisp
package.

bug#74368: 31.0.50; Different warnings between native-compile and native-compile-async

[Sean Devlin]

> On Nov 16, 2024, at 2:38 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> tags 74368 notabug
> thanks
> 
>> From: Sean Devlin <spd@toadstyle.org>
>> Date: Fri, 15 Nov 2024 12:04:42 -0500
>> 
>> I'm not sure if this is a bug, but I noticed a difference in behavior
>> when compiling with native-compile and native-compile-async.
>> 
>> Recipe:
>> 
>> 1. mkdir /tmp/emacs-test
>> 2. printf ";; -*- lexical-binding: t; -*-\n\n(vertico-mode)\n" > /tmp/emacs-test/test.el
>> 2. HOME=/tmp/emacs-test emacs
>> 3. M-x package-install RET vertico RET
>> 4. M-: (native-compile "/tmp/emacs-test/test.el") RET
>> 5. M-! touch /tmp/emacs-test/test.el RET
>> 6. M-: (native-compile-async "/tmp/emacs-test/test.el") RET
>> 
>> There is no warning when compiling synchronously, but there is a warning
>> during asynchronous compilation:
>> 
>> test.el:3:2: Warning: the function ‘vertico-mode’ is not known to be
>> defined.
>> 
>> I guess maybe the asynchronous compiler has not processed the autoloads
>> from installed packages, whereas the synchronous compiler has.
>> 
>> Is this difference in behavior expected? Or is one of the compilers
>> behaving incorrectly?
> 
> This is indeed expected, and not a bug.  The asynchronous JIT
> native-compilation runs in a separate batch Emacs session, which
> doesn't load any of your init files.  To avoid these warnings, you
> should make sure all of the *.el files that are natively compiled have
> all the requisite 'require's and/or 'eval-when-compile' to load all
> the dependency libraries when compiling the file as a stand-alone Lisp
> package.

I see, that makes sense. Thanks for the explanation.

bug#74368: 31.0.50; Different warnings between native-compile and native-compile-async

[Andrea Corallo]

Sean Devlin <spd@toadstyle.org> writes:

> Hi folks,
>
> I'm not sure if this is a bug, but I noticed a difference in behavior
> when compiling with native-compile and native-compile-async.
>
> Recipe:
>
> 1. mkdir /tmp/emacs-test
> 2. printf ";; -*- lexical-binding: t; -*-\n\n(vertico-mode)\n" > /tmp/emacs-test/test.el
> 2. HOME=/tmp/emacs-test emacs
> 3. M-x package-install RET vertico RET
> 4. M-: (native-compile "/tmp/emacs-test/test.el") RET
> 5. M-! touch /tmp/emacs-test/test.el RET
> 6. M-: (native-compile-async "/tmp/emacs-test/test.el") RET
>
> There is no warning when compiling synchronously, but there is a warning
> during asynchronous compilation:
>
> test.el:3:2: Warning: the function ‘vertico-mode’ is not known to be
> defined.
>
> I guess maybe the asynchronous compiler has not processed the autoloads
> from installed packages, whereas the synchronous compiler has.
>
> Is this difference in behavior expected? Or is one of the compilers
> behaving incorrectly?
>
> Thanks!

Hi Devlin,

yes this difference is expected, 'native-compile' runs the compilation
in the loaded Emacs so that all the definitions of loaded packages are
known to the compiler.  'native-compile-async' runs in a new fresh Emacs
so all requires need to be there in the compilation unit in order to let
the compiler be able to load the definitions.

We have also some doc in (info "(elisp) Native-Compilation Variables")
which goes like this:

    A common cause for asynchronous native-compilation to produce
     warnings is compiling a file that is missing some ‘require’ of a
     necessary feature.  The feature may be loaded into the main emacs,
     but because native compilation always starts from a subprocess with
     a pristine environment, that may not be true for the subprocess.

Regards

  Andrea

bug#74368: 31.0.50; Different warnings between native-compile and native-compile-async

[Sean Devlin]

[-- Attachment #1: Type: text/plain, Size: 1031 bytes --]


> On Nov 16, 2024, at 4:26 PM, Andrea Corallo <acorallo@gnu.org> wrote:
>> 
> 
> Hi Devlin,
> 
> yes this difference is expected, 'native-compile' runs the compilation
> in the loaded Emacs so that all the definitions of loaded packages are
> known to the compiler.  'native-compile-async' runs in a new fresh Emacs
> so all requires need to be there in the compilation unit in order to let
> the compiler be able to load the definitions.
> 
> We have also some doc in (info "(elisp) Native-Compilation Variables")
> which goes like this:
> 
>    A common cause for asynchronous native-compilation to produce
>     warnings is compiling a file that is missing some ‘require’ of a
>     necessary feature.  The feature may be loaded into the main emacs,
>     but because native compilation always starts from a subprocess with
>     a pristine environment, that may not be true for the subprocess.
> 
> Regards
> 
>  Andrea

I see. Thanks for the explanation and the documentation reference!

Sean

[-- Attachment #2: Type: text/html, Size: 13946 bytes --]

bug#74368: 31.0.50; Different warnings between native-compile and native-compile-async

[Eli Zaretskii]

> Cc: 74368@debbugs.gnu.org
> From: Sean Devlin <spd@toadstyle.org>
> Date: Fri, 22 Nov 2024 11:32:39 -0500
> 
>  On Nov 16, 2024, at 4:26 PM, Andrea Corallo <acorallo@gnu.org> wrote:
> 
>  Hi Devlin,
> 
>  yes this difference is expected, 'native-compile' runs the compilation
>  in the loaded Emacs so that all the definitions of loaded packages are
>  known to the compiler.  'native-compile-async' runs in a new fresh Emacs
>  so all requires need to be there in the compilation unit in order to let
>  the compiler be able to load the definitions.
> 
>  We have also some doc in (info "(elisp) Native-Compilation Variables")
>  which goes like this:
> 
>     A common cause for asynchronous native-compilation to produce
>      warnings is compiling a file that is missing some ‘require’ of a
>      necessary feature.  The feature may be loaded into the main emacs,
>      but because native compilation always starts from a subprocess with
>      a pristine environment, that may not be true for the subprocess.
> 
>  Regards
> 
>   Andrea
> 
> I see. Thanks for the explanation and the documentation reference!

I'm therefore closing this bug.