bug#56744: 29.0.50; "Autoloaded" information lost in native compilation?

bug#56744: 29.0.50; "Autoloaded" information lost in native compilation?

[Eli Zaretskii]

To reproduce:

  emacs -Q
  C-h f rmail-movemail-variant-p RET

(or any other autoloaded function).  Assuming that the function's .el
file was already natively compiled to produce a .eln file, the
"autoloaded" part will not be shown in the *Help* buffer, Emacs will
only say that this is a native-compiled function.

Is it possible to resurrect this information from natively-compiled
Lisp code?  If not, what would have to be done to include this
information (and how does auto-loading works if the information is
lost in the first place)?

In GNU Emacs 29.0.50 (build 1551, i686-pc-mingw32)
 of 2022-07-24 built on HOME-C4E4A596F7
Repository revision: 9ed5c39aad09571314097be91cb28e7504614421
Repository branch: master
Windowing system distributor 'Microsoft Corp.', version 5.1.2600
System Description: Microsoft Windows XP Service Pack 3 (v5.1.0.2600)

Configured using:
 'configure -C --prefix=/d/usr --with-wide-int
 --enable-checking=yes,glyphs 'CFLAGS=-O0 -gdwarf-4 -g3''

Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NOTIFY
W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS WEBP XPM ZLIB

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1255

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  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
  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 message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date subr-x mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils rmc iso-transl tooltip eldoc paren electric
uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel dos-w32
ls-lisp disp-table term/w32-win w32-win w32-vars 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 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 w32notify w32 lcms2 multi-tty
make-network-process emacs)

Memory information:
((conses 16 42025 11925)
 (symbols 48 6230 1)
 (strings 16 16688 2023)
 (string-bytes 1 454620)
 (vectors 16 9212)
 (vector-slots 8 143809 14713)
 (floats 8 23 45)
 (intervals 40 268 2)
 (buffers 888 10))

bug#56744: 29.0.50; "Autoloaded" information lost in native compilation?

[Eli Zaretskii]

Andrea,

Could you please take a look at this year-old bug report?

> Date: Sun, 24 Jul 2022 19:10:03 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> 
> To reproduce:
> 
>   emacs -Q
>   C-h f rmail-movemail-variant-p RET
> 
> (or any other autoloaded function).  Assuming that the function's .el
> file was already natively compiled to produce a .eln file, the
> "autoloaded" part will not be shown in the *Help* buffer, Emacs will
> only say that this is a native-compiled function.
> 
> Is it possible to resurrect this information from natively-compiled
> Lisp code?  If not, what would have to be done to include this
> information (and how does auto-loading works if the information is
> lost in the first place)?
> 
> In GNU Emacs 29.0.50 (build 1551, i686-pc-mingw32)
>  of 2022-07-24 built on HOME-C4E4A596F7
> Repository revision: 9ed5c39aad09571314097be91cb28e7504614421
> Repository branch: master
> Windowing system distributor 'Microsoft Corp.', version 5.1.2600
> System Description: Microsoft Windows XP Service Pack 3 (v5.1.0.2600)
> 
> Configured using:
>  'configure -C --prefix=/d/usr --with-wide-int
>  --enable-checking=yes,glyphs 'CFLAGS=-O0 -gdwarf-4 -g3''
> 
> Configured features:
> ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NOTIFY
> W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF
> TOOLKIT_SCROLL_BARS WEBP XPM ZLIB
> 
> Important settings:
>   value of $LANG: ENU
>   locale-coding-system: cp1255
> 
> Major mode: Lisp Interaction
> 
> Minor modes in effect:
>   tooltip-mode: t
>   global-eldoc-mode: t
>   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
>   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 message mailcap yank-media puny dired
> dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
> epg-config gnus-util text-property-search time-date subr-x mm-decode
> mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
> cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util
> mail-prsvr mail-utils rmc iso-transl tooltip eldoc paren electric
> uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel dos-w32
> ls-lisp disp-table term/w32-win w32-win w32-vars 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 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 w32notify w32 lcms2 multi-tty
> make-network-process emacs)
> 
> Memory information:
> ((conses 16 42025 11925)
>  (symbols 48 6230 1)
>  (strings 16 16688 2023)
>  (string-bytes 1 454620)
>  (vectors 16 9212)
>  (vector-slots 8 143809 14713)
>  (floats 8 23 45)
>  (intervals 40 268 2)
>  (buffers 888 10))
> 
> 
> 
> 

bug#56744: 29.0.50; "Autoloaded" information lost in native compilation?

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

> Andrea,
>
> Could you please take a look at this year-old bug report?
>

Yep will do, sorry it completely slipped under my radar.

  Andrea

bug#56744: 29.0.50; "Autoloaded" information lost in native compilation?

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

