GNU bug report logs - #78995
[PATCH] ;;;autoload-expand for special macros

Previous Next

Full log

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

From: "J.D. Smith" <jdtsmith <at> gmail.com>
To: 78995 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#78995: [PATCH] ;;;autoload-expand for special macros
Date: Tue, 15 Jul 2025 23:35:54 -0400

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

Here is an update on progress.  The attached is working reasonably well,
reproducing lisp/loaddefs.el with a few changes (see attached).  I went
with (declare ((autoload . macro-expand))) on the notion that there
might be other autoload-related declarations in the future, but open to
suggestion.

I've now fully eliminated list 1 in favor of declare statements, but
also had to handle the case of _aliased_ macros, e.g. all the
[easy-mmode]-define-global[ized]-minor-mode yada yada.

There are a couple things I need to check on.

1. Non-repeatable loaddefs:

When you re-run make and it needs to regenerate lisp/loaddefs.el, it
appears easy-mmode is _not_ loaded by whatever emacs process conducts
that subsequent autoload-generation round.  Consequently,
`define-minor-mode' isn't loaded, so calls to it produce only partial
autoload entries (via, I believe, list 2).  Maybe that's why list 2
duplicates entries from list 1, as a backup against this non-repeatable
build.  But it seems strange to have different packages loaded on
different passes of the same Makefile target.  You can confirm this by:

% mv lisp/loaddefs.el lisp/loaddefs_orig.el
% make
% diff -u lisp/loaddefs_orig.el lisp/loaddefs.el

I'm not clear if this has anything to do with this patch, or could even
be a pre-existing build bug.  Once you are in this situation, you
basically have to `make bootstrap' to get the full and complete autoload
statements to appear again in loaddefs.

2. Some files are now being loaded during autoloads generation:

I noticed a few files among bundled lisp packages that now get loaded,
because they autoload undefined macros:

   loaddefs-gen: loading file frameset (cl-defun)
   Loading frameset...
     INFO     Scraping 1565 files for loaddefs...15% 
   loaddefs-gen: loading file ede/cpp-root (defclass)
   Loading ede/cpp-root...
     INFO     Scraping 1565 files for loaddefs...25% 
     INFO     Scraping 1565 files for loaddefs...47% 
     INFO     Scraping 1565 files for loaddefs...64% 
   loaddefs-gen: loading file tramp-adb (tramp--with-startup)
   Loading tramp-adb...
     INFO     Scraping 1565 files for loaddefs...80% 
   loaddefs-gen: loading file grep (define-compilation-mode)
   Loading grep...

These mostly seem to be innocuous in that after loading them, it becomes
clear that these particular autoloaded macros don't request
macro-expansion, so nothing different happens.  But it does represent a
few new "internal" load calls during autoload generation.  I think list
1 is now "doing more work" because of this pre-load mechanism.

Thoughts and suggestions very welcome.

[autoload-expand_2.patch (text/x-patch, attachment)]

[loaddefs.diff (text/x-patch, attachment)]

Previous Next

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