Received: (at 72279) by debbugs.gnu.org; 4 Mar 2025 02:19:24 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Mar 03 21:19:24 2025 Received: from localhost ([127.0.0.1]:53499 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tpHsS-00013x-77 for submit <at> debbugs.gnu.org; Mon, 03 Mar 2025 21:19:24 -0500 Received: from mail-ed1-x531.google.com ([2a00:1450:4864:20::531]:61701) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <stefankangas@HIDDEN>) id 1tpHsQ-00013e-Up for 72279 <at> debbugs.gnu.org; Mon, 03 Mar 2025 21:19:23 -0500 Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-5e50de0b5easo3815958a12.3 for <72279 <at> debbugs.gnu.org>; Mon, 03 Mar 2025 18:19:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741054757; x=1741659557; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date :mime-version:references:in-reply-to:from:from:to:cc:subject:date :message-id:reply-to; bh=I+LQ+QSUVKtjGhh4TWJ6PYZXOfcxUzRftHHr5sOuU1Y=; b=BXQPilUAvURCpAztb7bajIaV7KoF/uRQuOXqgXzsi67SM+HESmrw4cDmUAXwWk4Tez Pm2w+dKrZCqP8vM69lMCMi31VYnNF3WF6fcAHc6KUw5PqYQMX4Vyx5bHWaNbOJMqkVNf 823+5iLPMOwYeonUjHeRWy2OAEcqXa4lEPAGISoWcxviV5MSlpptjHVE54K5Nkg2SvcK h2hyQ69xr/9zKLhNwIIr40zskPX28bMLWjIaLSMiWPHs0e/KwUvwj6oxrpfIN0R+6SgM 9uZExfuP3RhlvGSgshx8kYpakK0zrsEBYJubSISRzYBwj4WehJt37RpnAtWzWL4Kx4gS YFww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741054757; x=1741659557; h=content-transfer-encoding:cc:to:subject:message-id:date :mime-version:references:in-reply-to:from:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=I+LQ+QSUVKtjGhh4TWJ6PYZXOfcxUzRftHHr5sOuU1Y=; b=tQdKP8Z7tSZo3A9PclJqEK+crmkIieYoyx49V/ZldwRXPPQ5llBA9zfdGoFD51ojUv 6aUHSEIxJDF6Xl4KEBaHLtVar3n7zd4wQSFdwXZRL67NkfgLSZ+qP34eSlHH+p4Y2Zm1 eHlnBvuiWLctqUd8bG8pgDAdFrL1jPpjHzOfcMuizi5v4AsV3Ypxm+DQjZYLLoE3etCc oQ/ZWHsOGn86vJk3xRz0LXO6R8sNvtHzxv2IRF2TsaF5CKy+GN5knSLRLaS0iZEcVNlk PDUUs9ppphTk4Jleta2xZezLunqX5G53Wx6152IWIXQehEEwjeLWEH64ICODlIuDpJ76 9YQw== X-Gm-Message-State: AOJu0Yw4RIJYqxQyZ0uEh525/xNg5hYgDe4n8/9bfVu1WyfxS1PzAw9x jDW7rpc591GiPgyUqzYNTohwOiS1OaXhcq/vWcGd3VCjtOBVImq6mnN9mKOAxKAtJH1gYWBJzvM 34E9mXYPzo5NWCfSPJ9ExPz/2c70= X-Gm-Gg: ASbGnctJb/3CacQLvMfxizRWNsvtSFTnmUXyXD21ElCC/pB5Ef5muT60i4Bq4BwFgJt OQpElwh0YcdL7LxbJbuVrdhnx4tm8eW6/YTrXMgswk/zsq9htpib75xwwkWyp0t/GdWHiJn1c/D qTKMg0wWEv++l/ebvKLhr7q1R85w== X-Google-Smtp-Source: AGHT+IGd0bbSCqtwwcloO1kPM7E5EFcDjoTEsvlxuYBjH5mYiRhGJancvToDbG8tANYwbXAnvvyoNQFYKEwKp1V1wnI= X-Received: by 2002:a05:6402:35cf:b0:5d4:1ac2:277f with SMTP id 4fb4d7f45d1cf-5e4d6ae82camr14961995a12.9.1741054756554; Mon, 03 Mar 2025 18:19:16 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Tue, 4 Mar 2025 02:19:16 +0000 From: Stefan Kangas <stefankangas@HIDDEN> In-Reply-To: <87cyn13rxk.fsf@HIDDEN> References: <87wmla4rqq.fsf@HIDDEN> <jwvikwtjclw.fsf-monnier+emacs@HIDDEN> <87cyn13rxk.fsf@HIDDEN> MIME-Version: 1.0 Date: Tue, 4 Mar 2025 02:19:16 +0000 X-Gm-Features: AQ5f1Jr2HLSaJimzZ0GdQ-BjKQTBAeMiOnEJUV7bII1j6zZWyzGzpaQd0LvceFI Message-ID: <CADwFkmmf=6sJwVDu5Mb-vEW-YL8P+j6XGLNjpzgXvwtEW1mEwQ@HIDDEN> Subject: Re: bug#72279: [PATCH] Non-local exits from outside the lexical scope are caught by cl-block To: Thuna <thuna.cing@HIDDEN> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 72279 Cc: 72279 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Thuna <thuna.cing@HIDDEN> writes: >> 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. > > Aha, yes, that would indeed be simpler. > >> 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 don't have any particular complaints against keeping this > optimization, but for the record would you be able to expand on what > exactly the problem is? It doesn't seem obvious to me that unused > `catch'es would make such a meaningful difference. > >> Yup, as I said, the "optimization" is important (most of the >> `cl-block`s are implicit and unused, IME). > > It would be nice if this would be documented at least in a comment above > `cl-block', even though it's unlikely that it will see too many changes. > >>> 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. > > That sounds like a solution. Defining a hack for `setf catch' seems > like it would lead to a lot of problems down the line, so it would be > better to put it off until someone comes up with a good way to do it > (though I doubt it is possible given dynamic exits). Thuna, I see that you got some comments in this thread. Could you submit an updated patch based on them? Both the ones by Stefan Monnier above, but also comments from Andrea Corallo. Thanks in advance.
bug-gnu-emacs@HIDDEN:bug#72279; Package emacs.
Full text available.Received: (at 72279) by debbugs.gnu.org; 4 Mar 2025 02:18:37 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Mar 03 21:18:37 2025 Received: from localhost ([127.0.0.1]:53495 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tpHrg-000120-Ms for submit <at> debbugs.gnu.org; Mon, 03 Mar 2025 21:18:37 -0500 Received: from mail-ed1-x536.google.com ([2a00:1450:4864:20::536]:44089) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <stefankangas@HIDDEN>) id 1tpHre-00011e-1I for 72279 <at> debbugs.gnu.org; Mon, 03 Mar 2025 21:18:34 -0500 Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-5e095d47a25so9147559a12.0 for <72279 <at> debbugs.gnu.org>; Mon, 03 Mar 2025 18:18:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741054708; x=1741659508; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date:message-id:reply-to; bh=8ltzM5gcWIlL2+ozWmpkSC9KtOoV0eqayphTyTsAb/U=; b=i1gjqpkfGDdEs/5Ko3SPuL+r13TyiCWJQ0wvM9dpAE3ffDPqAV+VSWETi5Yugwm8t0 G6tJe8wgd3/I11NNgVgsmfGiBNVKwD+KdlJcw0ivDfDIIYUzD1KZijTvuSxAEVI/nxkq fynerXe+yv3x0VkjWOn8W5H+8E+8MBhqsBOvF4pQSB01EiB/ctOJSaQoStRzBOLkyphh rgl7Lz2gdN4sWKmbn6jaAYTuKOcg/Ko/NrjSQMK8D6zLdezZsorEw1m+Cdu4K4GF93SP eLZ4MnUpLABgwc2NpNSfBtlEq4FC3CztV25Ok4SMpcsFPjQmg4j6aKZ1yLslH6c2aLGA UAxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741054708; x=1741659508; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=8ltzM5gcWIlL2+ozWmpkSC9KtOoV0eqayphTyTsAb/U=; b=bfROD6F/5BXBl9qBQdMkqyx8xscbOfWwAZrtwI1mE/iC5YTkfa+qtweb1oQ7rLE0FN fp60vX4W6ACPYX48Ng6sCW5fxbGSW8plcYmiZbWfUKywhLULYSOIsb3daqOyxNNuUKZE NimK7H6v3VSJXI+tqRgn+41pF0S6T/ak3aQOJcwd/15lXnS2scUtlc6ihHmwqcn08RNz CkG17/NHXWmhCp061K+96k19OSlOFvQfaNjmrwhzhtg/j7k7eyejV8rbhGprdq4/Gwcz JGfCNNI9/Np5jvsdbt7+JeWQUrjUH2zH9mUKLr4N3tG0L3Ayd0ScgDRaQp0S56Fi2rzH tJ4Q== X-Forwarded-Encrypted: i=1; AJvYcCUkZRTG2Vk85fdIRjomUsFp0TGsMXaz2rQ/m4v4L7hb9isHXbvpC8dm2iGgtRLYLTUwLojVvA==@debbugs.gnu.org X-Gm-Message-State: AOJu0YxiEBvsERY+MrniBDafZ7DNBFCY+AxH1FYmlOQ8m8N4AUBai+8i UIm8c+gvlv23jFfPpNRD5TptUZlSi1+JbJOYU1ytlkiqRm69saaWMXfAgeSO81jDFjKUUCz4Jgf Pr3OgmRTq+wvw3KazpkcShEC3d94= X-Gm-Gg: ASbGncuzigjr/ho3RHJiWFSL0jOLocAnnkujXBwyYvqGZibYWz78zPcf/fsjnTtCrrT HpWHlghMUJ5mq8vyQ1ZVRV1TXZhuKM+ESGebkO7yxy52IKeMabuLoeYifo9yDhgYGCnoMiGH0bM RuWz9LSxDFjAQACV2kfjbTt0GwQg== X-Google-Smtp-Source: AGHT+IGt1StsDKnlVF+NPc64PmFB6pmMHong+qic4HaCPdz5n7IMUl3OCNMVx8v+d8Zd53+BlSoozE18oqcZ7IAxT4o= X-Received: by 2002:a05:6402:348a:b0:5dc:929a:a726 with SMTP id 4fb4d7f45d1cf-5e4d6b70f43mr15843186a12.26.1741054707687; Mon, 03 Mar 2025 18:18:27 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Mon, 3 Mar 2025 18:18:27 -0800 From: Stefan Kangas <stefankangas@HIDDEN> In-Reply-To: <yp1a5i4ppod.fsf@HIDDEN> References: <87wmla4rqq.fsf@HIDDEN> <jwvikwtjclw.fsf-monnier+emacs@HIDDEN> <87cyn13rxk.fsf@HIDDEN> <yp1a5i4ppod.fsf@HIDDEN> MIME-Version: 1.0 Date: Mon, 3 Mar 2025 18:18:27 -0800 X-Gm-Features: AQ5f1JrIJQomH8ReQrEoc5udAtn0AjKWt_Py8afXKIb7IkkCatM8OBRER9vmYXo Message-ID: <CADwFkmmzMQRARXiPADR=b-OdFTtd_LWXj6+mpheOxWX4y8nSEQ@HIDDEN> Subject: Re: bug#72279: [PATCH] Non-local exits from outside the lexical scope are caught by cl-block To: Andrea Corallo <acorallo@HIDDEN> Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 72279 Cc: 72279 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, Thuna <thuna.cing@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Andrea Corallo <acorallo@HIDDEN> writes: > Unused catches are a problem because they bloat bytecode unnecessary, > also they prevent a number of optimizations in the native compiler as > well. Essentially every time you have a landing pad like a catch you > cannot make assumptions on where you are landing from and what's the > state of your machine. > > It's very important we keep on removing unnecessary catches, that's why > I was asking in my previous mail. What constitutes an "unnecessary catch"? Just unused ones, or all catches?
bug-gnu-emacs@HIDDEN:bug#72279; Package emacs.
Full text available.Received: (at 72279) by debbugs.gnu.org; 26 Jul 2024 07:40:03 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jul 26 03:40:03 2024 Received: from localhost ([127.0.0.1]:38730 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sXFYY-0006ij-FD for submit <at> debbugs.gnu.org; Fri, 26 Jul 2024 03:40:03 -0400 Received: from eggs.gnu.org ([209.51.188.92]:56986) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <acorallo@HIDDEN>) id 1sXFYW-0006hp-G1 for 72279 <at> debbugs.gnu.org; Fri, 26 Jul 2024 03:40:01 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <acorallo@HIDDEN>) id 1sXFYI-0008Cq-QP; Fri, 26 Jul 2024 03:39:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=RxnqBH2GAd0GMgfK9byo/xeO43nUtG6fDgEEd+DFBQs=; b=owXmsIWiabUpnJBpciLy oqTHEkki2t6qjRQWSFuArR9ASyR3rwPLnXjUYChUmIqyxC53y1CDkebKKwjiSrvuWa5GCnpMYVTfB yjb2hBpWWSfHME8hqiuuGepp99/he3uUX/ywVAtxAU1TPA7yS8mCOkzGNAxyyiMJ3/m1aCnizHRnR +2Axd4zCJA6D3hv+R8XYZt6wyBeuR6Uf6brmGqzzeVFHV5hQaYi2UUBAbkCij6RLsupd7OfEhfHp/ A2eOq3MkGA7Z5Gd0fwtWqUuq1my3fMxGIYJZazoRK7kvekRDp9CHZni6zpKgWldBAhPtPtEC94Wp3 aYc5EVpgkLg3kw==; Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from <acorallo@HIDDEN>) id 1sXFYI-000885-Ib; Fri, 26 Jul 2024 03:39:46 -0400 From: Andrea Corallo <acorallo@HIDDEN> To: Thuna <thuna.cing@HIDDEN> Subject: Re: bug#72279: [PATCH] Non-local exits from outside the lexical scope are caught by cl-block In-Reply-To: <87cyn13rxk.fsf@HIDDEN> (Thuna's message of "Fri, 26 Jul 2024 02:41:59 +0200") References: <87wmla4rqq.fsf@HIDDEN> <jwvikwtjclw.fsf-monnier+emacs@HIDDEN> <87cyn13rxk.fsf@HIDDEN> Date: Fri, 26 Jul 2024 03:39:46 -0400 Message-ID: <yp1a5i4ppod.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 72279 Cc: 72279 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) Thuna <thuna.cing@HIDDEN> writes: >> 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. > > Aha, yes, that would indeed be simpler. > >> 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 don't have any particular complaints against keeping this > optimization, but for the record would you be able to expand on what > exactly the problem is? It doesn't seem obvious to me that unused > `catch'es would make such a meaningful difference. Unused catches are a problem because they bloat bytecode unnecessary, also they prevent a number of optimizations in the native compiler as well. Essentially every time you have a landing pad like a catch you cannot make assumptions on where you are landing from and what's the state of your machine. It's very important we keep on removing unnecessary catches, that's why I was asking in my previous mail. Andrea
bug-gnu-emacs@HIDDEN:bug#72279; Package emacs.
Full text available.Received: (at submit) by debbugs.gnu.org; 26 Jul 2024 00:43:13 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jul 25 20:43:13 2024 Received: from localhost ([127.0.0.1]:38032 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sX93A-0007mo-OS for submit <at> debbugs.gnu.org; Thu, 25 Jul 2024 20:43:13 -0400 Received: from lists.gnu.org ([209.51.188.17]:42382) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <geb-bug-gnu-emacs@HIDDEN>) id 1sX936-0007md-Uo for submit <at> debbugs.gnu.org; Thu, 25 Jul 2024 20:43:11 -0400 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 <geb-bug-gnu-emacs@HIDDEN>) id 1sX92y-0005Id-PS for bug-gnu-emacs@HIDDEN; Thu, 25 Jul 2024 20:43:00 -0400 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 <geb-bug-gnu-emacs@HIDDEN>) id 1sX92x-0003Ik-8c for bug-gnu-emacs@HIDDEN; Thu, 25 Jul 2024 20:43:00 -0400 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from <geb-bug-gnu-emacs@HIDDEN>) id 1sX92v-0006nd-5k for bug-gnu-emacs@HIDDEN; Fri, 26 Jul 2024 02:42:57 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: bug-gnu-emacs@HIDDEN From: Thuna <thuna.cing@HIDDEN> Subject: Re: bug#72279: [PATCH] Non-local exits from outside the lexical scope are caught by cl-block Date: Fri, 26 Jul 2024 02:41:59 +0200 Message-ID: <87cyn13rxk.fsf@HIDDEN> References: <87wmla4rqq.fsf@HIDDEN> <jwvikwtjclw.fsf-monnier+emacs@HIDDEN> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:JnviE6VGNkdy2V1LqFxql4Hz1u4= Received-SPF: pass client-ip=116.202.254.214; envelope-from=geb-bug-gnu-emacs@HIDDEN; 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-Spam-Score: -0.4 (/) X-Debbugs-Envelope-To: submit Cc: Stefan Monnier <monnier@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.4 (-) > 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. Aha, yes, that would indeed be simpler. > 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 don't have any particular complaints against keeping this optimization, but for the record would you be able to expand on what exactly the problem is? It doesn't seem obvious to me that unused `catch'es would make such a meaningful difference. > Yup, as I said, the "optimization" is important (most of the > `cl-block`s are implicit and unused, IME). It would be nice if this would be documented at least in a comment above `cl-block', even though it's unlikely that it will see too many changes. >> 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). 🙁 > > 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. That sounds like a solution. Defining a hack for `setf catch' seems like it would lead to a lot of problems down the line, so it would be better to put it off until someone comes up with a good way to do it (though I doubt it is possible given dynamic exits).
bug-gnu-emacs@HIDDEN:bug#72279; Package emacs.
Full text available.
Received: (at 72279) by debbugs.gnu.org; 25 Jul 2024 23:25:25 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jul 25 19:25:25 2024
Received: from localhost ([127.0.0.1]:38010 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1sX7pt-0005sa-DK
for submit <at> debbugs.gnu.org; Thu, 25 Jul 2024 19:25:25 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:18098)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1sX7pq-0005sL-FJ
for 72279 <at> debbugs.gnu.org; Thu, 25 Jul 2024 19:25:23 -0400
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==
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)
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)
From: Stefan Monnier <monnier@HIDDEN>
To: Thuna <thuna.cing@HIDDEN>
Subject: Re: bug#72279: [PATCH] Non-local exits from outside the lexical
scope are caught by cl-block
In-Reply-To: <87wmla4rqq.fsf@HIDDEN> (Thuna's message of "Wed, 24 Jul 2024
19:36:13 +0200")
Message-ID: <jwvikwtjclw.fsf-monnier+emacs@HIDDEN>
References: <87wmla4rqq.fsf@HIDDEN>
Date: Thu, 25 Jul 2024 19:24:52 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 72279
Cc: 72279 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> (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 <VAR> ...)` 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
bug-gnu-emacs@HIDDEN:bug#72279; Package emacs.
Full text available.Received: (at submit) by debbugs.gnu.org; 25 Jul 2024 17:23:04 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jul 25 13:23:04 2024 Received: from localhost ([127.0.0.1]:37713 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sX2BE-0001zJ-8i for submit <at> debbugs.gnu.org; Thu, 25 Jul 2024 13:23:04 -0400 Received: from lists.gnu.org ([209.51.188.17]:42032) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <geb-bug-gnu-emacs@HIDDEN>) id 1sX2BC-0001yz-5q for submit <at> debbugs.gnu.org; Thu, 25 Jul 2024 13:23:02 -0400 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 <geb-bug-gnu-emacs@HIDDEN>) id 1sX2B4-0000Xo-Dg for bug-gnu-emacs@HIDDEN; Thu, 25 Jul 2024 13:22:54 -0400 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 <geb-bug-gnu-emacs@HIDDEN>) id 1sX2B3-00038G-4T for bug-gnu-emacs@HIDDEN; Thu, 25 Jul 2024 13:22:54 -0400 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from <geb-bug-gnu-emacs@HIDDEN>) id 1sX2Az-0002wX-45 for bug-gnu-emacs@HIDDEN; Thu, 25 Jul 2024 19:22:49 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: bug-gnu-emacs@HIDDEN From: Thuna <thuna.cing@HIDDEN> Subject: Re: bug#72279: FSF copyright assignment Date: Thu, 25 Jul 2024 19:22:43 +0200 Message-ID: <87ikwt4c9o.fsf_-_@HIDDEN> References: <87wmla4rqq.fsf@HIDDEN> <yp1ikwtpkov.fsf@HIDDEN> Mime-Version: 1.0 Content-Type: text/plain User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:zB14WZuC1zXREJi/xxmGnrKgzwk= Received-SPF: pass client-ip=116.202.254.214; envelope-from=geb-bug-gnu-emacs@HIDDEN; 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-Spam-Score: -0.4 (/) X-Debbugs-Envelope-To: submit Cc: Craig Topham via RT <copyright-clerk@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.4 (-) > Also I don't see you in the copyright file. Would you like to do the > FSF paperwork in order to be able to contribute non trivial patches to > Emacs? I have applied for an assignment a bit over two years ago now. Unfortunately, the problem which stopped it from going through still persists to date, namely that the university in which I am a student (which is based in EU if that helps) refuses to sign the copyright disclaimer - or more specifically that I cannot get a response from the legal department to begin with. Craig has previously reached out on my behalf as well, but as far as I am aware they have similarly not had much success. The only way forward that I can see is a. do not consider them a possibly claimant to my work an forgo the copyright disclaimer or b. wait a year after which I will (hopefully) graduate and hope that the university I go to for my post-grad is more open to communication. I do not believe that b. is bound to see much success, but I do also do not know if a. is a viable option for the FSF.
bug-gnu-emacs@HIDDEN:bug#72279; Package emacs.
Full text available.Received: (at submit) by debbugs.gnu.org; 25 Jul 2024 17:05:19 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jul 25 13:05:19 2024 Received: from localhost ([127.0.0.1]:37706 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sX1u3-0001Yd-8G for submit <at> debbugs.gnu.org; Thu, 25 Jul 2024 13:05:19 -0400 Received: from lists.gnu.org ([209.51.188.17]:54178) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <geb-bug-gnu-emacs@HIDDEN>) id 1sX1u0-0001YT-Tx for submit <at> debbugs.gnu.org; Thu, 25 Jul 2024 13:05:17 -0400 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 <geb-bug-gnu-emacs@HIDDEN>) id 1sX1tt-0006p6-6r for bug-gnu-emacs@HIDDEN; Thu, 25 Jul 2024 13:05:09 -0400 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 <geb-bug-gnu-emacs@HIDDEN>) id 1sX1tr-0006Pr-EW for bug-gnu-emacs@HIDDEN; Thu, 25 Jul 2024 13:05:08 -0400 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from <geb-bug-gnu-emacs@HIDDEN>) id 1sX1tn-0005mK-DV for bug-gnu-emacs@HIDDEN; Thu, 25 Jul 2024 19:05:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: bug-gnu-emacs@HIDDEN From: Thuna <thuna.cing@HIDDEN> Subject: Re: 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@HIDDEN> References: <87wmla4rqq.fsf@HIDDEN> <yp1ikwtpkov.fsf@HIDDEN> Mime-Version: 1.0 Content-Type: text/plain User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:Y7Dz8DeYPbyEecdYrUCTYx0Vqr0= Received-SPF: pass client-ip=116.202.254.214; envelope-from=geb-bug-gnu-emacs@HIDDEN; 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-Spam-Score: -0.4 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.4 (-) > > (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 <thuna.cing@HIDDEN> > > 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."
bug-gnu-emacs@HIDDEN:bug#72279; Package emacs.
Full text available.Received: (at 72279) by debbugs.gnu.org; 25 Jul 2024 15:15:30 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jul 25 11:15:30 2024 Received: from localhost ([127.0.0.1]:37584 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sX0Bl-00070d-Ut for submit <at> debbugs.gnu.org; Thu, 25 Jul 2024 11:15:30 -0400 Received: from eggs.gnu.org ([209.51.188.92]:48766) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <acorallo@HIDDEN>) id 1sX0Bj-00070Q-3s for 72279 <at> debbugs.gnu.org; Thu, 25 Jul 2024 11:15:29 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <acorallo@HIDDEN>) id 1sX0BV-0000JR-Mo; Thu, 25 Jul 2024 11:15:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=11u8DIYXQUuduuukfVa9Dl+jjZi0pztrZ0Ken5BG/3k=; b=UZ34J+2knSoRI+WrwQiV HWWtds1fzoC1cTmpUpyWdhAbnCbzNawolgl1/H2eKCURt7A3RO2cADJOob86lP1kX1bEFc2yUoZ46 Oya37fSKprJwAVSwKFLgfJWqrEmo3TFDbepZz7rHJIRX4G6mIn7Vr9YNyVJAQuZTbU+RjlTvlPud3 /vASfSLCj2BY46QsaxF2PGngYLrUppmGEIg7IVEyI5rgW8EqiVE67UduimO6mPDBPwwiuoKAcpjIg GLROJta6qH//LspQtAn8/nHpCquavfg4oTUT9MjAMJwLlCKWRU+EYOeTbWf3MurgAPAVozydH1n2l qjUIqTgrQ8AEWw==; Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from <acorallo@HIDDEN>) id 1sX0BU-0007Qz-Sp; Thu, 25 Jul 2024 11:15:13 -0400 From: Andrea Corallo <acorallo@HIDDEN> To: Thuna <thuna.cing@HIDDEN> Subject: Re: bug#72279: [PATCH] Non-local exits from outside the lexical scope are caught by cl-block In-Reply-To: <87wmla4rqq.fsf@HIDDEN> (Thuna's message of "Wed, 24 Jul 2024 19:36:13 +0200") References: <87wmla4rqq.fsf@HIDDEN> Date: Thu, 25 Jul 2024 11:15:12 -0400 Message-ID: <yp1ikwtpkov.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 72279 Cc: 72279 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) Thuna <thuna.cing@HIDDEN> writes: > Since the thrown and caught tags in `cl-block' and `cl-return-from' are > interned and deterministic, a `cl-block' catches `cl-return-from's with > the corresponding names even from outside the current lexical scope. > > The only mechanism in place to stop this is the compiler macro around > cl--block-catch, which removes the block if no approriate returns are > found, however not only is this bound to break if the compiler macro > fails to expand, a valid exit is all that is needed to work around this. > > (defun foo () (cl-return "ruh roh")) > (cl-block nil (foo) (cl-return t)) ; => "ruh ruh" Hi Thuna, 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). > 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? > 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? > 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 <thuna.cing@HIDDEN> > 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. I'm Ccing Stefan maybe he has opinions on these patches. Also I don't see you in the copyright file. Would you like to do the FSF paperwork in order to be able to contribute non trivial patches to Emacs? Thanks! Andrea
bug-gnu-emacs@HIDDEN:bug#72279; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 24 Jul 2024 17:36:32 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jul 24 13:36:32 2024
Received: from localhost ([127.0.0.1]:34424 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1sWfui-0006Ch-25
for submit <at> debbugs.gnu.org; Wed, 24 Jul 2024 13:36:32 -0400
Received: from lists.gnu.org ([209.51.188.17]:46676)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <thuna.cing@HIDDEN>) id 1sWfud-0006CY-Vq
for submit <at> debbugs.gnu.org; Wed, 24 Jul 2024 13:36:30 -0400
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 <thuna.cing@HIDDEN>)
id 1sWfuX-0003z4-E3
for bug-gnu-emacs@HIDDEN; Wed, 24 Jul 2024 13:36:21 -0400
Received: from mail-wm1-x330.google.com ([2a00:1450:4864:20::330])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.90_1) (envelope-from <thuna.cing@HIDDEN>)
id 1sWfuV-0008I0-2j
for bug-gnu-emacs@HIDDEN; Wed, 24 Jul 2024 13:36:21 -0400
Received: by mail-wm1-x330.google.com with SMTP id
5b1f17b1804b1-42122ac2f38so572955e9.1
for <bug-gnu-emacs@HIDDEN>; Wed, 24 Jul 2024 10:36:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1721842577; x=1722447377; darn=gnu.org;
h=mime-version:message-id:date:subject:to:from:from:to:cc:subject
:date:message-id:reply-to;
bh=OdmZLlodoPT8xJxrWFikPqCG3MLjNxoISF7f6Elkp0Y=;
b=e6yb6N0ZXyCD3ItPg6o2QwrgEPF/fG16XrZplJj4KkXtEehssrNaaNn9+VaQbkcWED
LMwwzzcP+oPQ06x+Kgmw5AA3mDNI1cZiGk1NAIuxGDIQKCVEI6llACCoLI5U2XDzWgKl
0dtiBhDafMkVj6JShy4i08iEnpeYAIPHyxJBTTbHnlJZG6+Ft2JWkce5sXSeh+i/nU7Q
xHT+K5NKufA69xFvJlj3wwfMK6Aco5qzl4uIgfRiyA4wE4MA/9CWcm0k5M92tJGdo09d
NqPMTuvBDoGeo1wNHBDsXjC2LXeR7oCKhlEQb08NozMM/ItMg1reobvvSwzcPGOfnpAY
P4mQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1721842577; x=1722447377;
h=mime-version:message-id:date:subject:to:from:x-gm-message-state
:from:to:cc:subject:date:message-id:reply-to;
bh=OdmZLlodoPT8xJxrWFikPqCG3MLjNxoISF7f6Elkp0Y=;
b=JGhiZHlGkjUcCZqyo/f5Lvc5dNiuZ+TeJSH3YbITdsSQbW4omn6wSBUZIpmfMTmkzg
3nSWhcTZqcwab84PW7us0gSJJay9yxtvKFp87lShinYFDcnfGsz+FGJqSFZaG+CGZ24C
0paFORMrQFY1Q2qk6/ZY3hFtpnXDAvQ19w00Twjs2O8gSh6buqo8mj4IQKhGmi4JU5ty
4yOuQONWHhloUpRk5xLNux+klXY0PaFdVjuevHu/3XL/h3ktT1/Fw4CajVxZ6yRLUg8R
Nw5vBxaXDRJGiLr4gIsZffm3FzIFehnqbyL10z3D3Q5at0+1clcTHsVQozQx5K/Z++ZW
oWUg==
X-Gm-Message-State: AOJu0YyCqtL7RpEUsKJ9sFilpQSn4i7CmsBSNEDUPz9rdKt+h++DK4Gb
XcQ2F5FXxlipl//DGR8ZJY9TIOZc7SGv+1pwr8NXaZx794cNdxL0bGjvZg==
X-Google-Smtp-Source: AGHT+IEPCq5/K596gfGNKgfnZJbMjQKNulDRlxsFj/TkqmnruSOmWXTk07yvKV3AtWhj4VZ1+kpvZg==
X-Received: by 2002:a05:600c:3b86:b0:424:895c:b84b with SMTP id
5b1f17b1804b1-42803adc036mr2958515e9.4.1721842576292;
Wed, 24 Jul 2024 10:36:16 -0700 (PDT)
Received: from thuna-lis3 ([85.106.105.81]) by smtp.gmail.com with ESMTPSA id
5b1f17b1804b1-427f9359710sm40445735e9.1.2024.07.24.10.36.14
for <bug-gnu-emacs@HIDDEN>
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Wed, 24 Jul 2024 10:36:15 -0700 (PDT)
From: Thuna <thuna.cing@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: [PATCH] Non-local exits from outside the lexical scope are caught
by cl-block
Date: Wed, 24 Jul 2024 19:36:13 +0200
Message-ID: <87wmla4rqq.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
Received-SPF: pass client-ip=2a00:1450:4864:20::330;
envelope-from=thuna.cing@HIDDEN; helo=mail-wm1-x330.google.com
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.3 (-)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)
--=-=-=
Content-Type: text/plain
Since the thrown and caught tags in `cl-block' and `cl-return-from' are
interned and deterministic, a `cl-block' catches `cl-return-from's with
the corresponding names even from outside the current lexical scope.
The only mechanism in place to stop this is the compiler macro around
cl--block-catch, which removes the block if no approriate returns are
found, however not only is this bound to break if the compiler macro
fails to expand, a valid exit is all that is needed to work around this.
(defun foo () (cl-return "ruh roh"))
(cl-block nil (foo) (cl-return t)) ; => "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).
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.
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.
--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment;
filename=0001-Use-uninterned-tags-in-cl-block-remove-block-wrapper.patch
Content-Description: The first patch
From 4027c50645260a202e45a2a074dfeb48468394c1 Mon Sep 17 00:00:00 2001
From: Thuna <thuna.cing@HIDDEN>
Date: Wed, 24 Jul 2024 18:41:25 +0200
Subject: [PATCH 1/2] Use uninterned tags in cl-block, remove block wrappers
* lisp/emacs-lisp/cl-macs.el (cl-block): Macroexpand the body with its
tag in cl--active-block-names, if any `cl-return-from' or `cl-return'
with the appropriate name is found then have them throw the communicated
tag, otherwise simply return the body itself.
(cl-return-from): If a block was established with the appropriate name,
use throw using its tag. Otherwise use a newly created tag which is
guaranteed to signal a no-catch and emit a macroexpand warning.
(cl--block-wrapper cl--block-throw): Remove compiler macros.
* lisp/emacs-lisp/cl-lib.el (cl--block-wrapper cl--block-throw): Remove
aliases. Remove the now empty "Blocks and exits" section.
---
lisp/emacs-lisp/cl-lib.el | 6 ------
lisp/emacs-lisp/cl-macs.el | 44 ++++++++++++++------------------------
2 files changed, 16 insertions(+), 34 deletions(-)
diff --git a/lisp/emacs-lisp/cl-lib.el b/lisp/emacs-lisp/cl-lib.el
index 108dcd31f48..56c05aa0db3 100644
--- a/lisp/emacs-lisp/cl-lib.el
+++ b/lisp/emacs-lisp/cl-lib.el
@@ -183,12 +183,6 @@ substring
,getter ,start ,end ,v))
,v))))))))
-;;; Blocks and exits.
-
-(defalias 'cl--block-wrapper 'identity)
-(defalias 'cl--block-throw 'throw)
-
-
;;; Multiple values.
;; True multiple values are not supported, or even
;; simulated. Instead, cl-multiple-value-bind and friends simply expect
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)
+
;;;###autoload
(defmacro cl-block (name &rest body)
"Define a lexically-scoped block named NAME.
@@ -900,10 +902,12 @@ cl-block
references may appear inside macro expansions, but not inside functions
called from BODY."
(declare (indent 1) (debug (symbolp body)))
- (if (cl--safe-expr-p `(progn ,@body)) `(progn ,@body)
- `(cl--block-wrapper
- (catch ',(intern (format "--cl-block-%s--" name))
- ,@body))))
+ (let* ((cl-entry (list name (make-symbol (symbol-name name)) nil))
+ (cl--active-block-names (cons cl-entry cl--active-block-names))
+ (body (macroexpand-all (macroexp-progn body) macroexpand-all-environment)))
+ (if (nth 2 cl-entry) ; a corresponding cl-return was found
+ `(catch ',(nth 1 cl-entry) ,@(macroexp-unprogn body))
+ body)))
;;;###autoload
(defmacro cl-return (&optional result)
@@ -920,9 +924,14 @@ cl-return-from
This is compatible with Common Lisp, but note that `defun' and
`defmacro' do not create implicit blocks as they do in Common Lisp."
(declare (indent 1) (debug (symbolp &optional form)))
- (let ((name2 (intern (format "--cl-block-%s--" name))))
- `(cl--block-throw ',name2 ,result)))
-
+ (let ((cl-entry (assq name cl--active-block-names)))
+ (if (not cl-entry)
+ (macroexp-warn-and-return
+ (format "`cl-return-from' %S encountered with no corresponding `cl-block'" name)
+ ;; This will always be a no-catch
+ `(throw ',(make-symbol (symbol-name name)) ,result))
+ (setf (nth 2 cl-entry) t)
+ `(throw ',(nth 1 cl-entry) ,result))))
;;; The "cl-loop" macro.
@@ -3635,27 +3644,6 @@ cl-compiler-macroexpand
(not (eq form (setq form (apply handler form (cdr form))))))))
form)
-;; Optimize away unused block-wrappers.
-
-(defvar cl--active-block-names nil)
-
-(cl-define-compiler-macro cl--block-wrapper (cl-form)
- (let* ((cl-entry (cons (nth 1 (nth 1 cl-form)) nil))
- (cl--active-block-names (cons cl-entry cl--active-block-names))
- (cl-body (macroexpand-all ;Performs compiler-macro expansions.
- (macroexp-progn (cddr cl-form))
- macroexpand-all-environment)))
- ;; FIXME: To avoid re-applying macroexpand-all, we'd like to be able
- ;; to indicate that this return value is already fully expanded.
- (if (cdr cl-entry)
- `(catch ,(nth 1 cl-form) ,@(macroexp-unprogn cl-body))
- cl-body)))
-
-(cl-define-compiler-macro cl--block-throw (cl-tag cl-value)
- (let ((cl-found (assq (nth 1 cl-tag) cl--active-block-names)))
- (if cl-found (setcdr cl-found t)))
- `(throw ,cl-tag ,cl-value))
-
;; Compile-time optimizations for some functions defined in this package.
(defun cl--compiler-macro-member (form a list &rest keys)
--
2.44.2
--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment;
filename=0002-Avoid-macroexpanding-in-cl-block.patch
Content-Description: The second patch
From 8181df542b1f57365b0a2a503b245884cb8da94d Mon Sep 17 00:00:00 2001
From: Thuna <thuna.cing@HIDDEN>
Date: Wed, 24 Jul 2024 18:47:40 +0200
Subject: [PATCH 2/2] Avoid macroexpanding in cl-block
* lisp/emacs-lisp/cl-macs.el (cl-block): Communicate the tag during
evaluation via a lexical variable using the symbol kept in
`cl--active-block-names-var'.
(cl-return-from): Obtain the tag to throw by looking at the lexical
variable represented by the symbol kept in `cl--active-block-names-var'.
(cl--active-block-names): Remove variable.
(cl--active-block-names-var): Add variable.
---
lisp/emacs-lisp/cl-macs.el | 26 +++++++++++---------------
1 file changed, 11 insertions(+), 15 deletions(-)
diff --git a/lisp/emacs-lisp/cl-macs.el b/lisp/emacs-lisp/cl-macs.el
index 31b88aec889..07fc8ba7e73 100644
--- a/lisp/emacs-lisp/cl-macs.el
+++ b/lisp/emacs-lisp/cl-macs.el
@@ -889,7 +889,7 @@ cl-etypecase
;;; Blocks and exits.
-(defvar cl--active-block-names nil)
+(defvar cl--active-block-names-var '#:cl--active-block-names)
;;;###autoload
(defmacro cl-block (name &rest body)
@@ -902,12 +902,12 @@ cl-block
references may appear inside macro expansions, but not inside functions
called from BODY."
(declare (indent 1) (debug (symbolp body)))
- (let* ((cl-entry (list name (make-symbol (symbol-name name)) nil))
- (cl--active-block-names (cons cl-entry cl--active-block-names))
- (body (macroexpand-all (macroexp-progn body) macroexpand-all-environment)))
- (if (nth 2 cl-entry) ; a corresponding cl-return was found
- `(catch ',(nth 1 cl-entry) ,@(macroexp-unprogn body))
- body)))
+ (let ((block-name (make-symbol (symbol-name name))))
+ `(let ((,cl--active-block-names-var
+ (cl-acons ',name ',block-name
+ (ignore-error void-variable
+ ,cl--active-block-names-var))))
+ (catch ',block-name ,@body))))
;;;###autoload
(defmacro cl-return (&optional result)
@@ -924,14 +924,10 @@ cl-return-from
This is compatible with Common Lisp, but note that `defun' and
`defmacro' do not create implicit blocks as they do in Common Lisp."
(declare (indent 1) (debug (symbolp &optional form)))
- (let ((cl-entry (assq name cl--active-block-names)))
- (if (not cl-entry)
- (macroexp-warn-and-return
- (format "`cl-return-from' %S encountered with no corresponding `cl-block'" name)
- ;; This will always be a no-catch
- `(throw ',(make-symbol (symbol-name name)) ,result))
- (setf (nth 2 cl-entry) t)
- `(throw ',(nth 1 cl-entry) ,result))))
+ `(let ((block-name
+ (cdr (assq ',name (ignore-error void-variable
+ ,cl--active-block-names-var)))))
+ (throw (or block-name ',(make-symbol (symbol-name name))) ,result)))
;;; The "cl-loop" macro.
--
2.44.2
--=-=-=--
Thuna <thuna.cing@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#72279; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.