GNU bug report logs -
#79353
31.0.50; Eager macro expansion errors when building master
Previous Next
Full log
Message #68 received at 79353 <at> debbugs.gnu.org (full text, mbox):
Michael Albinus <michael.albinus <at> gmx.de> writes:
> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>
>>> I'm not sure what this could mean; a corrupted file somewhere?
>>
>> No, it's just that `tramp-compat.el` uses `\N{...}`:
>> but that syntax is not supported by the Lisp reader in the early part of
>> the bootstrap because it relies on a data structure built during Emacs
>> compilation (using ELisp code) from the Unicode tables.
>
> tramp-compat-password-colon-equivalents is not autoloaded.
> tramp-compat.el does not contain any autoload cookie. Why is it in
> play here?
Because the new autoload bootstrap actually /loads/ files with autoload
calls to `tramp--with-startup`, e.g. the file `tramp-adb`. This file
requires `tramp`, which loads `tramp-compat`, which uses the (not yet
available) unicode syntax. Turns out there are more footguns to early
loading of lisp files than expected.
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:
;;;###autoload
(my-fancy-mode-define 'foo 'bar) ;; correctly expanded to define-minor-mode etc.
So far I think the only internal library which is unknown to the
bootstrap version of emacs used to build autoloads during compilation is
TRAMP. For example, it knows about easy-mmode (and hence
`define-minor-mode' and friends).
I see two options:
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.
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.
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))'.
External package autoload generation would still work fine, since this
uses a "full" emacs version to generate.
Option 2 has the one disadvantage that external (ELPA) packages which
moved into core would need to forego and rework whatever auto-expansion
they had. Since TRAMP has already happily existed in that state for
many years, I think this is fine. How to document this is another
issue. Kind of subtle and yucky.
Are there other good options I'm overlooking?
This bug report was last modified 1 day ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.