From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#62317: 28.2; This byte-compiled file behaves wrongly. Date: Sat, 01 Apr 2023 12:27:35 -0400 Message-ID: References: <20230321.125408.609857763486645873.teika@gmx.com> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19237"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 62317@debbugs.gnu.org To: Teika Kazura Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Apr 01 18:28:21 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pie5V-0004nQ-5Z for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 01 Apr 2023 18:28:21 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pie5F-0007tL-6Y; Sat, 01 Apr 2023 12:28:05 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pie5D-0007qS-4v for bug-gnu-emacs@gnu.org; Sat, 01 Apr 2023 12:28:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pie5C-00046s-LO for bug-gnu-emacs@gnu.org; Sat, 01 Apr 2023 12:28:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pie5C-0007TR-2T for bug-gnu-emacs@gnu.org; Sat, 01 Apr 2023 12:28:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 01 Apr 2023 16:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62317 X-GNU-PR-Package: emacs Original-Received: via spool by 62317-submit@debbugs.gnu.org id=B62317.168036646628699 (code B ref 62317); Sat, 01 Apr 2023 16:28:02 +0000 Original-Received: (at 62317) by debbugs.gnu.org; 1 Apr 2023 16:27:46 +0000 Original-Received: from localhost ([127.0.0.1]:38459 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pie4w-0007Sp-4a for submit@debbugs.gnu.org; Sat, 01 Apr 2023 12:27:46 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:29728) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pie4t-0007Sa-QE for 62317@debbugs.gnu.org; Sat, 01 Apr 2023 12:27:44 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 437E81000E6; Sat, 1 Apr 2023 12:27:38 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 092281000BD; Sat, 1 Apr 2023 12:27:37 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1680366457; bh=843Ika6wMNSkW4L+SxlHQHUtaHiIHbHozfFUbc55QSk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=UNzEFytK645lgsYjgXWKYKAH+Sb9pah8zIUqWSh+8GOT0uLs9CkBRSQXuC/bqUf1z op6BIeYgXSfb2eWZM+TRre+oUO0ID50Vs7cPmDpMn5/QK4zihM5ZIWHIMxmX/XbFYz 8CTKVgGin32GAyIb1VpCMN1Of8Bj7qKWxckYpvs7n+DkBWAac8ULsyW/WyD7BE9/kW +To+bf6Tn0CYxbq+WyF3kATbD6QBJjZzIJjWy4u+ZrnWvEMt98VVhqA1rZ7QfcVh0J pLF+M/i2nYJYfSzff0zFIn83tJC3P6mxTKKJIpgH9tZsQy8MzXlf5pnKXQcrLtZaXc kaZR1xqDJ39sg== Original-Received: from pastel (unknown [45.72.217.176]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D7A4F12326D; Sat, 1 Apr 2023 12:27:36 -0400 (EDT) In-Reply-To: <20230321.125408.609857763486645873.teika@gmx.com> (Teika Kazura's message of "Tue, 21 Mar 2023 12:54:08 +0900 (JST)") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:259059 Archived-At: > * How to reproduce: > First, ~/.emacs.d/init.el: > ------------------------------------------------------------------------ > (eval-and-compile > (push user-emacs-directory load-path) > (require 'a)) > > ;; Hereafter is ignored when byte-compiled. > > (defvar foo-var 'baz) > (message "Hello, world.") > (pop-to-buffer "*Messages*") > ------------------------------------------------------------------------ > > ~/.emacs.d/a.el: > ------------------------------------------------------------------------ > (set-buffer "*Messages*") ;; or (set-buffer (get-buffer-create "bar")) > (provide 'a) > ------------------------------------------------------------------------ I suspect you can simplify the above to: (eval-and-compile (set-buffer "*Messages*")) ;; Hereafter is ignored when byte-compiled. (message "Hello, world.") > Stefan, any ideas? I think switching to a different buffer inside > `eval-and-compile` is a bad idea, but maybe I'm missing something. I tend to agree. [ Side note: (push user-emacs-directory load-path) is also a bad idea. ] We could guard against this to some extent, but there will always be ways for the code executed at compile-time to mess up the state of the compiler, so I'm not sure where we should draw the line. FWIW, in my book `set-buffer` is a code smell (usually better replaced by `with-current-buffer`). Admittedly, the resulting behavior can be very puzzling&frustrating for the user, which would tend to argue in favor of trying to at least detect the problem. But note that if the code switched to a buffer where point is not at EOB, we'd probably get helpful error messages during compilation, so I'm leaning towards considering it a "minor corner case" issue, but I think the untested patch below would be enough to plug the hole. Stefan diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el index 5df1205869c..e22ab94e378 100644 --- a/lisp/emacs-lisp/bytecomp.el +++ b/lisp/emacs-lisp/bytecomp.el @@ -2376,7 +2376,10 @@ byte-compile-from-buffer (form (read-positioning-symbols inbuffer)) (warning (byte-run--unescaped-character-literals-warning))) (when warning (byte-compile-warn-x form "%s" warning)) - (byte-compile-toplevel-file-form form))) + ;; Defend against macros using `set-buffer' or `goto-char' + ;; bug#62317. + (save-excursion + (byte-compile-toplevel-file-form form)))) ;; Compile pending forms at end of file. (byte-compile-flush-pending) (byte-compile-warn-about-unresolved-functions)))