bug#78685: 30.1; Call to `sort' in lisp/desktop.el is missing a keyword., [PATCH] Avoid triggering autoloads in the byte compiler (bug#78685)

[Pip Cet]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> FWIW. When merging master I noticed that
>
> 1. A number of new obsolete function warnings appeared

I think that is caused by the autoloading, which ends up making
functions obsolete before they are compiled (recursive obsolete
functions are warned about).  Some of the other warnings appear to
depend on the order in which an obsolete function and another function
calling it appear in the .el file.  I'm not sure that always makes
sense, but my patch restores the previous warning-free behavior.

> 2. Build times from git clean -xdf went up from 1:20m to 1:50m

It wasn't that extreme on my machine, but I did see an increase of about
15 s which went away with my patch.

So I think those two problems would be fixed by my patch, but there's a
new one:

3. We no longer warn about mismatched argument counts in macro
redefinitions:

(defmacro defun ())

Previously, we printed

Warning: macro defun used to take 2 or more arguments, now takes 0

I'm not sure this warning is very useful, but it seems like
byte-compile-fdefinition should return the cdr of a macro when that is
the (potentially indirect) function of a symbol passed to it.

I must confess I don't quite understand what the intended behavior of
byte-compile-fdefinition is: for functions and macros, we want the same
behavior as indirect-function; for symbols which are ultimately not
fboundp, we want to call get-advertised-calling-convention, but on which
symbol?  The first in the chain or the last one?  For autoloads, we want
to return nil; for exotically-fbound symbols (not closures, not cons
cells, or cons cells with a strange car), does it really matter whether
we call get-advertised-calling-convention or not?

Pip