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#72279: [PATCH] Non-local exits from outside the lexical scope are caught by cl-block Date: Thu, 25 Jul 2024 19:24:52 -0400 Message-ID: References: <87wmla4rqq.fsf@gmail.com> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24316"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 72279@debbugs.gnu.org To: Thuna Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jul 26 01:26:14 2024 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 1sX7qf-00069c-Uh for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 26 Jul 2024 01:26:14 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sX7qN-0001DV-RX; Thu, 25 Jul 2024 19:25:55 -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 1sX7qM-0001CE-EL for bug-gnu-emacs@gnu.org; Thu, 25 Jul 2024 19:25:54 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sX7qM-0005Ux-6P for bug-gnu-emacs@gnu.org; Thu, 25 Jul 2024 19:25:54 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sX7qT-0005tf-M9 for bug-gnu-emacs@gnu.org; Thu, 25 Jul 2024 19:26:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 25 Jul 2024 23:26:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72279 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 72279-submit@debbugs.gnu.org id=B72279.172194992522609 (code B ref 72279); Thu, 25 Jul 2024 23:26:01 +0000 Original-Received: (at 72279) by debbugs.gnu.org; 25 Jul 2024 23:25:25 +0000 Original-Received: from localhost ([127.0.0.1]:38010 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sX7pt-0005sa-DK for submit@debbugs.gnu.org; Thu, 25 Jul 2024 19:25:25 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:18098) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sX7pq-0005sL-FJ for 72279@debbugs.gnu.org; Thu, 25 Jul 2024 19:25:23 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 7A4A4100043; Thu, 25 Jul 2024 19:25:08 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1721949907; bh=KHK8VKhrsy98dyWJXHiL52YJPC+IPfYyfuK0zzwzZRg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=og9YUMd55ULZ+8KjfbmMunXnlKpTVkCprNPyilkW+UdoXyBqd8VztJYM1ic49XOpx wExNCjHQspx0leafdqF0j4UWiX/r3OUvkIl6mpZNGN5zpXb9qwwkpIOcB+2y1TnZgR q1HjpGLP73IMMYceV2P8F/3IBL20HV4WrP9ySSGByvpXvb2oXhR93iGd4yryYXee5m /vg1KAHyVG9IkchvbORlpjMjgrJ6CoNHC1ytPr30Heq5bLEphIQ58pUclUWMjgSpmA gA3zHN2Hnxwnvg8WslhYuOqqEq+HFhJAIQcZJH0aI688BUn8pY/z01YoiKiVnZg4+s 7iXzleTOi0D/A== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 16FB110002E; Thu, 25 Jul 2024 19:25:07 -0400 (EDT) Original-Received: from asado (dyn.144-85-159-142.dsl.vtx.ch [144.85.159.142]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 245C21202D7; Thu, 25 Jul 2024 19:25:05 -0400 (EDT) In-Reply-To: <87wmla4rqq.fsf@gmail.com> (Thuna's message of "Wed, 24 Jul 2024 19:36:13 +0200") 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:289342 Archived-At: > (defun foo () (cl-return "ruh roh")) > (cl-block nil (foo) (cl-return t)) ; =3D> "ruh ruh" > > The first patch attached attempts to solve this by moving the > functionality of the wrapper compiler macros to the macros themselves > and by using uninterned symbols for the thrown and caught tags, > communicated by the block to the corresponding returns. All the > existing tests seemed to run just fine but I did not do any > comprehensive testing (and there doesn't appear to be any relevant > suites either). BTW, for the second patch a simpler solution is to expand (cl-block A FOO) to (let ((cl--block--A ',(make-symbol "A"))) (catch cl--block--A FOO)) and (cl-return B FOO) to (throw cl--block--B FOO) which will signal an "unknown variable cl--block--B" if a `cl-return` is used outside of its block. But the optimization of `cl-block` when the tag is not used is important, so I don't think it's a good approach. > I do take minor issue with `macroexpand-all'ing all things inside a > block, making debugging via macrostep really annoying, but I don't know > of a better solution, outside of communicating the tag during > evaluation, which would look something like the second patch. I think in theory it's possible to avoid the `macroexpand-all`, but it requires a compiler-macro which (assuming we generate code like I outlined above) will have to recognize those `(catch ...)` where the tag is not used anywhere else. This is because compiler macros are executed by `macroexpand-all` both before and after performing the normal macro expansions, so they do get to see the code after `macroexpand-all`. But it can be slightly tricky to get it right and reliable (because it has to be careful to not mess up the code if it hasn't been macroexpanded yet), and it has to walk the whole code, which means that it needs to copy a fair bit of the code of `macroexpand-all`. > If it were to instead expand into a `catch' - whether because there is > a `cl-return' or because `cl-block' is modified to always expandi into > a `catch' as it is in my second patch - the setf will expand into > (setf catch) which is not defined. Yup, as I said, the "optimization" is important (most of the `cl-block`s are implicit and unused, IME). > I see two possible solutions, either define a (setf catch) or switch > to defsubst instead of cl-defsubst. I don't think we can implement a `setf catch` (tho we could probably come up with a hack which works in practice for those cl-defstruct slots). =F0=9F=99=81 IIRC for the slot accessors `defsubst` would lead to worse code than what we currently get with `cl-defsubst` so it wouldn't be as good, but I believe we could use `define-inline` instead. AFAIC, your first patch looks good to me. Stefan