From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#54079: 29.0.50; Method dispatching eratically fails Date: Tue, 8 Mar 2022 20:48:23 +0000 Message-ID: References: <87mtik3l54.fsf@web.de> <87ilt6bgnt.fsf@web.de> <87sfsapgv0.fsf@web.de> <87o82ypfxz.fsf@web.de> <875youbhbu.fsf@web.de> <87k0d7257t.fsf@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5224"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Michael Heerdegen , acm@muc.de, Lars Ingebrigtsen , 54079@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Mar 08 21:49:18 2022 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 1nRglh-0001Dy-Of for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 08 Mar 2022 21:49:17 +0100 Original-Received: from localhost ([::1]:45250 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nRglg-0003wv-DN for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 08 Mar 2022 15:49:16 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:41522) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nRglS-0003wn-LY for bug-gnu-emacs@gnu.org; Tue, 08 Mar 2022 15:49:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:35881) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nRglS-0001Ty-Au for bug-gnu-emacs@gnu.org; Tue, 08 Mar 2022 15:49:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nRglS-0006fP-3m for bug-gnu-emacs@gnu.org; Tue, 08 Mar 2022 15:49:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 08 Mar 2022 20:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54079 X-GNU-PR-Package: emacs Original-Received: via spool by 54079-submit@debbugs.gnu.org id=B54079.164677251325583 (code B ref 54079); Tue, 08 Mar 2022 20:49:02 +0000 Original-Received: (at 54079) by debbugs.gnu.org; 8 Mar 2022 20:48:33 +0000 Original-Received: from localhost ([127.0.0.1]:58011 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nRgkz-0006eZ-6r for submit@debbugs.gnu.org; Tue, 08 Mar 2022 15:48:33 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:62161 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1nRgkx-0006eK-DW for 54079@debbugs.gnu.org; Tue, 08 Mar 2022 15:48:32 -0500 Original-Received: (qmail 8958 invoked by uid 3782); 8 Mar 2022 20:48:24 -0000 Original-Received: from acm.muc.de (p4fe15889.dip0.t-ipconnect.de [79.225.88.137]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 08 Mar 2022 21:48:23 +0100 Original-Received: (qmail 8225 invoked by uid 1000); 8 Mar 2022 20:48:23 -0000 Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de 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" Xref: news.gmane.io gmane.emacs.bugs:228155 Archived-At: Hello, Stefan. On Tue, Mar 08, 2022 at 14:53:07 -0500, Stefan Monnier wrote: > > diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el > > index 9be44a8d5a..fb9f70bd67 100644 > > --- a/lisp/emacs-lisp/bytecomp.el > > +++ b/lisp/emacs-lisp/bytecomp.el > > @@ -499,9 +499,10 @@ byte-compile-initial-macro-environment > > (byte-compile-new-defuns > > byte-compile-new-defuns)) > > (setf result > > - (byte-compile-eval > > + (byte-run-strip-symbol-positions > > + (byte-compile-eval > > (byte-compile-top-level > > - (byte-compile-preprocess form))))))) > > + (byte-compile-preprocess form)))))))) > I'd expect the reverse: strip first and then eval the result. > Why should we not strip the form passed to `byte-compile-eval`? It's an edge case either way, but the form being evaluated might be a `byte-compile', in which case it's (much) better to leave the positions in place during this operation. > Does `byte-compile-top-level` already return a stripped form of code? Compiled code is always stripped, at least since the weekend! > And why bother stripping the result of `byte-compile-eval`? Because it might be the result of evaluating a defun (or defvar or defconst). This was the situation which gave rise to the bug. > > @@ -512,9 +513,10 @@ byte-compile-initial-macro-environment > > ;; or byte-compile-file-form. > > (let* ((print-symbols-bare t) ; Possibly redundant binding. > > (expanded > > - (macroexpand--all-toplevel > > - form > > - macroexpand-all-environment))) > > + (byte-run-strip-symbol-positions > > + (macroexpand--all-toplevel > > + form > > + macroexpand-all-environment)))) > > (eval expanded lexical-binding) > > expanded))))) > > (with-suppressed-warnings > Fundamentally, `eval` should always strip before doing its job. Except when what it's evaluating is a defun, defmacrro, defsubst, etc. Then it would be better to evaluate SWPs (which would work, since we're inside a compilation, where enable-symbols-with-pos has been bound). But here EXPANDED has been stripped before being evaluated, so I'm not sure what you're saying here. > Yes, I know, it might be a bit expensive, but we should probably > define a local function in `bytecomp.el` which does strip+eval and use > that instead of `eval` (both here and in `byte-compile-eval`). WDYT? I don't think stripping is really all that expensive. There are one or two .el files in Emacs (ucs-normalize.el springs to mind) which have very large lists with vectors in them, yet they don't seem noticeably to slow down the Emacs build. > Stefan -- Alan Mackenzie (Nuremberg, Germany).