From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] trunk r117002: Correctly treat progn contents as toplevel forms when byte compiling Date: Mon, 21 Apr 2014 11:09:46 -0400 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1398094885 17399 80.91.229.3 (21 Apr 2014 15:41:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 21 Apr 2014 15:41:25 +0000 (UTC) Cc: emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 21 17:41:19 2014 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 1WcGLO-00044e-Mn for ged-emacs-devel@m.gmane.org; Mon, 21 Apr 2014 17:41:18 +0200 Original-Received: from localhost ([::1]:49877 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WcGLO-0001Cx-6r for ged-emacs-devel@m.gmane.org; Mon, 21 Apr 2014 11:41:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37017) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WcFr5-0001dK-Hy for emacs-devel@gnu.org; Mon, 21 Apr 2014 11:10:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WcFqy-0005KM-32 for emacs-devel@gnu.org; Mon, 21 Apr 2014 11:09:59 -0400 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:39379) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WcFqx-0005K2-UL for emacs-devel@gnu.org; Mon, 21 Apr 2014 11:09:52 -0400 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id s3LF9lnV007015; Mon, 21 Apr 2014 11:09:47 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id D3F7160088; Mon, 21 Apr 2014 11:09:46 -0400 (EDT) In-Reply-To: (Daniel Colascione's message of "Mon, 21 Apr 2014 09:34:29 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4919=0 X-NAI-Spam-Version: 2.3.0.9378 : core <4919> : inlines <751> : streams <1164035> : uri <1736389> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.22 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:171532 Archived-At: > Correctly treat progn contents as toplevel forms when byte compiling Your commit messages should be copies of the ChangeLog entry. Could you describe the case(s) that this fixes? > + ;; Macroexpand (not macroexpand-all!) That could be a problem. > form at toplevel in case it > + ;; expands into a toplevel-equivalent `progn'. See CLHS section > + ;; 3.2.3.1, "Processing of Top Level Forms". Note that Elisp is not Common-Lisp, so we don't always follow Common-Lisp's design decisions (although, we often do, as well). > The semantics are very > + ;; subtle: see test/automated/bytecomp-tests.el for interesting > + ;; cases. > + (setf form (macroexpand form byte-compile-macro-environment)) > + (if (eq (car-safe form) 'progn) > + (cons 'progn > + (mapcar (lambda (subform) > + (byte-compile-recurse-toplevel > + subform non-toplevel-case)) > + (cdr form))) > + (funcall non-toplevel-case form))) `non-toplevel-case' is declared as optional, but here you call it without ensuring it's non-nil. IOW it shouldn't be optional. > (defconst byte-compile-initial-macro-environment > '( > ;; (byte-compiler-options . (lambda (&rest forms) > ;; (apply 'byte-compiler-options-handler forms))) > (declare-function . byte-compile-macroexpand-declare-function) > (eval-when-compile . (lambda (&rest body) Oops, we have a bug here. We should be using `(... ,(lambda ... Stefan