Subject: bug#78995: [PATCH] ;;;autoload-expand for special macros

From: Stefan Monnier <[email-masked]>
Date: Sun, 03 Aug 2025 19:17:12 -0400

> The short but unsatisfying answer is to preserve the hard-coded list
> of macros to expand, which this functionality replaces and extends.
> The former explanation in `loaddefs-generate--make-autoload' was quite
> terse:
>
>  ;; For complex cases, try again on the macro-expansion.

The reason is always that calls to these macros don't want to be
*preloaded* but only to be *autoloaded*.  By expanding the macro,
`autoload.el` (aka `loaddefs-gen.el`) gets to see the underlying
`defalias` and friends necessary to figure out *how* to autoload it.

In practice this means it's used for macros which define functions (or
macros).

> I've tried to inject a short explanation everywhere this declaration
> is used.  I left the `byte-run--set-autoload-macro' alone, since
> that's just a generic property setter, and values other than `expand'
> may be used in the future. Latest patch below.
>
> Meta-comments:
> ==============
>
> Though outside of the scope of this patch, a few mildly bothersome
> attributes remain, which I leave here for posterity.
>
> 1. It's somewhat arbitrary which macros request expansion
>
> Eventually, I think for all builtin macros, the question should be
> asked: "Will calls to this macro likely be marked ;;;###autoload"?
> If the answer is yes, the macro should declare
> `autoload-macro=expand', so that these calls get recursively expanded
> down to their most basic forms — `defalias', `put', and so on.

It's a judgment call: will it be more common to *preload* or to
*autoload*?

> 2. Some autoloaded macro expansions are not "autoload-hygienic".
> 3. Some macros' autoload treatment depend on whether they are defined
> at autoload-generation time.

I hope your patch will help us fix those issues.

        Stefan