Subject: bug#53632: Function definition history

From: Eli Zaretskii <[email-masked]>
Date: Sun, 30 Jan 2022 09:43:12 +0200

> Date: Sun, 30 Jan 2022 00:07:57 -0500
> From:  Stefan Monnier via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <[email-masked]>
> 
> I suggest to replace that info with something slightly more complete.
> In the patch below I store the history of the function definition of
> a symbol in its `function-history` symbol property.  This history is
> stored as a list of the form (... VAL(n+1) FILE(n+1) VALn FILEn ...)
> where VALn is the value set by FILEn.  To make this list cheap in the
> default case, the latest value is not stored in the list (since it's in
> the `symbol-function`) and neither is the first file.  So if there's
> only been a single definition (the most common case), the list is empty
> and the property is just not present at all.  If a function was first
> defined as an autoload and then overriden by the actual function
> definition, then the list will hold (FILE2 AUTOLOAD), i.e. the name of
> the file that provided the actual function definition and the autoload
> that was used before that.
> [ Note: the name of the file that provided the first definition can be
>   recovered if really needed by checking all entries in `load-history`.
>   In the patch below I have not needed it.  ]
> 
> This makes it possible to handle correctly things like unloading
> `cl-loaddefs.el` which should remove the autoloads that are still
> autoloads and leave untouched the functions whose autoload have been
> replaced by the actual function definition.
> 
> In my tests it increased the size of the .pdmp by about 2KB (on a 32bit
> build).
> 
> The patch also gets rid of the `autoload` vs `defun` distinction in
> `load-history` which seems unnecessary (a significant part of the
> motivation for this patch was to get rid of the special handling of
> autoloads in this part of the code).  At least I couldn't find any place
> in the code which took advantage of that distinction.
> 
> Comments?  Objections?

Please make sure to document this in the ELisp manual.