> Andrea,
>
> Could you please take a look at this year-old bug report?
>
>> Date: Sun, 24 Jul 2022 19:10:03 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> 
>> 
>> To reproduce:
>> 
>>   emacs -Q
>>   C-h f rmail-movemail-variant-p RET
>> 
>> (or any other autoloaded function).  Assuming that the function's .el
>> file was already natively compiled to produce a .eln file, the
>> "autoloaded" part will not be shown in the *Help* buffer, Emacs will
>> only say that this is a native-compiled function.

On current master before requiring rmail on C-h f
rmail-movemail-variant-p RET I get:

===
rmail-movemail-variant-p is an autoloaded byte-compiled Lisp function
in ‘rmail.el’.

(rmail-movemail-variant-p &rest VARIANTS)
===

After requiring rmail (and having it native compiled) I get:

===
rmail-movemail-variant-p is an autoloaded native-compiled Lisp
function in ‘rmail.el’.

(rmail-movemail-variant-p &rest VARIANTS)

Inferred type: (function (&rest t) boolean)
===

So I guess the issue has already been fixed (or I'm not reproducing it
correctly)?

Best Regards

  Andrea

bug#56744: 29.0.50; "Autoloaded" information lost in native compilation?

[Eli Zaretskii]

> From: Andrea Corallo <acorallo@gnu.org>
> Cc: 56744@debbugs.gnu.org
> Date: Sun, 20 Aug 2023 16:45:51 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Andrea,
> >
> > Could you please take a look at this year-old bug report?
> >
> >> Date: Sun, 24 Jul 2022 19:10:03 +0300
> >> From: Eli Zaretskii <eliz@gnu.org>
> >> 
> >> 
> >> To reproduce:
> >> 
> >>   emacs -Q
> >>   C-h f rmail-movemail-variant-p RET
> >> 
> >> (or any other autoloaded function).  Assuming that the function's .el
> >> file was already natively compiled to produce a .eln file, the
> >> "autoloaded" part will not be shown in the *Help* buffer, Emacs will
> >> only say that this is a native-compiled function.
> 
> On current master before requiring rmail on C-h f
> rmail-movemail-variant-p RET I get:
> 
> ===
> rmail-movemail-variant-p is an autoloaded byte-compiled Lisp function
> in ‘rmail.el’.
> 
> (rmail-movemail-variant-p &rest VARIANTS)
> ===
> 
> After requiring rmail (and having it native compiled) I get:
> 
> ===
> rmail-movemail-variant-p is an autoloaded native-compiled Lisp
> function in ‘rmail.el’.
> 
> (rmail-movemail-variant-p &rest VARIANTS)
> 
> Inferred type: (function (&rest t) boolean)
> ===
> 
> So I guess the issue has already been fixed (or I'm not reproducing it
> correctly)?

No, you are reproducing correctly.  It's also seems to be fixed on the
emacs-29 branch, so I will close the bug.  Sorry for not
double-checking before I pinged you.

bug#56744: 29.0.50; "Autoloaded" information lost in native compilation?

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <acorallo@gnu.org>
>> Cc: 56744@debbugs.gnu.org
>> Date: Sun, 20 Aug 2023 16:45:51 -0400
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > Andrea,
>> >
>> > Could you please take a look at this year-old bug report?
>> >
>> >> Date: Sun, 24 Jul 2022 19:10:03 +0300
>> >> From: Eli Zaretskii <eliz@gnu.org>
>> >> 
>> >> 
>> >> To reproduce:
>> >> 
>> >>   emacs -Q
>> >>   C-h f rmail-movemail-variant-p RET
>> >> 
>> >> (or any other autoloaded function).  Assuming that the function's .el
>> >> file was already natively compiled to produce a .eln file, the
>> >> "autoloaded" part will not be shown in the *Help* buffer, Emacs will
>> >> only say that this is a native-compiled function.
>> 
>> On current master before requiring rmail on C-h f
>> rmail-movemail-variant-p RET I get:
>> 
>> ===
>> rmail-movemail-variant-p is an autoloaded byte-compiled Lisp function
>> in ‘rmail.el’.
>> 
>> (rmail-movemail-variant-p &rest VARIANTS)
>> ===
>> 
>> After requiring rmail (and having it native compiled) I get:
>> 
>> ===
>> rmail-movemail-variant-p is an autoloaded native-compiled Lisp
>> function in ‘rmail.el’.
>> 
>> (rmail-movemail-variant-p &rest VARIANTS)
>> 
>> Inferred type: (function (&rest t) boolean)
>> ===
>> 
>> So I guess the issue has already been fixed (or I'm not reproducing it
>> correctly)?
>
> No, you are reproducing correctly.  It's also seems to be fixed on the
> emacs-29 branch, so I will close the bug.  Sorry for not
> double-checking before I pinged you.

No problem, a bug that's already solved is the best outcome we could
desire :)

Best Regards

  Andrea