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#54079: 29.0.50; Method dispatching eratically fails Date: Wed, 09 Mar 2022 13:06:11 -0500 Message-ID: References: <87ilt6bgnt.fsf@web.de> <87sfsapgv0.fsf@web.de> <87o82ypfxz.fsf@web.de> <875youbhbu.fsf@web.de> <87k0d7257t.fsf@web.de> 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="17748"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Michael Heerdegen , Lars Ingebrigtsen , 54079@debbugs.gnu.org To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Mar 09 19:07:16 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 1nS0iR-0004Qp-Ia for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 09 Mar 2022 19:07:15 +0100 Original-Received: from localhost ([::1]:40520 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nS0iQ-0002yg-7e for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 09 Mar 2022 13:07:14 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:33010) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nS0iE-0002u1-0P for bug-gnu-emacs@gnu.org; Wed, 09 Mar 2022 13:07:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:38564) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nS0iD-0003DQ-OH for bug-gnu-emacs@gnu.org; Wed, 09 Mar 2022 13:07:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nS0iD-0004Ok-JE for bug-gnu-emacs@gnu.org; Wed, 09 Mar 2022 13:07:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 09 Mar 2022 18:07: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.164684918216855 (code B ref 54079); Wed, 09 Mar 2022 18:07:01 +0000 Original-Received: (at 54079) by debbugs.gnu.org; 9 Mar 2022 18:06:22 +0000 Original-Received: from localhost ([127.0.0.1]:60694 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nS0ha-0004Nn-Hk for submit@debbugs.gnu.org; Wed, 09 Mar 2022 13:06:22 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:54477) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nS0hY-0004NZ-Ey for 54079@debbugs.gnu.org; Wed, 09 Mar 2022 13:06:21 -0500 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 454ED10020C; Wed, 9 Mar 2022 13:06:14 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id A818C100009; Wed, 9 Mar 2022 13:06:12 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1646849172; bh=IdK0nG4WzjzKA2Sn4Gz2AQwdwpXraZITxF0/vH3hhis=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=L6s0gprZ+zgwFJWilng4rfA7qBhtQOv+6R85bLPmY/spiFQjhSb+dnH0kTPZ6wqQ4 Y3PKRwgtK0W0+11aGwhwkeXapaFO9RHb2Znkvd2jjl6nXcwff5YUS7anWfgRckL70j HtQVLWH+QJyge2ttdzVENip7RwE0pxE1rD9UwZSrWNyNn20R5LHAw8XLMSXassI2uL JgnMd4zRmUDymqBAZSQ50ilULS7FqArPUH0wz3sfuD2K32U3u3qwNWzPBg0BI4ocXl brDedQybMdwwykYUMqdSMoeKWp9eNtJLfUK8C1HUp08zRYuVjeWwTPYTaYjRXVxN7Y AtK6IRbxfBKVw== Original-Received: from alfajor (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 9520E120263; Wed, 9 Mar 2022 13:06:12 -0500 (EST) In-Reply-To: (Alan Mackenzie's message of "Wed, 9 Mar 2022 17:42:56 +0000") 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:228173 Archived-At: >> I don't understand the scenario you're thinking of. >> Are you thinking of something like `(eval-when-compile (byte-compile ...))? > Yes. >> Does that ever happen in real life? > Probably exceedingly seldomly. > What's to be gained by not catering to this unusual case? What do we > lose? We lose making it work right for the 99% other cases that *do* occur? >> >> And why bother stripping the result of `byte-compile-eval`? >> > Because it might be the result of evaluating a defun (or defvar or >> > defconst). > >> AFAIK sympos should only appear within the compiler pipeline between the >> "read" and the "emit resulting bytecode". They may be passed to various >> functions and macros along the way, but I can't think of any scenario >> where they'd end up returned by `(byte-compile-)eval`. > >> > This was the situation which gave rise to the bug. > >> Could you give some details about how it played out? >> [ Either here or as a comment in the code. ] > > Michael byte compiled cl-generic.el. This created cl-generic.elc > correctly, but also left uncompiled forms in the function cells of the > symbols defun'd inside an eval-{when,and}-compile. These forms > contained symbols with positions. Hmm... we're talking about stripping the result of `byte-compile-eval`. This function is only used for `eval-when-compile`, not `eval-and-compile`. And nothing in your above description indicates that the sympos appeared in the resulting value of `eval-when-compile` (as opposed to appearing in the slot of functions and variables that were set during the course of the evaluation). >> >> Fundamentally, `eval` should always strip before doing its job. >> > Except when what it's evaluating is a defun, defmacrro, defsubst, etc. >> Why? > Because that evaluated form might later be byte compiled, and the SWPs > will be needed for that. I don't understand the scenario you're thinking of. Are thinking of a case like: - something causes the execution of (eval '(defun foo ...)) - the user types `M-x byte-compile RET foo RET` If so, then: - I don't think we should care about this case because it's extremely rare and fundamentally broken (the symbol's function cell contains a function *value* (i.e. a closure) and not a function's source code, so in general we need `byte-compile--reify-function` which implements a heuristic to go back to something like a source form, which can break in various ways in corner cases). - If we don't strip before calling the `M-x byte-compile` then the code may/will bisbehave because of the presence of the sympos. Stefan