GNU bug report logs - #53632
Function definition history

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 53632 <at> debbugs.gnu.org
Subject: bug#53632: Function definition history
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" <bug-gnu-emacs <at> gnu.org>
> 
> 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.

Previous Next

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