From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Thuna 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:00:23 +0200 Message-ID: <87plr14daw.fsf@gmail.com> References: <87wmla4rqq.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26466"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: 72279@debbugs.gnu.org Cancel-Lock: sha1:Y7Dz8DeYPbyEecdYrUCTYx0Vqr0= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jul 25 19:06:03 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 1sX1ul-0006nR-A9 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 25 Jul 2024 19:06:03 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sX1ud-0006yt-WA; Thu, 25 Jul 2024 13:05:56 -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 1sX1uc-0006yi-LQ for bug-gnu-emacs@gnu.org; Thu, 25 Jul 2024 13:05: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 1sX1uc-0006eG-87 for bug-gnu-emacs@gnu.org; Thu, 25 Jul 2024 13:05:54 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sX1uj-0001ZZ-KK for bug-gnu-emacs@gnu.org; Thu, 25 Jul 2024 13:06:01 -0400 X-Loop: help-debbugs@gnu.org In-Reply-To: <87wmla4rqq.fsf@gmail.com> Resent-From: Thuna Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 25 Jul 2024 17:06: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 X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.17219271195997 (code B ref -1); Thu, 25 Jul 2024 17:06:01 +0000 Original-Received: (at submit) by debbugs.gnu.org; 25 Jul 2024 17:05:19 +0000 Original-Received: from localhost ([127.0.0.1]:37706 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sX1u3-0001Yd-8G for submit@debbugs.gnu.org; Thu, 25 Jul 2024 13:05:19 -0400 Original-Received: from lists.gnu.org ([209.51.188.17]:54178) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sX1u0-0001YT-Tx for submit@debbugs.gnu.org; Thu, 25 Jul 2024 13:05:17 -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 1sX1tt-0006p6-6r for bug-gnu-emacs@gnu.org; Thu, 25 Jul 2024 13:05:09 -0400 Original-Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sX1tr-0006Pr-EW for bug-gnu-emacs@gnu.org; Thu, 25 Jul 2024 13:05:08 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1sX1tn-0005mK-DV for bug-gnu-emacs@gnu.org; Thu, 25 Jul 2024 19:05:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=geb-bug-gnu-emacs@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: 0 X-Spam_score: 0.0 X-Spam_bar: / X-Spam_report: (0.0 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action 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:289323 Archived-At: > > (defun foo () (cl-return "ruh roh")) > > (cl-block nil (foo) (cl-return t)) ; => "ruh ruh" > > yes I agree this is not optimal. We should not even get to evaluating > the second form as we should error on the first (I think your patch > does that). Yes, with my first patch applied, the call to `foo' signals a `no-catch' in (cl-return "ruh roh"). It also emits a warning while macroexpanding. > > 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). > > Have you tried some general use with Emacs compiled with this patch? No, sorry, I didn't. I am currently working on a different thing which changes the definitions for these macros yet again so I proposed this more as an interliminary change so that my later changes don't end up moving where cl-block is calculated AND modify what it does all in one step. > > 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. > > IIUC installing first.patch we keep the same capability of cleaning-up > all un-necessary catches if no approriate throws are found correct? Correct, I have not changed that behavior; if no appropriate `cl-return-from's are found within the body of the `cl-block', then the `cl-block' simply expands into the (macroexpanded, though that can be fixed) body. > > PS. I would also like to have a discussion about a problem that I have > > noticed when trying to build with the second patch, maybe here maybe in > > another bug: Because struct slots are defined using `cl-defsubst', the > > whole body is wrapped in a `cl-block'. The only reason `setf' works > > with such slots is because `cl-block' expands into the body itself when > > there are no `cl-return's. 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. I see two > > possible solutions, either define a (setf catch) or switch to defsubst > > instead of cl-defsubst. > > > >>From 4027c50645260a202e45a2a074dfeb48468394c1 Mon Sep 17 00:00:00 2001 > > From: Thuna > > Date: Wed, 24 Jul 2024 18:41:25 +0200 > > Subject: [PATCH 1/2] Use uninterned tags in cl-block, remove block wrappers > > > > [...] > > > diff --git a/lisp/emacs-lisp/cl-macs.el b/lisp/emacs-lisp/cl-macs.el > > index 2e501005bf7..31b88aec889 100644 > > --- a/lisp/emacs-lisp/cl-macs.el > > +++ b/lisp/emacs-lisp/cl-macs.el > > @@ -889,6 +889,8 @@ cl-etypecase > > > > ;;; Blocks and exits. > > > > +(defvar cl--active-block-names nil) > > I think would be nice to document this variable with how its content is > supposed to look like. This was a variable which already existed; I simply moved it here, though I wouldn't mind documenting it. A decent place to start from is: "A list of the currently active `cl-block' forms. Each element is of the form (NAME VAR FOUNDP) where NAME is the name of the block as it is written in `cl-block' and `cl-return-from', VAR is the tag as it is caught and thrown by `catch' and `throw', and FOUNDP is non-nil if a `cl-return' or `cl-return-from' with the same name was found. This variable should be set such that the modifications can only be seen within the same lexical scope."