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: Sun, 13 Mar 2022 16:49:58 +0000 Message-ID: References: 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="26118"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Michael Heerdegen , 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 Sun Mar 13 17:51:11 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 1nTRR1-0006fC-9e for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 13 Mar 2022 17:51:11 +0100 Original-Received: from localhost ([::1]:44990 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nTRQz-0003O8-PB for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 13 Mar 2022 12:51:09 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:48922) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nTRQr-0003Nw-WD for bug-gnu-emacs@gnu.org; Sun, 13 Mar 2022 12:51:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49281) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nTRQr-0006iV-Nk for bug-gnu-emacs@gnu.org; Sun, 13 Mar 2022 12:51:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nTRQr-0003cQ-K3 for bug-gnu-emacs@gnu.org; Sun, 13 Mar 2022 12:51:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 13 Mar 2022 16:51:01 +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.164719021013816 (code B ref 54079); Sun, 13 Mar 2022 16:51:01 +0000 Original-Received: (at 54079) by debbugs.gnu.org; 13 Mar 2022 16:50:10 +0000 Original-Received: from localhost ([127.0.0.1]:43178 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nTRQ1-0003ak-Uf for submit@debbugs.gnu.org; Sun, 13 Mar 2022 12:50:10 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:24797 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1nTRPz-0003a6-Jj for 54079@debbugs.gnu.org; Sun, 13 Mar 2022 12:50:08 -0400 Original-Received: (qmail 75965 invoked by uid 3782); 13 Mar 2022 16:50:00 -0000 Original-Received: from acm.muc.de (p4fe157ef.dip0.t-ipconnect.de [79.225.87.239]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 13 Mar 2022 17:50:00 +0100 Original-Received: (qmail 8817 invoked by uid 1000); 13 Mar 2022 16:49:58 -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:228302 Archived-At: Hello, Stefan. On Fri, Mar 11, 2022 at 23:23:50 -0500, Stefan Monnier wrote: [ .... ] > Whatever appears in the code passed through `eval-{when,and}-compile` > can survive that code, so the fact that `symbols-with-pos-enabled` is > `eval` is exactly this "as long as possible" point where we know the > code won't be compiled because it's about to be interpreted. > non-nil while evaluating it doesn't make it correct. OK, you've persuaded me. ;-) Lisp forms need to be stripped of SWPs before being passed into `eval'. > > But, looking at the code, I don't think byte-compile binds > > symbols-with-pos-enabled to t. This could be a bug. > Maybe not: it has no reason to presume that its argument has positions. More to the point, I don't think it can assume that there aren't SWPs in the form. > If it does, then it must be because the caller explicitly arranged for > it to happen and so the caller could be in charge of binding > that variable. The caller could be any lisp function. It's just that binding symbols-with-pos-enabled in byte-compile is cheap and harmless, and there might well be legitimate cases that need it. I can't think of any at the moment, though. > >> And why bother stripping the result of `byte-compile-eval`? I think this point is moot if the form has been stripped before going into byte-compile-eval. In that case, there will be no need to strip the result. [ .... ] > >> Fundamentally, `eval` should always strip before doing its job. > > You mean, by "always", you meant ALWAYS??? > Yes. > > I understood you to mean "always, when in the context of > > eval-{when,and}-compile". If we're not inside a compilation, and thus > > there're no SWPs hanging around, stripping symbols from an expression > > will just mean a loss of time for a null operation. > That's right: the only cases where not stripping the arg of `eval` is OK > is when we know that stripping would do nothing. > IOW it's an optimization. It's NOT an optimisation. It's a straightforward implementation of the design. To add unnecessary stripping of non-existent symbol positions would be a pessimisation, a possibly measurable slowing down of Emacs. The whole essence of the SWP design was to minimise the influence of the SWPs on code which isn't the compiler. Always stripping before calling `eval' would not be in accordance with that design. There are a lot of places where `eval' is called. Inserting byte-run-strip-symbol-positions before each of them would be tedious in the extreme. Instead damaging `eval', to make it do two disparate things which just happen to follow on from eachother sometimes, would be worse; it would likely involve adding an extra &optional argument meaning "strip". [ .... ] > >> The misbehavior I'm referring to is what happens when you call the > >> function before you byte-compile it (or, more likely, when you never end > >> up byte-compiling it), because the presence of sympos in the function > >> will mess up its semantics (because `symbols-with-pos-enabled` won't be > >> set any more when it's called). > > I'm puzzled. Are we still talking about eval-{when,and}-compile, here? > No. We're talking about a hypothetical case where `(eval '(defun foo ...))` > is executed somehow and where the `(defun foo ...)` part somehow > contains symposes. Modulo bugs, I think that could only happen in a macro, where the (defun foo ...) bit was an argument, and the macro takes steps to preserve that argument beyond its natural scope. > I used it as an example of why `eval` should conceptually always strip > its argument (or if `eval` doesn't do it, then its caller should make > sure that the code passed to it doesn't contains symposes). I think it will be rare. [ .... ] I will prepare another patch which strips the forms of SWPs before the `eval' in eval-{when,and}-compile. Apologies if I've inadvertently failed to answer any open points. > Stefan -- Alan Mackenzie (Nuremberg, Germany).