From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#34757: Invalid bytecode from byte compiler Date: Fri, 15 Mar 2019 16:30:10 -0400 Message-ID: References: <838sxg1rwz.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="55515"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: 34757@debbugs.gnu.org, chuntaro@sakura-games.jp To: Pip Cet Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Mar 15 21:31:17 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h4tU5-000EHX-8U for geb-bug-gnu-emacs@m.gmane.org; Fri, 15 Mar 2019 21:31:17 +0100 Original-Received: from localhost ([127.0.0.1]:32774 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h4tU4-0006Dm-6R for geb-bug-gnu-emacs@m.gmane.org; Fri, 15 Mar 2019 16:31:16 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:51260) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h4tTx-0006Dd-5Y for bug-gnu-emacs@gnu.org; Fri, 15 Mar 2019 16:31:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h4tTt-0004Kb-Do for bug-gnu-emacs@gnu.org; Fri, 15 Mar 2019 16:31:07 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:60221) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1h4tTq-0004IL-FX for bug-gnu-emacs@gnu.org; Fri, 15 Mar 2019 16:31:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1h4tTq-0002CT-B0 for bug-gnu-emacs@gnu.org; Fri, 15 Mar 2019 16:31: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: Fri, 15 Mar 2019 20:31:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34757 X-GNU-PR-Package: emacs Original-Received: via spool by 34757-submit@debbugs.gnu.org id=B34757.15526818168404 (code B ref 34757); Fri, 15 Mar 2019 20:31:02 +0000 Original-Received: (at 34757) by debbugs.gnu.org; 15 Mar 2019 20:30:16 +0000 Original-Received: from localhost ([127.0.0.1]:45532 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h4tT6-0002BT-4P for submit@debbugs.gnu.org; Fri, 15 Mar 2019 16:30:16 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:46868) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h4tT3-0002BI-IM for 34757@debbugs.gnu.org; Fri, 15 Mar 2019 16:30:15 -0400 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id x2FKUBr3001469; Fri, 15 Mar 2019 16:30:11 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id F11F36AB95; Fri, 15 Mar 2019 16:30:10 -0400 (EDT) In-Reply-To: (Pip Cet's message of "Fri, 15 Mar 2019 19:40:48 +0000") X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6504=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6504> : inlines <7035> : streams <1815807> : uri <2813474> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:156398 Archived-At: > Just to be sure I understand correctly, you would like to remove the > decompilation of trivial function calls entirely? Yes, tho the main motivation was to try and figure out what the decompilation is useful for. This only affects "open code" (i.e. not the content of functions, which are already never decompiled), so the impact should be minor and it removes a rather complicated and brittle chunk of code whose purpose is not clear. It was originally introduced when we didn't have byte-compiled function objects, so its main purpose was one of performance, to avoid pessimizing the code by replacing trivial function calls with more costly (byte-code "...") expressions but nowadays such (byte-code "...") expressions only occur basically at the top-level of .elc files where such pessimization would be unnoticeable in terms of performance. It does impact the readability of .elc files, OTOH, so I'm not completely happy with the result when considering the few cases where I was happy to be able to make sense of a .elc file to better understand the source of a problem (after all, that's why I wrote the elisp-byte-code-mode). > It seems the special case is necessary to avoid compilation errors, I haven't found it to be really necessary, no. > and that it's used for (byte-compile 3), so I think the comment could > be improved a little. (byte-compile 3) seems to work correctly here even without the special case. It returns (byte-code "\300\207" [3] 1) which is indeed a correct expression that evaluates to 3 (just like the argument to `byte-compile` was an expression whose evaluation returns 3). Let's not forget that what `byte-compile` tries to do is to preserve the invariant that (eval EXP) =E2=89=83 (eval (byte-compile EXP)) This said, if you remove the special case, you will bump into a corner-case bug in `byte-compile` which happens because that function incorrectly considers that `byte-compile-top-level` returns a value whereas in reality it returns an expression (just like `byte-compile`): the decompilation happens to turn expressions that return constant values (like byte-compiled functions) into their value (as an optimization which relies on the fact that those objects are self-evaluating), so if you remove it, you then bump into this bug of byte-compile. The patch below would fix this bug. But indeed the decompilation of constants is handy since that's what people expect from `byte-compile`. When I (byte-compile '(lambda (x) (foo))) I expect to receive a byte-compiled function, and not a byte-code expression which when evaluated will return that byte-compiled function. > I'm not sure this case can actually happen without doing something > silly, but (byte-compile '(internal-get-closed-var 0)) throws an error > with Stefan's patch, because the byte code is (byte-constant . 0) > (byte-return). This source code is arguably invalid, so it's not a real problem, but indeed we should burp in that case. I can't remember enough of how internal-get-closed-var is handled to know where'd the bug be, offhand. Stefan diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el index f46cab2c17..ae17553d0c 100644 --- a/lisp/emacs-lisp/bytecomp.el +++ b/lisp/emacs-lisp/bytecomp.el @@ -2674,7 +2674,11 @@ byte-compile (setq fun (byte-compile-top-level fun nil 'eval))) (if macro (push 'macro fun)) (if (symbolp form) - (fset form fun) + ;; byte-compile returns an *expression* equivalent to the + ;; `fun' expression, so we need to evaluate it, tho normally + ;; this is not needed because the expression is just a constant + ;; byte-code object, which is self-evaluating. + (fset form (eval fun t)) fun))))))) =20 (defun byte-compile-sexp (sexp)