Subject: bug#63236: 29.0.90; loaddefs-generate not 100% backwards compatible

From: Robert Pluim <[email-masked]>
Date: Tue, 02 May 2023 19:06:14 +0200

I attempted to upgrade my packages today using `list-packages', which
errored out when regenerating the autoloads for vlf-write.el:

Debugger entered--Lisp error: (search-failed "\n\f\n;;;")
  search-forward("\n\f\n;;;")
  loaddefs-generate("/home/rpluim/.emacs.d/elpa/vlf-20191126.2250" "/home/rpluim/.emacs.d/elpa/vlf-20191126.2250/vlf-a..." nil "(add-to-list 'load-path (or (and load-file-name (f...")
  package-generate-autoloads(vlf "/home/rpluim/.emacs.d/elpa/vlf-20191126.2250")

The vlf-autoloads.el file ends like this:

--begin--

;;; Generated autoloads from vlf-tune.el

(register-definition-prefixes "vlf-tune" '("vlf-"))


;;; Generated autoloads from vlf-write.el

(register-definition-prefixes "vlf-write" '("vlf-"))

;; Local Variables:
;; version-control: never
;; no-byte-compile: t
;; no-update-autoloads: t
;; coding: utf-8
;; End:
;;; vlf-autoloads.el ends here
--end--

which doesnʼt contain "\n\f\n;;;" after the vlf-write entry.

The code in question from loaddefs-gen.el:629 is

              (when (file-exists-p loaddefs-file)
                ;; If we're updating an old loaddefs file, then see if
                ;; there's a section here for this file already.
                (goto-char (point-min))
                (if (not (search-forward head nil t))
                    ;; It's a new file; put the data at the end.
                    (progn
                      (goto-char (point-max))
                      (search-backward "\f\n" nil t))
                  ;; Delete the old version of the section.
                  (delete-region (match-beginning 0)
                                 (and (search-forward "\n\f\n;;;")
                                      (match-beginning 0)))
                  (forward-line -2)))

So itʼs assuming that the entry ends with ";;;"

This is a really old package, and itʼs probably somewhat obsolete, but
perhaps we should support such an old format without erroring anyway.

In GNU Emacs 29.0.90 (build 8, x86_64-pc-linux-gnu, GTK+ Version
 3.24.24, cairo version 1.16.0) of 2023-05-02 built on rltb
Repository revision: 16ecbf5af6d4fcb500941ede4d029cffd8eac757
Repository branch: emacs-29
Windowing system distributor 'The X.Org Foundation', version 11.0.12009000
System Description: Debian GNU/Linux 11 (bullseye)