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

[Eli Zaretskii <eliz@gnu.org>]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: 63236@debbugs.gnu.org
> Date: Wed, 03 May 2023 15:47:21 +0200
> 
> >>>>> On Wed, 03 May 2023 14:21:05 +0300, Eli Zaretskii <eliz@gnu.org> said:
> 
>     >> From: Robert Pluim <rpluim@gmail.com>
>     >> Date: Wed, 03 May 2023 10:40:28 +0200
>     >> 
>     >> >>>>> On Tue, 02 May 2023 19:06:14 +0200, Robert Pluim <rpluim@gmail.com> said:
>     >> 
>     Robert> I attempted to upgrade my packages today using `list-packages', which
>     Robert> errored out when regenerating the autoloads for vlf-write.el:
>     >> 
>     Robert> Debugger entered--Lisp error: (search-failed "\n\f\n;;;")
>     Robert> search-forward("\n\f\n;;;")
>     Robert> 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...")
>     Robert> package-generate-autoloads(vlf "/home/rpluim/.emacs.d/elpa/vlf-20191126.2250")
>     >> 
>     >> The minimal patch I can come up with is this, which seems safe enough
>     >> but Iʼd appreciate it if someone who knows the code could comment
> 
>     Eli> Can you describe what was special in your use case, and explain why
>     Eli> the original code didn't work in that case?
> 
> Itʼs not the use case thatʼs special, itʼs the package I was installing:
> The autoloads file shipped with vlf-20191126.2250 didnʼt have a line
> starting with ';;;' after the final entry in the file, which is what
> the code was looking for.

But if the search for "\n\f\n;;;" fails, why should we assume that the
search for "\n\f\n;;" will succeed?  A broken autoloads file can be
broken in a much worse manner, no?  Is even a form-feed guaranteed?

Maybe we should assume, if the search for the canonical last line
fails, that there's no canonical last line, and just insert it
ourselves?

What did the old code do in these cases?

> Looking at the history, the autoloads generation was rewritten for
> emacs-29, so this looks like a minor regression.

Yes, loaddefs-gen.el is new, so we must fix it on the emacs-29 branch.