Re: End of file while generating loaddefs.el

[Eli Zaretskii]

> Date: Sat, 21 Nov 2015 09:33:38 +0100
> From: martin rudalics <address@hidden>
> CC: address@hidden
> 
>  > I don't know why prin1 crashed, but I do know why Emacs complains
>  > about end of file: there are null bytes in the middle of loaddefs.el.
>  > Do you have those too?
> 
> I suppose you mean this entry:
> 
> (autoload 'xref-find-backend "xref" "\
> 
> 
> \(fn)" nil nil)

The null bytes were in a different place in my case.

And anyway, what's the problem with the above?  That's what I have
here, after the problem is solved.  I also see that on GNU/Linux,
where there was no problem to begin with.

Why do you think it's this entry that was the cause of the problem?

> Do autoload cookies require a doc-string?

No, they don't require them.

>  > Emacs creates loaddefs.el by visiting the previous one and scanning it
>  > for certain patterns.  Those stray null bytes interrupt a pattern, so
>  > the result is that Emacs tries to parse an incomplete sexp, and barfs.
> 
> Why (apparently) on Windows only?

I don't know, because I have no idea what caused that in the first
place.

>  > if you also see these null bytes, delete them so that the expected
>  > format of the file is preserved, then re-run "make autoloads" -- it
>  > should succeed.
> 
> I now have
> 
> (autoload 'xref-find-backend "xref" "\
> Run...
> 
> \(fn)" nil nil)
> 
> instead and it ran to completion.

Great!  Although I don't understand what was the problem with that
spot in your case.  Were there any null bytes, anywhere?

>  > I don't know how these nulls ended up in loaddefs, the only hint is
>  > that they appear in the same place which Emacs scans when it produces
>  > this warning:
>  >
>  >    Making generated-autoload-file local to  *autoload-file* while let-bound
> 
> How did you spot that location?

I instrumented the autoload.el code to report it.

In 'autoload-read-section-header' (which was where the "end of file
during parsing" was coming from the call to 'read'), there's code that
takes a buffer-substring, and then edits it in a temporary buffer.  I
made that code print the start and end point of the buffer-substring,
then looked into the old loaddefs.el near the last position it printed
before barfing.