GNU bug report logs - #79353
31.0.50; Eager macro expansion errors when building master

Previous Next

Full log

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

From: JD Smith <jdtsmith <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 Po Lu <luangruo <at> yahoo.com>, Michael Albinus <michael.albinus <at> gmx.de>,
 79353 <at> debbugs.gnu.org
Subject: Re: bug#79353: 31.0.50; Eager macro expansion errors when building
 master
Date: Wed, 3 Sep 2025 12:53:14 -0400

> On Sep 3, 2025, at 11:19 AM, Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:
> 
>> available) unicode syntax.  Turns out there are more footguns to early
>> loading of lisp files than expected.
> 
> Bootstrap is full of exciting surprises.

:) 

>> Zooming back out, this entire feature was really created for /external
>> packages/, so they could provide their own macros which wrap
>> e.g. `define-minor-mode`, and have these autoloads handled correctly
>> without pre-loading anything:
> 
> FWIW, it's best to reduce differences between "internal" and "external"
> packages.

Yeah, that's my instinct too, since some packages are both, and some migrate in either direction.

>> 1. Find and fix the footguns, making the bootstrap version of Emacs used
>>   for autoload generation more robust.  E.g. move unicode table
>>   generation earlier in the build.
> 
> Worth a try, but as you've seen the bootstrap is ... interesting so it
> may prove more trouble than its worth.
> We could also change `tramp-compat.el` to refrain from using the \N{...} syntax.
> 
> One more thing: AFAIK we're talking about eliminating a compile-time
> *warning*, right?  IOW, the new autoload-macro-expansion is sufficiently
> careful to withstand errors that the resulting code still works, no?

Yes, the error is handled, and the result is that the TRAMP file which autoloads calls to `tramp--with-startup' simply fails to load, hence that macro remains undefined. This macro, and autoload calls to it, are then copied verbatim into the tramp-loaddefs.el file.  Which is how it has been for many years.

>> 2. Stop loading internal files during bootstrap.  Add an argument to
>>   `loaddefs-generate--make-autoload' which inhibits loading absolutely.
>>   Pass this arg in during bootstrap autoload generation.
> 
> I'd rather not go there if I can avoid it.
> 
>> For option 2, we'd remove the expand declaration from
>> `tramp--with-startup', which is incomplete anyway, since some of its
>> autoloads are gated behind e.g. `(when ... (tramp--with-startup))'.
> 
> We should probably remove it anyway: it was a good way to test the new
> functionality, but it's not that important.

It currently doesn't function due to the load error.  We could of course just catch and not report load errors. But they do provide insight into early-loading issues that may merit correction.  And this "silent approach" would be a problem for internal packages which begin to rely on `autoload-macro expand` and the early-loading behavior during autoload bootstrap generation, only later to find out loading no longer occurs because of the introduction of some new bootstrap-emacs problem, causing breakage.  Preventing /future/ problems seems important.

Summarizing, I guess option 3 is just:

3. Stop declaring autoload-macro expand in tramp--with-startup (since it doesn't function anyway), and ask people to ignore the warning.

I do think a real question could be asked: how early should it be possible to load a valid lisp file?  

Thanks

Previous Next

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