From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dan Nicolaescu Newsgroups: gmane.emacs.devel Subject: Re: strange byte compiler behavior Date: Wed, 02 Jan 2008 15:17:30 -0800 Message-ID: <200801022317.m02NHVSC017328@oogie-boogie.ics.uci.edu> References: <200712312055.lBVKteSa012881@oogie-boogie.ics.uci.edu> <200801021948.m02JmJ1Y005211@oogie-boogie.ics.uci.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1199315927 9596 80.91.229.12 (2 Jan 2008 23:18:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 2 Jan 2008 23:18:47 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 03 00:19:05 2008 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 1JACrY-0000Ba-U5 for ged-emacs-devel@m.gmane.org; Thu, 03 Jan 2008 00:19:05 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JACrC-0003uZ-JP for ged-emacs-devel@m.gmane.org; Wed, 02 Jan 2008 18:18:42 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JACr8-0003rw-6x for emacs-devel@gnu.org; Wed, 02 Jan 2008 18:18:38 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JACr6-0003qv-Pk for emacs-devel@gnu.org; Wed, 02 Jan 2008 18:18:37 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JACr6-0003qs-K5 for emacs-devel@gnu.org; Wed, 02 Jan 2008 18:18:36 -0500 Original-Received: from oogie-boogie.ics.uci.edu ([128.195.1.41]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JACr6-0004XI-Bn for emacs-devel@gnu.org; Wed, 02 Jan 2008 18:18:36 -0500 Original-Received: from mothra.ics.uci.edu (mothra.ics.uci.edu [128.195.6.93]) by oogie-boogie.ics.uci.edu (8.13.6/8.13.6) with ESMTP id m02NHVSC017328 for ; Wed, 2 Jan 2008 15:17:31 -0800 (PST) In-Reply-To: <200801021948.m02JmJ1Y005211@oogie-boogie.ics.uci.edu> (Dan Nicolaescu's message of "Wed, 02 Jan 2008 11:48:18 -0800") Original-Lines: 49 X-ICS-MailScanner: Found to be clean X-ICS-MailScanner-SpamCheck: not spam, SpamAssassin (score=-1.44, required 5, autolearn=disabled, ALL_TRUSTED -1.44) X-ICS-MailScanner-From: dann@mothra.ics.uci.edu X-detected-kernel: by monty-python.gnu.org: Solaris 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:85949 Archived-At: Dan Nicolaescu writes: > Dan Nicolaescu writes: > > > When compiling vc-cvs in batch mode (cd emacs/lisp; make recompile) > > no warning is issued. > > > > When compiling it with M-x byte-compile-file this warning is issued: > > > > In vc-cvs-register: > > vc-cvs.el:301:41:Warning: reference to free variable `file' > > > > > > The warning is correct, it looks like vc-cvs-register has a bug, it > > should look at `files', not `file'. > > > > Any idea why this warning is not issued in batch mode? > > > Investigating a bit: > > 1. > cd lisp ; make recompile > > which runs: -batch --no-site-file --multibyte --eval "(batch-byte-recompile-directory 0)" > does NOT warn > > but running: > > -batch --no-site-file --multibyte --eval '(byte-compile-file "vc-cvs.el")' > > warns > > 2. the warning is related to the name `file', if the variable is renamed > `file1' both the batch mode and interactive mode produce a warning. > > 3. Adding this: > > (message "var %s boundp %s" var (boundp var)) > to `byte-compile-variable-ref' shows that `file' is bound for the function > in question. Which would explain the results. > Any idea what causes `file' to be bound? (Assuming that boundp is the > correct test in that context...) `byte-recompile-directory' contains a form: "(dolist (file files)" that calls `byte-compile-file'. As a consequence (boundp 'file) to be t when `byte-compile-file' is called. What is TRTD here?