From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: add-change-log-entry Date: Mon, 23 Jul 2007 15:38:20 +0000 Message-ID: <20070723153820.GC2768@muc.de> References: <469E8702.5000204@gmx.at> <46A07200.6010103@gmx.at> <46A1CD47.7070802@gmx.at> <46A318F9.6090006@gmx.at> <20070722132404.GC895@muc.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1185205202 693 80.91.229.12 (23 Jul 2007 15:40:02 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 23 Jul 2007 15:40:02 +0000 (UTC) Cc: emacs-devel@gnu.org To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 23 17:39:58 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1ID00m-000246-8Z for ged-emacs-devel@m.gmane.org; Mon, 23 Jul 2007 17:39:54 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ID00k-0003og-Nq for ged-emacs-devel@m.gmane.org; Mon, 23 Jul 2007 11:39:50 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ICzzi-0003Wd-Pu for emacs-devel@gnu.org; Mon, 23 Jul 2007 11:38:46 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ICzze-0003VQ-TW for emacs-devel@gnu.org; Mon, 23 Jul 2007 11:38:46 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ICzze-0003VK-Jp for emacs-devel@gnu.org; Mon, 23 Jul 2007 11:38:42 -0400 Original-Received: from colin.muc.de ([193.149.48.1] helo=mail.muc.de) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1ICzzW-0002I8-Rg for emacs-devel@gnu.org; Mon, 23 Jul 2007 11:38:36 -0400 Original-Received: (qmail 46617 invoked by uid 3782); 23 Jul 2007 15:38:12 -0000 Original-Received: from acm.muc.de (p54A3CCF3.dip.t-dialin.net [84.163.204.243]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Mon, 23 Jul 2007 17:38:10 +0200 Original-Received: (qmail 14885 invoked by uid 1000); 23 Jul 2007 15:38:20 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Delivery-Agent: TMDA/1.1.5 (Fettercairn) X-Primary-Address: acm@muc.de X-detected-kernel: FreeBSD 4.6-4.9 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:75373 Archived-At: On Mon, Jul 23, 2007 at 12:28:09AM -0400, Richard Stallman wrote: > What does the byte-compiler bug consist of? emacs -Q Evaluate the following: (defun foo () (bar)) (byte-compile 'foo) (defun bar ()) (byte-compile 'bar) Now do M-: byte-compile-file .../emacs/lisp/emacs-lisp/bytecomp.el (or any other file, for that matter). This gives the following message: In end of data: bytecomp.el:4256:1:Warning: the function `bar' might not be defined at runtime. > What does your patch intend to do? The bug happens because the variable byte-compile-unresolved-functions is cleared at the END of a compilation rather than being initialised at the beginning of it. In the recipe above, it's value is ((bar 0)) at the start of the compilation. My patch initialises the variable correctly at the start of byte-compile-file, and also makes the variable's doc string less vague, this vagueness probably being what made the original hacker scared to initialise it in the first place. The following patch is against the Emacs 22 branch: 2007-07-23 Alan Mackenzie * emacs-lisp/bytecomp.el (byte-compile-from-buffer): initialise byte-compile-unresolved-functions before rather than after a compilation. (byte-compile-unresolved-functions): Amplify doc string. Index: bytecomp.el =================================================================== RCS file: /cvsroot/emacs/emacs/lisp/emacs-lisp/bytecomp.el,v retrieving revision 2.198 diff -c -r2.198 bytecomp.el *** bytecomp.el 11 Apr 2007 03:59:20 -0000 2.198 --- bytecomp.el 23 Jul 2007 15:26:07 -0000 *************** *** 476,482 **** (defvar byte-compile-unresolved-functions nil "Alist of undefined functions to which calls have been compiled. ! Used for warnings when the function is not known to be defined or is later defined with incorrect args.") (defvar byte-compile-noruntime-functions nil --- 476,483 ---- (defvar byte-compile-unresolved-functions nil "Alist of undefined functions to which calls have been compiled. ! This variable is only significant whilst compiling an entire buffer. ! Used for warnings when a function is not known to be defined or is later defined with incorrect args.") (defvar byte-compile-noruntime-functions nil *************** *** 1848,1853 **** --- 1849,1859 ---- (save-excursion (set-buffer inbuffer) (goto-char 1) + ;; Should we always do this? When calling multiple files, it + ;; would be useful to delay this warning until all have been + ;; compiled. A: Yes! b-c-u-f might contain dross from a + ;; previous byte-compile. + (setq byte-compile-unresolved-functions nil) ;; Compile the forms from the input buffer. (while (progn *************** *** 1864,1874 **** ;; Make warnings about unresolved functions ;; give the end of the file as their position. (setq byte-compile-last-position (point-max)) ! (byte-compile-warn-about-unresolved-functions) ! ;; Should we always do this? When calling multiple files, it ! ;; would be useful to delay this warning until all have ! ;; been compiled. ! (setq byte-compile-unresolved-functions nil)) ;; Fix up the header at the front of the output ;; if the buffer contains multibyte characters. (and filename (byte-compile-fix-header filename inbuffer outbuffer)))) --- 1870,1876 ---- ;; Make warnings about unresolved functions ;; give the end of the file as their position. (setq byte-compile-last-position (point-max)) ! (byte-compile-warn-about-unresolved-functions)) ;; Fix up the header at the front of the output ;; if the buffer contains multibyte characters. (and filename (byte-compile-fix-header filename inbuffer outbuffer)))) -- Alan Mackenzie (Ittersbach, Germany).