From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 25 03:38:21 2025 Received: (at submit) by debbugs.gnu.org; 25 Apr 2025 07:38:21 +0000 Received: from localhost ([127.0.0.1]:46601 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u8Ddc-0000bx-Th for submit@debbugs.gnu.org; Fri, 25 Apr 2025 03:38:21 -0400 Received: from lists.gnu.org ([2001:470:142::17]:39580) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1u8DdZ-0000bT-5l for submit@debbugs.gnu.org; Fri, 25 Apr 2025 03:38:19 -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 ) id 1u8DdR-0003Yg-W0 for bug-gnu-emacs@gnu.org; Fri, 25 Apr 2025 03:38:11 -0400 Received: from smtp-65.smtpout.orange.fr ([80.12.242.65] helo=smtp.smtpout.orange.fr) by eggs.gnu.org with esmtps (TLS1.2:RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1u8DdO-0003S3-Ue for bug-gnu-emacs@gnu.org; Fri, 25 Apr 2025 03:38:09 -0400 Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA id 8DdGuDVtA3t2y8DdJuebg3; Fri, 25 Apr 2025 09:38:02 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1745566682; bh=+xEYLRTMjM1OrLvZvRwLwjijlK6LzfdhYItoZtri37Q=; h=Message-ID:Date:MIME-Version:To:From:Subject; b=hAnbyWs+7IrEL8Rbvw0fPI7j+K7YllECDe6kme+jTHNW7MdOxTWcoYMZreBn72Vel rgQhsVTiRn0EYXYFe+65/iOde8adOP2cS7UnzFqkXYwl6847P8sduDZPyAzeHtGk73 DB5HzgSBKjFGxnthB1TZ2e497wxJCc5SyqgKzk8mH6ZcmEaE7gTmSbzcmENau1EzPm Z6EtBOjpA8UmV2eEyJduGjtiD8CldwnO1JgqB5ifpVxRTvlzldGj2AFssMW3zJjTwC ezLHCtEg/SsaJEj0dWIJKjaZ6GQVu2U5N0dLnYbV34smF67NxNjDFs30mJ+V9GJ1FD Vf3yj8vbZrJHg== X-ME-Helo: [192.168.1.21] X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI= X-ME-Date: Fri, 25 Apr 2025 09:38:02 +0200 X-ME-IP: 90.112.40.65 Content-Type: multipart/mixed; boundary="------------5iany5QbJB0F3OJaRQo1nd4S" Message-ID: <5951a2a7-12b2-4ac0-a4e9-a874ff4dd25a@orange.fr> Date: Fri, 25 Apr 2025 09:37:58 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: fr, en-US To: bug-gnu-emacs@gnu.org From: David Ponce Subject: 31.0.50; bug in `cl-eval-when` with symbols with positions Received-SPF: pass client-ip=80.12.242.65; envelope-from=da_vid@orange.fr; helo=smtp.smtpout.orange.fr 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, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) This is a multi-part message in MIME format. --------------5iany5QbJB0F3OJaRQo1nd4S Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello, Following advice of S. Monnier, I am creating this specific bug report for this issue discovered while working on bug report #77725. I am copying the messages exchanged on this subject here. I attached the test file cl-type-recipe2.el for the mentioned simple recipe to reproduce the issue. Thanks! > On 2025-04-24 13:44, David Ponce wrote: >> It seems the side effect is more general than just with cl-type.el. >> >> I attached cl-type-recipe2.el, another simple recipe to illustrate with >> current `cl-deftype'. >> >> - Run emacs -Q and load cl-type-recipe2.el. >> - Then in the scratch buffer eval: >> >> (symbol-plist 'cons-car-foo) >> => (cl-deftype-handler #[nil ((list 'satisfies #'(lambda (x) (eq (car-safe x) 'foo)))) (t) nil "A cons with a `foo' car."]) >> >> - Then open cl-type-recipe2.el and M-x emacs-lisp-byte-compile >> >> - Then in the scratch buffer eval again: >> >> (symbol-plist 'cons-car-foo) >> => (cl-deftype-handler #[nil (`(# ,(# (x) (# (# #) '#)))) (t) nil "A cons with a `foo' car."]) >> >> And, of course: >> >> (cl-typep '(foo) 'cons-car-foo) >> => (invalid-function #) >> >> Without compile in the `cl-eval-when' in `cl-deftype', there is no side effect. >> >> Hope it will help. >> >> David > > Another information which could be useful: if I replace (cl-eval-when (compile load eval) ...) > by (eval-and-compile ...) in the definition of `cl-deftype', there is no side effect > of the byte-compilation on the current definition. > > What I don't know is if the two forms are equivalent. > > On 2025-04-24 21:44, Stefan Monnier wrote: >> Another information which could be useful: if I replace (cl-eval-when >> (compile load eval) ...) by (eval-and-compile ...) in the definition >> of `cl-deftype', there is no side effect of the byte-compilation on >> the current definition. > > It looks like this is a bug in `cl-eval-when` introduced when Alan added > "symbol with positions" for better error reporting. > > Could you make it a separate bug-report? > >> What I don't know is if the two forms are equivalent. > > Obviously they don't do quite the same thing, but AFAIK they *should* > behave the same, so I'd use `eval-and-compile`. > > > Stefan > In GNU Emacs 31.0.50 (build 3, x86_64-pc-linux-gnu, GTK+ Version 3.24.43, cairo version 1.18.2) of 2025-04-22 Repository revision: 871ec9615a949e967bf7d19466eb9c56ed80ff7e Repository branch: master Windowing system distributor 'The X.Org Foundation', version 11.0.12101016 System Description: Fedora Linux 41 (KDE Plasma) Configured using: 'configure --with-native-compilation=no PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/usr/lib/pkgconfig' Configured features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XINERAMA XINPUT2 XPM XRANDR GTK3 ZLIB Important settings: value of $LC_TIME: fr_FR.utf8 value of $LANG: fr_FR.UTF-8 locale-coding-system: utf-8-unix --------------5iany5QbJB0F3OJaRQo1nd4S Content-Type: text/x-emacs-lisp; charset=UTF-8; name="cl-type-recipe2.el" Content-Disposition: attachment; filename="cl-type-recipe2.el" Content-Transfer-Encoding: base64 OzsgLSotIGxleGljYWwtYmluZGluZzogdDsgLSotCgoocmVxdWlyZSAnY2wtbGliKQoKKGNs LWRlZnR5cGUgY29ucy1jYXItZm9vICgpCiAgIkEgY29ucyB3aXRoIGEgYGZvbycgY2FyLiIK ICBgKHNhdGlzZmllcyAsKGxhbWJkYSAoeCkgKGVxIChjYXItc2FmZSB4KSAnZm9vKSkpKQoK KGNsLWRlZnR5cGUgY29ucy1jZHItZm9vICgpCiAgIkEgY29ucyB3aXRoIGEgYGZvbycgY2Ry LiIKICBgKHNhdGlzZmllcyAsKGxhbWJkYSAoeCkgKGVxIChjZHItc2FmZSB4KSAnZm9vKSkp KQo= --------------5iany5QbJB0F3OJaRQo1nd4S-- From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 27 01:13:58 2025 Received: (at 78056) by debbugs.gnu.org; 27 Apr 2025 05:13:58 +0000 Received: from localhost ([127.0.0.1]:37935 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u8uKz-0004AH-Q9 for submit@debbugs.gnu.org; Sun, 27 Apr 2025 01:13:58 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:19162) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1u8uKx-00049z-78 for 78056@debbugs.gnu.org; Sun, 27 Apr 2025 01:13:56 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 0EEA744052E; Sun, 27 Apr 2025 01:13:48 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1745730826; bh=qeSRg2kREY25qitowrva3vH4+ZQjrfEEwT6v2r9Oufc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=kCCKJefVHNkYaFohrLvZ1S16OFwfoZwRFGKs014rAP08fk7njyKUd0/NFzz7PGuQ4 q3uoln1sM51Ts/PlsST6IO2FUU4cKMQvkuth0CFupNgqLNkEOGA9VX2fmmh0XFQhJM +cUNuyb/1ILre+xVsHc5r7JUwrH3N6swgedwjwxDL1WKxSp7zC0jOl3mZ0H2j6/9Ow uYwT/yWHvtCNuHp7PO8dTpY+fY37tP+YjF9+iHX8YSylAnSPRUGz0LPwAS00nTe29H bwvBli/gB1V71aap1vgzxPDcsiQ8mLhadK09YSR4RkiRtp4p0tobezrHphTy2DoUyY jlFCyzpxvp6VQ== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 74BB044046A; Sun, 27 Apr 2025 01:13:46 -0400 (EDT) Received: from alfajor (104-195-232-56.cpe.teksavvy.com [104.195.232.56]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 455171204C9; Sun, 27 Apr 2025 01:13:46 -0400 (EDT) From: Stefan Monnier To: David Ponce Subject: Re: bug#78056: 31.0.50; bug in `cl-eval-when` with symbols with positions In-Reply-To: <5951a2a7-12b2-4ac0-a4e9-a874ff4dd25a@orange.fr> Message-ID: References: <5951a2a7-12b2-4ac0-a4e9-a874ff4dd25a@orange.fr> Date: Sun, 27 Apr 2025 01:13:32 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.018 Adjusted score from AWL reputation of From: address 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: 78056 Cc: 78056@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) --=-=-= Content-Type: text/plain >>> (cl-typep '(foo) 'cons-car-foo) >>> => (invalid-function #) >>> >>> Without compile in the `cl-eval-when' in `cl-deftype', there is no side effect. To fix this problem, `cl-eval-when` would need to do the same kind of `byte-run-strip-symbol-positions` dance as is done for `eval-when-compile` and `eval-and-compile`. But I suggest the patch below instead, which starts by acknowledging that `cl-eval-when` doesn't actually distinguish if it's used at top-level (it has an ugly hack which tries to do that, but only for those `cl-eval-when` nested inside another `cl-eval-when`, which his extremely rare, and even in those cases it's right only some of the time). So the patch throws away the ugly hack and just reduces `cl-eval-when` to one of `eval-when-compile`, `eval-and-compile`, `progn`, or nil. It might be worthwhile to improve our macro-expansion machinery to let (compiler-)macros know if they're used at top-level or not, but that's a larger undertaking and it will be easy to retro-fit it into this macro if/when we do that. Comments, objections? Stefan --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=cl-when.patch diff --git a/lisp/emacs-lisp/cl-macs.el b/lisp/emacs-lisp/cl-macs.el index a966ec5eaf6..0f748e01791 100644 --- a/lisp/emacs-lisp/cl-macs.el +++ b/lisp/emacs-lisp/cl-macs.el @@ -724,8 +724,6 @@ cl-destructuring-bind ;;; The `cl-eval-when' form. -(defvar cl--not-toplevel nil) - ;;;###autoload (defmacro cl-eval-when (when &rest body) "Control when BODY is evaluated. @@ -733,31 +731,22 @@ cl-eval-when If `load' is in WHEN, BODY is evaluated when loaded after top-level compile. If `eval' is in WHEN, BODY is evaluated when interpreted or at non-top-level. +Beware: the implementation currently fails to correctly distinguish top-level +from non-top-level uses. Among other things, this means that `load' and `eval' +are conflated. + \(fn (WHEN...) BODY...)" (declare (indent 1) (debug (sexp body))) - (if (and (macroexp-compiling-p) - (not cl--not-toplevel) (not (boundp 'for-effect))) ;Horrible kludge. - (let ((comp (or (memq 'compile when) (memq :compile-toplevel when))) - (cl--not-toplevel t)) - (if (or (memq 'load when) (memq :load-toplevel when)) - (if comp (cons 'progn (mapcar #'cl--compile-time-too body)) - `(if nil nil ,@body)) - (progn (if comp (eval (cons 'progn body) lexical-binding)) nil))) - (and (or (memq 'eval when) (memq :execute when)) - (cons 'progn body)))) - -(defun cl--compile-time-too (form) - (or (and (symbolp (car-safe form)) (get (car-safe form) 'byte-hunk-handler)) - (setq form (macroexpand - form (cons '(cl-eval-when) macroexpand-all-environment)))) - (cond ((eq (car-safe form) 'progn) - (cons 'progn (mapcar #'cl--compile-time-too (cdr form)))) - ((eq (car-safe form) 'cl-eval-when) - (let ((when (nth 1 form))) - (if (or (memq 'eval when) (memq :execute when)) - `(cl-eval-when (compile ,@when) ,@(cddr form)) - form))) - (t (eval form lexical-binding) form))) + (let ((when-comp (or (memq 'compile when) (memq :compile-toplevel when))) + (when-eval (or (memq 'eval when) (memq :execute when) + (memq 'load when) (memq :load-toplevel when)))) + (cond + ((and (macroexp-compiling-p) when-comp) + (if when-eval + `(eval-and-compile . ,body) + `(eval-when-compile . ,body))) + (when-eval + (macroexp-progn body))))) ;;;###autoload (defmacro cl-load-time-value (form &optional _read-only) --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 27 03:15:37 2025 Received: (at 78056) by debbugs.gnu.org; 27 Apr 2025 07:15:37 +0000 Received: from localhost ([127.0.0.1]:38458 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u8wEh-0003M2-CT for submit@debbugs.gnu.org; Sun, 27 Apr 2025 03:15:37 -0400 Received: from smtp-15.smtpout.orange.fr ([80.12.242.15]:60803 helo=smtp.smtpout.orange.fr) by debbugs.gnu.org with esmtps (TLS1.2:RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1u8wEd-0003LQ-4L for 78056@debbugs.gnu.org; Sun, 27 Apr 2025 03:15:32 -0400 Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA id 8wE7uviiodMIr8wEAuETLD; Sun, 27 Apr 2025 09:15:04 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1745738104; bh=TeRUlpCRG+QpailqK+KWLtpO+W0kyTi4PuvFB1xGg2k=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=bp/BGPpxzN6UWLBACJLAD312ymSZXwaG6eLP/I7K/3f193waeFFtfaS1QayYuQmyd q3spGFKJqpoY7k5FU3dMB9q5P5icOYViuij03rxFaOSi3Avof3vVTjD6czaSbOSfig eSxI/2cSOgFgFAJUeDW9TmbHYRCR6I3p8wGA1S/NvmMe0ZXsJtiSs0NZm/BDjup7Mg AILKRB/eO2hwE/Aj61NjGNET/ZIZH6fflr7L9dCG82tSutVwfPmuG24DXDERhQB6f6 BPYtMtF9WCwZvjp0+N3ko2TEUb7sMfycWKTqKFEMkAVrxhjdXJ7HRIxWXGI/EbRkzb iX6K8/B/w/U9g== X-ME-Helo: [192.168.1.21] X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI= X-ME-Date: Sun, 27 Apr 2025 09:15:04 +0200 X-ME-IP: 90.112.40.65 Message-ID: <985d5e1a-7bdf-42d9-b7b1-305fd1192b8a@orange.fr> Date: Sun, 27 Apr 2025 09:15:23 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#78056: 31.0.50; bug in `cl-eval-when` with symbols with positions To: Stefan Monnier References: <5951a2a7-12b2-4ac0-a4e9-a874ff4dd25a@orange.fr> Content-Language: fr, en-US From: David Ponce In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78056 Cc: 78056@debbugs.gnu.org, Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 2025-04-27 07:13, Stefan Monnier wrote: >>>> (cl-typep '(foo) 'cons-car-foo) >>>> => (invalid-function #) >>>> >>>> Without compile in the `cl-eval-when' in `cl-deftype', there is no side effect. > > To fix this problem, `cl-eval-when` would need to do the same kind of > `byte-run-strip-symbol-positions` dance as is done for > `eval-when-compile` and `eval-and-compile`. > > But I suggest the patch below instead, which starts by acknowledging > that `cl-eval-when` doesn't actually distinguish if it's used at > top-level (it has an ugly hack which tries to do that, but only for those > `cl-eval-when` nested inside another `cl-eval-when`, which his > extremely rare, and even in those cases it's right only some of the > time). > > So the patch throws away the ugly hack and just reduces `cl-eval-when` > to one of `eval-when-compile`, `eval-and-compile`, `progn`, or nil. > > It might be worthwhile to improve our macro-expansion machinery to let > (compiler-)macros know if they're used at top-level or not, but that's > a larger undertaking and it will be easy to retro-fit it into this macro > if/when we do that. > > Comments, objections? I don't have enough expertise to judge the merits of this patch, but it seems to me a very good thing to bring `cl-eval-when' back to the standard `eval-when-compile' and `eval-and-compile' cases as much as possible, if only to improve the consistency of the code and simplify its maintenance. Thanks! From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 27 12:03:34 2025 Received: (at 78056) by debbugs.gnu.org; 27 Apr 2025 16:03:34 +0000 Received: from localhost ([127.0.0.1]:43851 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u94Te-0002Oz-Ay for submit@debbugs.gnu.org; Sun, 27 Apr 2025 12:03:34 -0400 Received: from smtp-22.smtpout.orange.fr ([80.12.242.22]:58357 helo=smtp.smtpout.orange.fr) by debbugs.gnu.org with esmtps (TLS1.2:RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1u94TX-0002Od-2v for 78056@debbugs.gnu.org; Sun, 27 Apr 2025 12:03:32 -0400 Received: from [192.168.1.21] ([90.112.40.65]) by smtp.orange.fr with ESMTPA id 94TPuE3mU20Vo94TSunzzk; Sun, 27 Apr 2025 18:03:25 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1745769805; bh=KQS7kSIJ683RvRqXHrSEhFUHWtIFMGYayGNYAKACwfI=; h=Message-ID:Date:MIME-Version:Subject:From:To; b=JUxYiPJDn6Ti3qBcvXSKFZObbZBu+/NuSkHIFzazyrU1O2jnhU49VLhYlD+87Md1M O8tDMabfA/q9DQfao/X3sI41QDsemGjRARx77FZefZTDTznvJ2qEaG3JTd5/qmP/od 60ApnQlEJBt0c475WdswFBNBOS20HpwvZa5owC7f0DzfJZVmM9MsQcUEEes9V94FLf ulS1oXz2sIB9uWAATULeDJdgc5u9rVxhbMk8LB354Yf0ynboroPmkKWsb0R2fFUfFq tTtGdZrx4+wUls2+IzErX5EIlw4N9Cf0K9iN6rl3t2jLta5ufnuVzdB3Lirgr9HZcE oGjk+dspoz3IQ== X-ME-Helo: [192.168.1.21] X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI= X-ME-Date: Sun, 27 Apr 2025 18:03:25 +0200 X-ME-IP: 90.112.40.65 Message-ID: <6173b5ea-3b1d-438a-a548-5af2cdd6da4e@orange.fr> Date: Sun, 27 Apr 2025 18:03:18 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#78056: 31.0.50; bug in `cl-eval-when` with symbols with positions From: David Ponce To: Stefan Monnier References: <5951a2a7-12b2-4ac0-a4e9-a874ff4dd25a@orange.fr> <985d5e1a-7bdf-42d9-b7b1-305fd1192b8a@orange.fr> Content-Language: fr, en-US In-Reply-To: <985d5e1a-7bdf-42d9-b7b1-305fd1192b8a@orange.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78056 Cc: 78056@debbugs.gnu.org, Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 2025-04-27 09:15, David Ponce wrote: > On 2025-04-27 07:13, Stefan Monnier wrote: >>>>> (cl-typep '(foo) 'cons-car-foo) >>>>> => (invalid-function #) >>>>> >>>>> Without compile in the `cl-eval-when' in `cl-deftype', there is no side effect. >> >> To fix this problem, `cl-eval-when` would need to do the same kind of >> `byte-run-strip-symbol-positions` dance as is done for >> `eval-when-compile` and `eval-and-compile`. >> >> But I suggest the patch below instead, which starts by acknowledging >> that `cl-eval-when` doesn't actually distinguish if it's used at >> top-level (it has an ugly hack which tries to do that, but only for those >> `cl-eval-when` nested inside another `cl-eval-when`, which his >> extremely rare, and even in those cases it's right only some of the >> time). >> >> So the patch throws away the ugly hack and just reduces `cl-eval-when` >> to one of `eval-when-compile`, `eval-and-compile`, `progn`, or nil. >> >> It might be worthwhile to improve our macro-expansion machinery to let >> (compiler-)macros know if they're used at top-level or not, but that's >> a larger undertaking and it will be easy to retro-fit it into this macro >> if/when we do that. >> >> Comments, objections? > > I don't have enough expertise to judge the merits of this patch, but it > seems to me a very good thing to bring `cl-eval-when' back to the standard > `eval-when-compile' and `eval-and-compile' cases as much as possible, if > only to improve the consistency of the code and simplify its maintenance. > > Thanks! I forgot to confirm that the patch fixed the issue :-) Thanks!