From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: End of file while generating loaddefs.el Date: Sat, 21 Nov 2015 10:49:47 +0200 Message-ID: <83vb8v4tzo.fsf@gnu.org> References: <834mgkbk2t.fsf@gnu.org> <564C2DDB.2090402@gmx.at> <83si439py4.fsf@gnu.org> <564D848D.4000301@gmx.at> <83lh9u7yp2.fsf@gnu.org> <564ED86E.3030705@gmx.at> <83egfl6p6a.fsf@gnu.org> <83a8q85qcy.fsf@gnu.org> <56502C62.8030803@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1448095854 1427 80.91.229.3 (21 Nov 2015 08:50:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 21 Nov 2015 08:50:54 +0000 (UTC) Cc: emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 21 09:50:46 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1a03s7-0001i0-Fc for ged-emacs-devel@m.gmane.org; Sat, 21 Nov 2015 09:50:15 +0100 Original-Received: from localhost ([::1]:51516 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a03s6-0008W4-QE for ged-emacs-devel@m.gmane.org; Sat, 21 Nov 2015 03:50:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46878) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a03ru-0008Vt-R3 for emacs-devel@gnu.org; Sat, 21 Nov 2015 03:50:03 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a03rr-0007KH-Kd for emacs-devel@gnu.org; Sat, 21 Nov 2015 03:50:02 -0500 Original-Received: from mtaout29.012.net.il ([80.179.55.185]:48267) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a03rr-0007JH-83 for emacs-devel@gnu.org; Sat, 21 Nov 2015 03:49:59 -0500 Original-Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NY500C00PI6NV00@mtaout29.012.net.il> for emacs-devel@gnu.org; Sat, 21 Nov 2015 10:49:18 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NY500755PU5Y050@mtaout29.012.net.il>; Sat, 21 Nov 2015 10:49:18 +0200 (IST) In-reply-to: <56502C62.8030803@gmx.at> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.185 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:194926 Archived-At: > Date: Sat, 21 Nov 2015 09:33:38 +0100 > From: martin rudalics > CC: emacs-devel@gnu.org > > > 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.