From unknown Sun Aug 17 22:10:19 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#41988 <41988@debbugs.gnu.org> To: bug#41988 <41988@debbugs.gnu.org> Subject: Status: 28.0.50; Edebug unconditionally instruments definitions with &define specs Reply-To: bug#41988 <41988@debbugs.gnu.org> Date: Mon, 18 Aug 2025 05:10:19 +0000 retitle 41988 28.0.50; Edebug unconditionally instruments definitions with = &define specs reassign 41988 emacs submitter 41988 Philipp severity 41988 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 21 12:59:05 2020 Received: (at submit) by debbugs.gnu.org; 21 Jun 2020 16:59:05 +0000 Received: from localhost ([127.0.0.1]:60855 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jn3JA-0001Gc-LP for submit@debbugs.gnu.org; Sun, 21 Jun 2020 12:59:04 -0400 Received: from lists.gnu.org ([209.51.188.17]:36310) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jn3J7-0001GC-9P for submit@debbugs.gnu.org; Sun, 21 Jun 2020 12:59:03 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:58694) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jn3J7-0000wX-0p for bug-gnu-emacs@gnu.org; Sun, 21 Jun 2020 12:59:01 -0400 Received: from mail-wr1-x444.google.com ([2a00:1450:4864:20::444]:32829) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jn3J5-0004K4-1m for bug-gnu-emacs@gnu.org; Sun, 21 Jun 2020 12:59:00 -0400 Received: by mail-wr1-x444.google.com with SMTP id l11so14368743wru.0 for ; Sun, 21 Jun 2020 09:58:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version; bh=6UP0dIreru0XNIFamP68DvxHFfz+TtGXjizrMDZMRpo=; b=g+hP5B+4oSC93UXAJvAXDG93DcsSti85Ox96rSYghKdDTpo5P4LB91gkTKrO/+dUjV N51+nnVdvGdE1AmaLlIcUJZpnHKCDHAi2bPt1i5ZUTBz5r1i9wtHTYui+mQPF/8hDB22 BBtPJ92PtVsfaIKPwLF4ZHkmyfOfI9qXbuldFwk7LCdedDY3tceUK2FRaFnomx3P4QOe /XB/LacVxkpK5ZSTqDP5Jg3+sRJ9Gg9dwQUIul2K5hVpHJ1h7NithIf++t1yW1MoV1LP sLAkSTskYdWWY3eFnBgiiLF1ztHCWeWMwLEMJVI6ZBQk5FvHdWhTdzBBnF8bulmDsTrt F3cQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version; bh=6UP0dIreru0XNIFamP68DvxHFfz+TtGXjizrMDZMRpo=; b=beHfRNVyupuEIoVn/Z3COisQ+utJJMPt6zfHNOonfcq0V7xX10h2jAyWMERsZ43H8l WZ1crz2WzkT78EHLwYbgbQ6s6I+qokafm5imgc8MyaatgW402cBPB6jbMga7lQ7KOA06 3z3y9MuM1IKBD6s/2j1f60n2upUsshAV55fnOtPGyH40S3ncNwAHbkqHmrEDendbgB0r H/1msWZ24oo1voKvxadjZdJNOVGNS+zYi5bujGf5gEJPrwLSTszYL8O37uR7yuU07UCI Rb/690iAjVcl0Ga0wvvmLUPjJnCX/qR4tSTIMnoFFxLJbkxiRMCicfgepCn0E7ISVd6C /fYw== X-Gm-Message-State: AOAM531d4SG91IjuSQOk/C4EQiDIxrEEbhf5DJh5k9AsZak7gFLEw69+ 8NNqrc/XDsPEvunWFxP1wBi5XaDCItc= X-Google-Smtp-Source: ABdhPJyCaYfQf6YcCBiJLoF46QcRB3pfSrAs024h4324AWeaLyJ3JeQGFNA1LLYkEnadd7c0WqZofw== X-Received: by 2002:adf:8444:: with SMTP id 62mr14138875wrf.278.1592758736844; Sun, 21 Jun 2020 09:58:56 -0700 (PDT) Received: from p ([2a02:2455:2a2:100:b098:928b:bb30:186]) by smtp.gmail.com with ESMTPSA id d63sm14269414wmc.22.2020.06.21.09.58.55 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 21 Jun 2020 09:58:56 -0700 (PDT) From: Philipp To: bug-gnu-emacs@gnu.org Subject: 28.0.50; Edebug unconditionally instruments definitions with &define specs Date: Sun, 21 Jun 2020 18:58:55 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2a00:1450:4864:20::444; envelope-from=p.stephani2@gmail.com; helo=mail-wr1-x444.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-Spam-Score: 0.9 (/) 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: -2.1 (--) As an example, edebug-instrument (C-u C-M-x) the following definition: (defun bar () (cl-flet ((foo () 1)) (foo))) The *Messages* buffer now says Edebug: foo [2 times] Edebug: bar Note the '[2 times]'. I believe this is because `edebug-match-&define' calls `edebug-make-form-wrapper' unconditionally. The Edebug spec for `cl-flet' has two `&or' branches that both use `&define', so if the first one doesn't match it will still create a definition using `edebug-make-form-wrapper'. Probably `edebug-match-&define' should only invoke `edebug-make-form-wrapper' if the specification actually matches. In GNU Emacs 28.0.50 (build 55, x86_64-apple-darwin19.4.0, NS appkit-1894.50 Version 10.15.5 (Build 19F101)) of 2020-06-21 Repository revision: a4d3897d8f0caa54be1e1d081651ed6640b7f25e Repository branch: master Windowing system distributor 'Apple', version 10.3.1894 System Description: Mac OS X 10.15.5 Recent messages: For information about GNU Emacs and the GNU system, type C-h C-a. C-c C-c is undefined Configured using: 'configure --with-modules --without-xml2 --without-pop --with-mailutils --enable-gcc-warnings=warn-only --enable-checking=all --enable-check-lisp-object-type 'CFLAGS=-ggdb3 -O0'' Configured features: JPEG TIFF GIF PNG NOTIFY KQUEUE ACL GNUTLS ZLIB TOOLKIT_SCROLL_BARS NS MODULES THREADS JSON PDUMPER LCMS2 GMP Important settings: value of $LANG: de_DE.UTF-8 locale-coding-system: utf-8-unix Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t global-eldoc-mode: t eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message rmc dired dired-loaddefs rfc822 mml easymenu mml-sec epa epg epg-config gnus-util rmail rmail-loaddefs text-property-search time-date mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils phst skeleton derived edmacro kmacro pcase ffap thingatpt url url-proxy url-privacy url-expand url-methods url-history url-cookie url-domsuf url-util url-parse auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs password-cache json map url-vars mailcap subr-x rx gnutls puny seq byte-opt gv bytecomp byte-compile cconv dbus xml compile comint ansi-color ring cl-loaddefs cl-lib tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/ns-win ns-win ucs-normalize mule-util term/common-win tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite charscript charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote threads kqueue cocoa ns lcms2 multi-tty make-network-process emacs) Memory information: ((conses 16 69651 5774) (symbols 48 8651 1) (strings 32 23551 1900) (string-bytes 1 768689) (vectors 16 14140) (vector-slots 8 172499 9631) (floats 8 25 30) (intervals 56 206 0) (buffers 992 10)) From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 21 19:48:27 2020 Received: (at 41988) by debbugs.gnu.org; 21 Jun 2020 23:48:27 +0000 Received: from localhost ([127.0.0.1]:32846 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jn9hL-00078Q-D0 for submit@debbugs.gnu.org; Sun, 21 Jun 2020 19:48:27 -0400 Received: from colin.muc.de ([193.149.48.1]:15229 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1jn9hH-00078A-Ll for 41988@debbugs.gnu.org; Sun, 21 Jun 2020 19:48:26 -0400 Received: (qmail 88428 invoked by uid 3782); 21 Jun 2020 23:48:16 -0000 Date: 21 Jun 2020 23:48:16 -0000 Message-ID: <20200621234816.88427.qmail@mail.muc.de> From: Alan Mackenzie To: Philipp Subject: Re: bug#41988: 28.0.50; Edebug unconditionally instruments definitions with &define specs Organization: muc.de e.V. In-Reply-To: X-Newsgroups: gnu.emacs.bug User-Agent: tin/2.4.4-20191224 ("Millburn") (FreeBSD/11.3-RELEASE-p9 (amd64)) X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41988 Cc: 41988@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: -1.0 (-) Hello, Philipp. In article you wrote: > As an example, edebug-instrument (C-u C-M-x) the following definition: > (defun bar () > (cl-flet ((foo () 1)) > (foo))) > The *Messages* buffer now says > Edebug: foo [2 times] > Edebug: bar > Note the '[2 times]'. I believe this is because `edebug-match-&define' > calls `edebug-make-form-wrapper' unconditionally. The Edebug spec for > `cl-flet' has two `&or' branches that both use `&define', so if the > first one doesn't match it will still create a definition using > `edebug-make-form-wrapper'. Probably `edebug-match-&define' should only > invoke `edebug-make-form-wrapper' if the specification actually matches. I don't understand why this is a bug. What precisely is wrong with the messages displayed in *Messages*? Or is it something else which is wrong? After instrumenting bar, can you actually step through it with edebug? (I can't try it out myself, since I can't discern from the documentation what, precisely, cl-flet is supposed to do.) > In GNU Emacs 28.0.50 (build 55, x86_64-apple-darwin19.4.0, NS appkit-1894.50 Version 10.15.5 (Build 19F101)) > of 2020-06-21 > Repository revision: a4d3897d8f0caa54be1e1d081651ed6640b7f25e > Repository branch: master > Windowing system distributor 'Apple', version 10.3.1894 > System Description: Mac OS X 10.15.5 [ .... ] -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 08 07:02:10 2020 Received: (at 41988) by debbugs.gnu.org; 8 Aug 2020 11:02:10 +0000 Received: from localhost ([127.0.0.1]:58279 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k4Mc6-0007or-0A for submit@debbugs.gnu.org; Sat, 08 Aug 2020 07:02:10 -0400 Received: from mail-oi1-f172.google.com ([209.85.167.172]:33361) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k4Mc3-0007oY-5o for 41988@debbugs.gnu.org; Sat, 08 Aug 2020 07:02:08 -0400 Received: by mail-oi1-f172.google.com with SMTP id 25so4440436oir.0 for <41988@debbugs.gnu.org>; Sat, 08 Aug 2020 04:02:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8LjXQ6ODusjiW+2fjm+xSPHU8z5lGS+qZn8vwOk0VqQ=; b=rWjM7+3B8G9+Hu/9fGrmsQHPpXWMpS56bfIts+uRG0kvtJAlqru4L8r+gSaz26+R3q OyNCQNDdpb0smjMz9gSdwVk2a7W4eyrC4rO/WE857SHIdv9SYnWVcwsChq/2LiIsqXMp sf7stu0ve69fs+VQCPmAcs8AHKs17cWthtGhIQf/oNL3dntZ1PGgNTRwM+3cGy4CWA51 gWpI63SsbSlIJ7uul8q6HkoVII+g81R8PWNTY4oOerTdmr7KkiJX4qiGDqoCX2+NGtS5 dSAx2Gsw5iUn366yBsLt0q5tqStAC01p4l6FjcP1uu7ItER2DtYD1IjvKKPW5EDPB6Kq 85ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8LjXQ6ODusjiW+2fjm+xSPHU8z5lGS+qZn8vwOk0VqQ=; b=o4uN5tni+nf8oksnzMeR3AAakss9EBbPpCIIV2gSQ76U86rUnloIsEv+ChfyJkzRYR JruMZVtwRd6Nbt6l5P7qFppFNo7ZM7I4f+MYtvv7rS+MzK+VqjnICd/TG6p5HBkUAoxx 8hf9cOFFZyz84lKkHn55FDv3peF3d9U/F99bm2nIYaJMYE63Bixwq1JpI9JM4LckoU1N nFkt4dhSqn4MzkjbgWXI6Hyd2Dy+hYUWmvWsRV3e2C34Xzu+Yfc3bvMKENJuhOELPs9q QBvkXeWiq7du+KQkgIcrZaPp+F+47a70UYuy+7phGr6TC9HHotCek1k+EnaFI+qfN8Rc utgg== X-Gm-Message-State: AOAM531aGzNoixYPaAyW+OwZaLK7yLJ8gFNqUoK/Gz5VagNk3DJ78vta v5vgRX7iyTApjXpqUdvmsbCfqQrahyb2P8pow6707sNu X-Google-Smtp-Source: ABdhPJxrrMY11YyErEGPjOc0w/pM1MTTGeZqlbMqcf0I5HI5Lfl3mk4EzMXGqvm1g1/0f89anTiyn5TZtNpLBTJGs7U= X-Received: by 2002:aca:b884:: with SMTP id i126mr14904511oif.65.1596884521096; Sat, 08 Aug 2020 04:02:01 -0700 (PDT) MIME-Version: 1.0 References: <20200621234816.88427.qmail@mail.muc.de> In-Reply-To: <20200621234816.88427.qmail@mail.muc.de> From: Philipp Stephani Date: Sat, 8 Aug 2020 13:01:50 +0200 Message-ID: Subject: Re: bug#41988: 28.0.50; Edebug unconditionally instruments definitions with &define specs To: Alan Mackenzie Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 41988 Cc: 41988@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: -0.8 (/) Am Mo., 22. Juni 2020 um 01:48 Uhr schrieb Alan Mackenzie : > > Hello, Philipp. > > In article you wrote: > > > As an example, edebug-instrument (C-u C-M-x) the following definition: > > > (defun bar () > > (cl-flet ((foo () 1)) > > (foo))) > > > The *Messages* buffer now says > > > Edebug: foo [2 times] > > Edebug: bar > > > Note the '[2 times]'. I believe this is because `edebug-match-&define' > > calls `edebug-make-form-wrapper' unconditionally. The Edebug spec for > > `cl-flet' has two `&or' branches that both use `&define', so if the > > first one doesn't match it will still create a definition using > > `edebug-make-form-wrapper'. Probably `edebug-match-&define' should only > > invoke `edebug-make-form-wrapper' if the specification actually matches. > > I don't understand why this is a bug. What precisely is wrong with the > messages displayed in *Messages*? Or is it something else which is > wrong? > > After instrumenting bar, can you actually step through it with edebug? > (I can't try it out myself, since I can't discern from the documentation > what, precisely, cl-flet is supposed to do.) > So this is somewhat subtle, so let me try to give some context. The message is merely a symptom of defining a symbol twice (via edebug-make-form-wrapper). That's a problem when using Edebug for coverage instrumentation (in batch mode), as the coverage information is attached to properties of the symbol that Edebug generates/instruments. Instrumenting a symbol with two different definitions can lead to very subtle bugs because the frequency vector and the form offset vector are out of sync, see e.g. https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41853. Therefore it's important to prevent such duplicate instrumentation, typically by changing the Edebug symbol in some way (appending a unique suffix, etc.). Edebug does this already in many cases (ERT tests, CL methods, ...), but not always. For some more context, see the coverage instrumentation in my Bazel rules for ELisp (https://github.com/phst/rules_elisp). https://github.com/phst/rules_elisp/blob/master/elisp/ert/runner.el contains the ERT and coverage integration. In https://github.com/phst/rules_elisp/blob/0b24aa1660af2f6c668899bdd78aaba383d7ac18/elisp/ert/runner.el#L133-L134 I explicitly check for duplicate instrumentation. It is hard to predict in general whether a specific instance of duplicate instrumentation will lead to bugs like https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41853 or not, thus I'm treating every duplicate instrumentation as a bug. From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 08 10:59:58 2020 Received: (at 41988) by debbugs.gnu.org; 8 Aug 2020 14:59:58 +0000 Received: from localhost ([127.0.0.1]:59473 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k4QKE-0002Ei-9V for submit@debbugs.gnu.org; Sat, 08 Aug 2020 10:59:58 -0400 Received: from colin.muc.de ([193.149.48.1]:27705 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1k4QKC-0002ET-KK for 41988@debbugs.gnu.org; Sat, 08 Aug 2020 10:59:58 -0400 Received: (qmail 80133 invoked by uid 3782); 8 Aug 2020 14:59:48 -0000 Received: from acm.muc.de (p2e5d54f7.dip0.t-ipconnect.de [46.93.84.247]) by localhost.muc.de (tmda-ofmipd) with ESMTP; Sat, 08 Aug 2020 16:59:48 +0200 Received: (qmail 10453 invoked by uid 1000); 8 Aug 2020 14:59:48 -0000 Date: Sat, 8 Aug 2020 14:59:48 +0000 To: Philipp Stephani Subject: Re: bug#41988: 28.0.50; Edebug unconditionally instruments definitions with &define specs Message-ID: <20200808145948.GA10181@ACM> References: <20200621234816.88427.qmail@mail.muc.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41988 Cc: 41988@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: -1.0 (-) Hello, Philipp. I must admit, I'm having difficulty understanding this problem. On Sat, Aug 08, 2020 at 13:01:50 +0200, Philipp Stephani wrote: > Am Mo., 22. Juni 2020 um 01:48 Uhr schrieb Alan Mackenzie : > > In article you wrote: > > > As an example, edebug-instrument (C-u C-M-x) the following > > > definition: > > > (defun bar () > > > (cl-flet ((foo () 1)) > > > (foo))) > > > The *Messages* buffer now says > > > Edebug: foo [2 times] > > > Edebug: bar > > > Note the '[2 times]'. I believe this is because > > > `edebug-match-&define' calls `edebug-make-form-wrapper' > > > unconditionally. The Edebug spec for `cl-flet' has two `&or' > > > branches that both use `&define', so if the first one doesn't match > > > it will still create a definition using `edebug-make-form-wrapper'. > > > Probably `edebug-match-&define' should only invoke > > > `edebug-make-form-wrapper' if the specification actually matches. > > I don't understand why this is a bug. What precisely is wrong with > > the messages displayed in *Messages*? Or is it something else which > > is wrong? > > After instrumenting bar, can you actually step through it with > > edebug? (I can't try it out myself, since I can't discern from the > > documentation what, precisely, cl-flet is supposed to do.) > So this is somewhat subtle, so let me try to give some context. The > message is merely a symptom of defining a symbol twice (via > edebug-make-form-wrapper). That's a problem when using Edebug for > coverage instrumentation (in batch mode), as the coverage information > is attached to properties of the symbol that Edebug > generates/instruments. I'm trying to see what, exactly, this problem is. Edebug is defining a symbol twice, once for each of two arms of a &or form in the edebug spec. The first of these surely does nothing; it will eventually end up in the garbage collector. The second will form the function slot of the symbol, fulfilling all the Edebug things. What am I missing? > Instrumenting a symbol with two different definitions can lead to very > subtle bugs because the frequency vector and the form offset vector are > out of sync, .... The picture you seem to be painting is of two distinct definitions being assigned to the same symbol, and both of them being live. Do you have any evidence that this is happening? > .... see e.g. https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41853. > Therefore it's important to prevent such duplicate instrumentation, > typically by changing the Edebug symbol in some way (appending a unique > suffix, etc.). Edebug does this already in many cases (ERT tests, CL > methods, ...), but not always. For some more context, see the coverage > instrumentation in my Bazel rules for ELisp > (https://github.com/phst/rules_elisp). > https://github.com/phst/rules_elisp/blob/master/elisp/ert/runner.el > contains the ERT and coverage integration. In > https://github.com/phst/rules_elisp/blob/0b24aa1660af2f6c668899bdd78aaba383d7ac18/elisp/ert/runner.el#L133-L134 > I explicitly check for duplicate instrumentation. It is hard to predict > in general whether a specific instance of duplicate instrumentation > will lead to bugs like > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41853 or not, thus I'm > treating every duplicate instrumentation as a bug. What exactly do you mean by "duplicate instrumentation"? If a symbol gets defined twice, once for each arm of an &or in the edebug spec, does that count as a duplicate instrumentation? -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 09 07:34:12 2020 Received: (at 41988) by debbugs.gnu.org; 9 Aug 2020 11:34:12 +0000 Received: from localhost ([127.0.0.1]:60138 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k4jad-0003IG-LW for submit@debbugs.gnu.org; Sun, 09 Aug 2020 07:34:12 -0400 Received: from mail-ot1-f54.google.com ([209.85.210.54]:33805) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k4jab-0003I1-VD for 41988@debbugs.gnu.org; Sun, 09 Aug 2020 07:34:10 -0400 Received: by mail-ot1-f54.google.com with SMTP id k12so5139775otr.1 for <41988@debbugs.gnu.org>; Sun, 09 Aug 2020 04:34:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6fal7yEZr6AvDAgOfOLLinsHTt4+laJj/uoBiDOQWJQ=; b=QwwZ2Y/rv58PHS7+nMa2odXa7VwvpJDMjllr7wd+PbtEBNvo0h/FsNkeRMA6OnvWgb aEqTPi4fUQ+XIqnZ8xl6tssukstsxoF/FSU7VGEwTCMGfyA75s8HEe2h/I7P/ymAwPFR WMwkNkGshMatKCOqJ5qiuxkuGDnEwmLFsr0MMqBjLbmK6GJs5f4Ojqo1A+LBaP+YywJa drNf3mhdm0MIE3/x7YMFSktgnYowcg6EXcTybCXbXI95mhAtieXYeT0kgI+8hfFQN/XX 16npDqoH9Q9rihVTKSfnKRq2hw0xJ4QDCJlHmxBs0BsaKgsti7NofsBCrz0YhSm4MoVf vMpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6fal7yEZr6AvDAgOfOLLinsHTt4+laJj/uoBiDOQWJQ=; b=IcHNdRv4+xAA2i6uBbFnR/lqPE6pedyoFSyT8Nz1rtYCmXYBP3bqobKHw4nvfmkzWe 7lQdOINVfC4lckZa9rTKuuVR1K6mBeYKg1aoa5UkA4+5ai4EmW8JsFPzyemwV0ICfumF lixtlIKiJHPnz3w6h0FzdJ6O9f2UPyZJpVfwXjIRHIgsZ0PlTY7KsI2ny6HYmjcu1Dkx 6mC7IFlFlPMj7N3ao8aZTZwpeB86DSCwLprg82dhEzhkpLCy26+axMKrqtPb3oGH/mYj AAvtAS2o1620h503YRE7MZVSF3hQ9blMver6cmqS27HAUbZv/S7VQXshF9JRnWSMc21i Ak3Q== X-Gm-Message-State: AOAM531tfWUVXOO1iSWGw8XK3Adkk6uPSse/LAkT2GJ6Z/sLiclvRlO3 vkvrvS07HnrV8Pwpos4XO3ErkuXLw4jRMZUGDoRdLZG7 X-Google-Smtp-Source: ABdhPJzGDOHTdN878aNjY3oJDEns/jdUV/BzL2td+XunJnBk8W+YO/j6T5LKe85nVNTfnXNXAWtZvLdcKArZgL/KaQg= X-Received: by 2002:a9d:2203:: with SMTP id o3mr18292377ota.149.1596972844052; Sun, 09 Aug 2020 04:34:04 -0700 (PDT) MIME-Version: 1.0 References: <20200621234816.88427.qmail@mail.muc.de> <20200808145948.GA10181@ACM> In-Reply-To: <20200808145948.GA10181@ACM> From: Philipp Stephani Date: Sun, 9 Aug 2020 13:33:53 +0200 Message-ID: Subject: Re: bug#41988: 28.0.50; Edebug unconditionally instruments definitions with &define specs To: Alan Mackenzie Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 41988 Cc: 41988@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: -0.7 (/) Am Sa., 8. Aug. 2020 um 16:59 Uhr schrieb Alan Mackenzie : > > Hello, Philipp. > > I must admit, I'm having difficulty understanding this problem. > > On Sat, Aug 08, 2020 at 13:01:50 +0200, Philipp Stephani wrote: > > Am Mo., 22. Juni 2020 um 01:48 Uhr schrieb Alan Mackenzie : > > > > In article you wrote: > > > > > As an example, edebug-instrument (C-u C-M-x) the following > > > > definition: > > > > > (defun bar () > > > > (cl-flet ((foo () 1)) > > > > (foo))) > > > > > The *Messages* buffer now says > > > > > Edebug: foo [2 times] > > > > Edebug: bar > > > > > Note the '[2 times]'. I believe this is because > > > > `edebug-match-&define' calls `edebug-make-form-wrapper' > > > > unconditionally. The Edebug spec for `cl-flet' has two `&or' > > > > branches that both use `&define', so if the first one doesn't match > > > > it will still create a definition using `edebug-make-form-wrapper'. > > > > Probably `edebug-match-&define' should only invoke > > > > `edebug-make-form-wrapper' if the specification actually matches. > > > > I don't understand why this is a bug. What precisely is wrong with > > > the messages displayed in *Messages*? Or is it something else which > > > is wrong? > > > > After instrumenting bar, can you actually step through it with > > > edebug? (I can't try it out myself, since I can't discern from the > > > documentation what, precisely, cl-flet is supposed to do.) > > > > So this is somewhat subtle, so let me try to give some context. The > > message is merely a symptom of defining a symbol twice (via > > edebug-make-form-wrapper). That's a problem when using Edebug for > > coverage instrumentation (in batch mode), as the coverage information > > is attached to properties of the symbol that Edebug > > generates/instruments. > > I'm trying to see what, exactly, this problem is. Edebug is defining a > symbol twice, once for each of two arms of a &or form in the edebug spec. > The first of these surely does nothing; it will eventually end up in the > garbage collector. The second will form the function slot of the symbol, > fulfilling all the Edebug things. What am I missing? The problem is that Edebug not only generates objects that would later be garbage-collected (and therefore not observable), but also modifies observable global state. This starts at https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/emacs-lisp/edebug.el?id=55bcb3f7e05c01d86778f1a2b7caccf72124614d#n1418 and continues for the rest of the edebug-make-form-wrapper function. In particular, https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/emacs-lisp/edebug.el?id=55bcb3f7e05c01d86778f1a2b7caccf72124614d#n1444 sets the `edebug' symbol property of the symbol being generated. None of these mutations are undone when backtracking. > > > Instrumenting a symbol with two different definitions can lead to very > > subtle bugs because the frequency vector and the form offset vector are > > out of sync, .... > > The picture you seem to be painting is of two distinct definitions being > assigned to the same symbol, and both of them being live. Do you have > any evidence that this is happening? Let's say it's rather an incompatible mixture of two definitions. https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41853 is a symptom of this. Another piece of evidence is the implementation of `edebug-make-form-wrapper': that function clearly modifies buffer contents and symbol properties even in branches that would later be discarded as part of backtracking. My (not well evidenced) assumption is that https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/emacs-lisp/edebug.el?id=55bcb3f7e05c01d86778f1a2b7caccf72124614d#n1427 regenerates the offset vector, but there's no regeneration of the frequency vector, which is the immediate trigger of https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41853, since now the frequency and offset vectors might be incompatible with each other. But I'd also assume the problem runs deeper: edebug-make-form-wrapper performs multiple mutations, and it's not really clear which of those are "safe" w.r.t. multiple definitions in not-taken branches. > > > .... see e.g. https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41853. > > Therefore it's important to prevent such duplicate instrumentation, > > typically by changing the Edebug symbol in some way (appending a unique > > suffix, etc.). Edebug does this already in many cases (ERT tests, CL > > methods, ...), but not always. For some more context, see the coverage > > instrumentation in my Bazel rules for ELisp > > (https://github.com/phst/rules_elisp). > > https://github.com/phst/rules_elisp/blob/master/elisp/ert/runner.el > > contains the ERT and coverage integration. In > > https://github.com/phst/rules_elisp/blob/0b24aa1660af2f6c668899bdd78aaba383d7ac18/elisp/ert/runner.el#L133-L134 > > I explicitly check for duplicate instrumentation. It is hard to predict > > in general whether a specific instance of duplicate instrumentation > > will lead to bugs like > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41853 or not, thus I'm > > treating every duplicate instrumentation as a bug. > > What exactly do you mean by "duplicate instrumentation"? If a symbol > gets defined twice, once for each arm of an &or in the edebug spec, does > that count as a duplicate instrumentation? What I mean concretely is evaluating `edebug-make-form-wrapper' (and therefore, mutating symbol properties and buffer contents) once for each branch of an &or construct. From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 09 12:35:37 2020 Received: (at 41988) by debbugs.gnu.org; 9 Aug 2020 16:35:37 +0000 Received: from localhost ([127.0.0.1]:33319 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k4oIL-0003Eb-3q for submit@debbugs.gnu.org; Sun, 09 Aug 2020 12:35:37 -0400 Received: from colin.muc.de ([193.149.48.1]:38369 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1k4oIF-0003EF-2O for 41988@debbugs.gnu.org; Sun, 09 Aug 2020 12:35:35 -0400 Received: (qmail 1733 invoked by uid 3782); 9 Aug 2020 16:35:24 -0000 Received: from acm.muc.de (p2e5d5e8f.dip0.t-ipconnect.de [46.93.94.143]) by localhost.muc.de (tmda-ofmipd) with ESMTP; Sun, 09 Aug 2020 18:35:23 +0200 Received: (qmail 27260 invoked by uid 1000); 9 Aug 2020 16:35:23 -0000 Date: Sun, 9 Aug 2020 16:35:23 +0000 To: Philipp Stephani Subject: Re: bug#41988: 28.0.50; Edebug unconditionally instruments definitions with &define specs Message-ID: <20200809163523.GB26635@ACM> References: <20200621234816.88427.qmail@mail.muc.de> <20200808145948.GA10181@ACM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41988 Cc: 41988@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: -1.0 (-) Hello, Philipp. On Sun, Aug 09, 2020 at 13:33:53 +0200, Philipp Stephani wrote: > Am Sa., 8. Aug. 2020 um 16:59 Uhr schrieb Alan Mackenzie : > > I must admit, I'm having difficulty understanding this problem. > > On Sat, Aug 08, 2020 at 13:01:50 +0200, Philipp Stephani wrote: > > > Am Mo., 22. Juni 2020 um 01:48 Uhr schrieb Alan Mackenzie : [ .... ] > > > So this is somewhat subtle, so let me try to give some context. The > > > message is merely a symptom of defining a symbol twice (via > > > edebug-make-form-wrapper). That's a problem when using Edebug for > > > coverage instrumentation (in batch mode), as the coverage > > > information is attached to properties of the symbol that Edebug > > > generates/instruments. > > I'm trying to see what, exactly, this problem is. Edebug is defining > > a symbol twice, once for each of two arms of a &or form in the edebug > > spec. The first of these surely does nothing; it will eventually end > > up in the garbage collector. The second will form the function slot > > of the symbol, fulfilling all the Edebug things. What am I missing? > The problem is that Edebug not only generates objects that would later > be garbage-collected (and therefore not observable), but also modifies > observable global state. This starts at > https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/emacs-lisp/edebug.el?id=55bcb3f7e05c01d86778f1a2b7caccf72124614d#n1418 > and continues for the rest of the edebug-make-form-wrapper function. > In particular, > https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/emacs-lisp/edebug.el?id=55bcb3f7e05c01d86778f1a2b7caccf72124614d#n1444 > sets the `edebug' symbol property of the symbol being generated. None > of these mutations are undone when backtracking. Ah, I think I see it, now. edebug-form-data contains structures referring to functions, and could well have two entries with the same function name. (I see that at the moment in a file where I instrumented alternately an old version and a new version of a function.) The property list on the symbol then contains a messy combination of details for the two functions. > > > Instrumenting a symbol with two different definitions can lead to > > > very subtle bugs because the frequency vector and the form offset > > > vector are out of sync, .... > > The picture you seem to be painting is of two distinct definitions > > being assigned to the same symbol, and both of them being live. Do > > you have any evidence that this is happening? > Let's say it's rather an incompatible mixture of two definitions. > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41853 is a symptom of > this. Another piece of evidence is the implementation of > `edebug-make-form-wrapper': that function clearly modifies buffer > contents and symbol properties even in branches that would later be > discarded as part of backtracking. > My (not well evidenced) assumption is that > https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/emacs-lisp/edebug.el?id=55bcb3f7e05c01d86778f1a2b7caccf72124614d#n1427 > regenerates the offset vector, but there's no regeneration of the > frequency vector, which is the immediate trigger of > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41853, since now the > frequency and offset vectors might be incompatible with each other. > But I'd also assume the problem runs deeper: edebug-make-form-wrapper > performs multiple mutations, and it's not really clear which of those > are "safe" w.r.t. multiple definitions in not-taken branches. How about, instead of having symbol properties, we institute non-symbol property lists contained in each entry in edebug-form-data? This list could be rapidly searched, with repeated memq, for the pertinent entry. It would mean, however, that all gathered data would be discarded on each fresh instrumentation of a function. Apologies if you've already suggested this and I missed it. > > > .... see e.g. https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41853. > > > Therefore it's important to prevent such duplicate instrumentation, > > > typically by changing the Edebug symbol in some way (appending a unique > > > suffix, etc.). Edebug does this already in many cases (ERT tests, CL > > > methods, ...), but not always. For some more context, see the coverage > > > instrumentation in my Bazel rules for ELisp > > > (https://github.com/phst/rules_elisp). > > > https://github.com/phst/rules_elisp/blob/master/elisp/ert/runner.el > > > contains the ERT and coverage integration. In > > > https://github.com/phst/rules_elisp/blob/0b24aa1660af2f6c668899bdd78aaba383d7ac18/elisp/ert/runner.el#L133-L134 > > > I explicitly check for duplicate instrumentation. It is hard to predict > > > in general whether a specific instance of duplicate instrumentation > > > will lead to bugs like > > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41853 or not, thus I'm > > > treating every duplicate instrumentation as a bug. > > What exactly do you mean by "duplicate instrumentation"? If a symbol > > gets defined twice, once for each arm of an &or in the edebug spec, does > > that count as a duplicate instrumentation? > What I mean concretely is evaluating `edebug-make-form-wrapper' (and > therefore, mutating symbol properties and buffer contents) once for > each branch of an &or construct. OK, thanks. How does my above plan, for reinitilising the function's properties at each instrumentation, sound? -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 10 09:32:42 2020 Received: (at 41988) by debbugs.gnu.org; 10 Aug 2020 13:32:42 +0000 Received: from localhost ([127.0.0.1]:34961 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k57us-0003ok-7y for submit@debbugs.gnu.org; Mon, 10 Aug 2020 09:32:42 -0400 Received: from mail-ot1-f41.google.com ([209.85.210.41]:39452) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k57up-0003jR-M6 for 41988@debbugs.gnu.org; Mon, 10 Aug 2020 09:32:40 -0400 Received: by mail-ot1-f41.google.com with SMTP id z18so7243010otk.6 for <41988@debbugs.gnu.org>; Mon, 10 Aug 2020 06:32:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=a46mJzD7MlT4mJ6NWGxSDXsjJv17kGZi3yiLR7mhIio=; b=tj1EoL2ca5S/3UyGVgnKlxF21IBvalss60EcZIOhJEJt5S8Bqj0t3/XEHGM8Bb6s06 He23o92FhJBREYsDyI4NQ/i13XBbU/1ozMb+6Yx2OuuSysOwOJrjze5ywupMkFCsJ9Kl KHGozTWagc+tX931RM3GVst5JU/zh5j5xks74LPOCcqyIXnObU0alsx7u0ogLiRTzyS4 dY9cK0zR+HC6CbbvBAQwRboYZHXdZYnXdQdkAa5MdkzZ8au4YlFr/Iltb+I/ZUqQdgA2 mLvl9gFkbYW/9dSSR92igcY9KX+B9Qu8W57m9VrsGjUT3FuMK1v5d+onhL/k/uziq12s BgKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=a46mJzD7MlT4mJ6NWGxSDXsjJv17kGZi3yiLR7mhIio=; b=peVZ+AKW4rI+Ihf4Eu8PMhU9fTdUPRUeuXoW0qnkp2wLo4HQmg40P9MMgGpcxQiWpY TUR5l0TF3k3/LHV2QDm5lfC3J/toZ6Z3eAMhrh9HHcO3+MGBiuOA3C8gWXuU5SpBaay7 7yHy0tRMm13Ae2uo/CwOz9MzEethX34eWCVXyqQ7/DEU9IHK0WEBjakWNknK0IxK7t8p wSGkAakb0O7CsA6EesBO80xY4CWjI/1w6no7kaWmm/LWYdGcK/nYjksHi+PBMao4q31P /A2smSuualnJJMjDJL1Tyj0CMxUKO6BXCUtP1NXeAIiufpLJntXshuubdLNbSNlfeBBQ PVaQ== X-Gm-Message-State: AOAM533khhjFRbkpGSX+uSfGystjD30jTqGKv7xvZMOWx4BH+cPIeTC/ KasPqYuaktR0tYcqtow6Ftg19vyISA0i5Hl6xIptT7HS X-Google-Smtp-Source: ABdhPJz9Pct3+3mAXlvEaK1CQEbkhEwgFLXDZjpCzasffSEmRDeQzDzArsPVaOJuFkvYLYlOq3rnom94FWZWesfRG7s= X-Received: by 2002:a9d:2203:: with SMTP id o3mr753633ota.149.1597066353477; Mon, 10 Aug 2020 06:32:33 -0700 (PDT) MIME-Version: 1.0 References: <20200621234816.88427.qmail@mail.muc.de> <20200808145948.GA10181@ACM> <20200809163523.GB26635@ACM> In-Reply-To: <20200809163523.GB26635@ACM> From: Philipp Stephani Date: Mon, 10 Aug 2020 15:32:22 +0200 Message-ID: Subject: Re: bug#41988: 28.0.50; Edebug unconditionally instruments definitions with &define specs To: Alan Mackenzie Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 41988 Cc: 41988@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: -0.7 (/) Am So., 9. Aug. 2020 um 18:35 Uhr schrieb Alan Mackenzie : > > Hello, Philipp. > > On Sun, Aug 09, 2020 at 13:33:53 +0200, Philipp Stephani wrote: > > Am Sa., 8. Aug. 2020 um 16:59 Uhr schrieb Alan Mackenzie : > > > > I must admit, I'm having difficulty understanding this problem. > > > > On Sat, Aug 08, 2020 at 13:01:50 +0200, Philipp Stephani wrote: > > > > Am Mo., 22. Juni 2020 um 01:48 Uhr schrieb Alan Mackenzie : > > [ .... ] > > > > > So this is somewhat subtle, so let me try to give some context. The > > > > message is merely a symptom of defining a symbol twice (via > > > > edebug-make-form-wrapper). That's a problem when using Edebug for > > > > coverage instrumentation (in batch mode), as the coverage > > > > information is attached to properties of the symbol that Edebug > > > > generates/instruments. > > > > I'm trying to see what, exactly, this problem is. Edebug is defining > > > a symbol twice, once for each of two arms of a &or form in the edebug > > > spec. The first of these surely does nothing; it will eventually end > > > up in the garbage collector. The second will form the function slot > > > of the symbol, fulfilling all the Edebug things. What am I missing? > > > The problem is that Edebug not only generates objects that would later > > be garbage-collected (and therefore not observable), but also modifies > > observable global state. This starts at > > https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/emacs-lisp/edebug.el?id=55bcb3f7e05c01d86778f1a2b7caccf72124614d#n1418 > > and continues for the rest of the edebug-make-form-wrapper function. > > In particular, > > https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/emacs-lisp/edebug.el?id=55bcb3f7e05c01d86778f1a2b7caccf72124614d#n1444 > > sets the `edebug' symbol property of the symbol being generated. None > > of these mutations are undone when backtracking. > > Ah, I think I see it, now. edebug-form-data contains structures > referring to functions, and could well have two entries with the same > function name. (I see that at the moment in a file where I instrumented > alternately an old version and a new version of a function.) The > property list on the symbol then contains a messy combination of details > for the two functions. Yes. > > > > > Instrumenting a symbol with two different definitions can lead to > > > > very subtle bugs because the frequency vector and the form offset > > > > vector are out of sync, .... > > > > The picture you seem to be painting is of two distinct definitions > > > being assigned to the same symbol, and both of them being live. Do > > > you have any evidence that this is happening? > > > Let's say it's rather an incompatible mixture of two definitions. > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41853 is a symptom of > > this. Another piece of evidence is the implementation of > > `edebug-make-form-wrapper': that function clearly modifies buffer > > contents and symbol properties even in branches that would later be > > discarded as part of backtracking. > > My (not well evidenced) assumption is that > > https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/emacs-lisp/edebug.el?id=55bcb3f7e05c01d86778f1a2b7caccf72124614d#n1427 > > regenerates the offset vector, but there's no regeneration of the > > frequency vector, which is the immediate trigger of > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41853, since now the > > frequency and offset vectors might be incompatible with each other. > > But I'd also assume the problem runs deeper: edebug-make-form-wrapper > > performs multiple mutations, and it's not really clear which of those > > are "safe" w.r.t. multiple definitions in not-taken branches. > > How about, instead of having symbol properties, we institute non-symbol > property lists contained in each entry in edebug-form-data? This list > could be rapidly searched, with repeated memq, for the pertinent entry. > It would mean, however, that all gathered data would be discarded on each > fresh instrumentation of a function. Apologies if you've already > suggested this and I missed it. That seems roughly what the documentation of `edebug-form-data' itself suggests: "In the future (haha!), the symbol will be irrelevant and edebug data will be stored in the definitions themselves rather than in the property list of a symbol." Though I don't know what "the definitions themselves" is supposed to mean here. In any case, I'd agree that attaching the data (in an undocumented manner) to some symbol that then carefully needs to be constructed to be unique is too brittle. However, the current implementation is used in quite a few places (see e.g. the interactive specification of `edebug-remove-instrumentation'), so changing it isn't trivial. > > > > > .... see e.g. https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41853. > > > > Therefore it's important to prevent such duplicate instrumentation, > > > > typically by changing the Edebug symbol in some way (appending a unique > > > > suffix, etc.). Edebug does this already in many cases (ERT tests, CL > > > > methods, ...), but not always. For some more context, see the coverage > > > > instrumentation in my Bazel rules for ELisp > > > > (https://github.com/phst/rules_elisp). > > > > https://github.com/phst/rules_elisp/blob/master/elisp/ert/runner.el > > > > contains the ERT and coverage integration. In > > > > https://github.com/phst/rules_elisp/blob/0b24aa1660af2f6c668899bdd78aaba383d7ac18/elisp/ert/runner.el#L133-L134 > > > > I explicitly check for duplicate instrumentation. It is hard to predict > > > > in general whether a specific instance of duplicate instrumentation > > > > will lead to bugs like > > > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41853 or not, thus I'm > > > > treating every duplicate instrumentation as a bug. > > > > What exactly do you mean by "duplicate instrumentation"? If a symbol > > > gets defined twice, once for each arm of an &or in the edebug spec, does > > > that count as a duplicate instrumentation? > > > What I mean concretely is evaluating `edebug-make-form-wrapper' (and > > therefore, mutating symbol properties and buffer contents) once for > > each branch of an &or construct. > > OK, thanks. How does my above plan, for reinitilising the function's > properties at each instrumentation, sound? It would definitely be an improvement I think. From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 02 10:59:39 2021 Received: (at 41988) by debbugs.gnu.org; 2 Mar 2021 15:59:39 +0000 Received: from localhost ([127.0.0.1]:54042 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lH7Qw-0004Li-Gt for submit@debbugs.gnu.org; Tue, 02 Mar 2021 10:59:39 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:53895) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lH7Qq-0004LQ-Qt for 41988@debbugs.gnu.org; Tue, 02 Mar 2021 10:59:36 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id BBFB0440879; Tue, 2 Mar 2021 10:59:26 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 5F638440843; Tue, 2 Mar 2021 10:59:25 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1614700765; bh=bfMNXog8QUX1mFwKEhLhAw6DeRyGMS9JutKu8uiSzh8=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=hxHlUPzf7N/10anGP1fTOXBEhzeYou+Rj0SGXhykqNOswGQ46/TI/JaOJa0ML/o02 tjw6Y+Y0AZAUT3MYYF84b3RFhNRWL7Gcrkw7P4dFbEK4duU5sgeh8nusP+Hbnar8M1 O1XedpKxJEgUY7LWhjsIL4WITC3QdFHFPslNs7Ola+Xb0MZFqCapRazqFLQOKweidW CzZQudgAJPq+mbDtriePrLis9/q5O+5ZiVfbr2FTZVU6fay0vZKOT1/yT4Kd0BzhqT TqRugoIdqMl+gaMwEH6P9/m3/DMyoWjEx/9xpYirsmJjW49XJMrY8lDE/oEGhSM561 fN68N52xHMqOw== Received: from alfajor (unknown [216.154.41.47]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 6639C1203FD; Tue, 2 Mar 2021 10:59:25 -0500 (EST) From: Stefan Monnier To: Philipp Subject: Re: bug#41988: 28.0.50; Edebug unconditionally instruments definitions with &define specs Message-ID: References: Date: Tue, 02 Mar 2021 10:59:24 -0500 In-Reply-To: (Philipp's message of "Sun, 21 Jun 2020 18:58:55 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.100 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 X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41988 Cc: 41988@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 (---) > As an example, edebug-instrument (C-u C-M-x) the following definition: > > (defun bar () > (cl-flet ((foo () 1)) > (foo))) > > The *Messages* buffer now says > > Edebug: foo [2 times] > Edebug: bar I believe this is now fixed in `master`. At least we only get a total of 2 messages rather than "3 collapsed to 2". But I don't know enough about the code coverage to be sure that the underlying problem you saw is also fixed. Can you confirm? Stefan From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 02 12:28:23 2021 Received: (at 41988) by debbugs.gnu.org; 2 Mar 2021 17:28:23 +0000 Received: from localhost ([127.0.0.1]:54107 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lH8op-0006QB-Gk for submit@debbugs.gnu.org; Tue, 02 Mar 2021 12:28:23 -0500 Received: from mail-ot1-f49.google.com ([209.85.210.49]:45806) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lH8om-0006Pv-LN for 41988@debbugs.gnu.org; Tue, 02 Mar 2021 12:28:21 -0500 Received: by mail-ot1-f49.google.com with SMTP id d9so20701433ote.12 for <41988@debbugs.gnu.org>; Tue, 02 Mar 2021 09:28:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=yXdivCJCmd7MlWmnK8Hu3RilSNwNwzMVl47jNyMIMGw=; b=NV86xJ3H2rLzZAuGO3xnSyDBA+ifQrvXbMUd5OsluIMFyUmcF+yQFyBPJq6am/LXSS 330hCoGNFa069s9zIyKIBK3Es+BvGciNuD7pFksH/jAtnDm1QkQX6dIerNhAEyYt+TXd uRIU6zphHGakqrw5upWkkPOREkSkLtKwwmAv7tGkk0uvWUBQltlddlXoTHLlr4KhzkIr uqHm8rLkwXmdV3pURQrMheysdVfCqPnbA1c2omAOASbW6N73GY+TKNJVJY9oxws3b5fp +3zABOqUS6aAbf/1yzfKEx2RFzcqdnuRAMHj7w0NiAucsP2LMd/e3Cphc2Iz3gMnuY3f ZQTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=yXdivCJCmd7MlWmnK8Hu3RilSNwNwzMVl47jNyMIMGw=; b=YMDy57NpPfsH5+s/IDAm7xZscjFtflySN1FuRguQUtBXup6yQjC5L3U4fxljA1f7j8 1+CE0lPnUBC8MqjXaGCBIP4+Kq7seyM9sRJtYDxYwsGnyw0Lv2Mvm+wBuhVxqx/dsTJ9 CxaxXcmwHghdFRMmRuMbeT82egx6uObcSI4ylILe/FaSi0Sbor1XLT0d7VxvS4lTpk+f XDGFMQmegKrW5MeyLuAq9K/H+UL0Z3REaZZ2Mo9Xy1yNEt0gKIW8h4cCmwaAGqd+yfZ7 k/l0mCL70fW5ihP6yg7+3LlNu1HdMCcsTRJPxcKgJNYmcq1FAxdJLwIy9AwRdb7ziB2W SoQw== X-Gm-Message-State: AOAM530gbon9pKxXsEEOAkFJtb+27ZMe6LMqkreMMl++fBqeWjzKWTWF WPzb00ncdmitdEYR1dWDa36CAsyKvmdp+/sx+J8= X-Google-Smtp-Source: ABdhPJy3/O7oI6w6act1wTYyDi/21UWv0d11d1eM4HY0hQEVu80VhpfcitNhmLqmHc45ZC7qf/GoGq7sZIbO8pAJDXM= X-Received: by 2002:a9d:3a34:: with SMTP id j49mr18347404otc.153.1614706094723; Tue, 02 Mar 2021 09:28:14 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Philipp Stephani Date: Tue, 2 Mar 2021 18:28:03 +0100 Message-ID: Subject: Re: bug#41988: 28.0.50; Edebug unconditionally instruments definitions with &define specs To: Stefan Monnier Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 41988 Cc: 41988@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: -0.7 (/) Am Di., 2. M=C3=A4rz 2021 um 16:59 Uhr schrieb Stefan Monnier : > > > As an example, edebug-instrument (C-u C-M-x) the following definition: > > > > (defun bar () > > (cl-flet ((foo () 1)) > > (foo))) > > > > The *Messages* buffer now says > > > > Edebug: foo [2 times] > > Edebug: bar > > I believe this is now fixed in `master`. > At least we only get a total of 2 messages rather than "3 collapsed to 2"= . > But I don't know enough about the code coverage to be sure that the > underlying problem you saw is also fixed. Can you confirm? Thanks! I'll check (hopefully in the next few days). For context, the tests that should now be fixed are https://github.com/phst/rules_elisp/blob/6050b4ecc35e1a450320420f3a652f2551= fc22b1/tests/ert_test.go#L215 and https://github.com/phst/rules_elisp/blob/6050b4ecc35e1a450320420f3a652f= 2551fc22b1/elisp/ert/runner.el#L138. But these run under Emacs 27 by default. I'm going to check whether I can make them run under "master" as well. From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 08 11:33:39 2021 Received: (at 41988-done) by debbugs.gnu.org; 8 Mar 2021 16:33:40 +0000 Received: from localhost ([127.0.0.1]:44614 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lJIp9-0000Xc-OM for submit@debbugs.gnu.org; Mon, 08 Mar 2021 11:33:39 -0500 Received: from mail-oi1-f177.google.com ([209.85.167.177]:40055) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lJIp8-0000XP-4g for 41988-done@debbugs.gnu.org; Mon, 08 Mar 2021 11:33:38 -0500 Received: by mail-oi1-f177.google.com with SMTP id w65so11557741oie.7 for <41988-done@debbugs.gnu.org>; Mon, 08 Mar 2021 08:33:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Nz81GVOgana74Bp1QaY5YTBBXhmHNVeDV9q8/iX56SU=; b=Wovs7UkLqkf/qre2OglQ5bJNIF7b1QLGEaqjLc/HUM/EisT0jfe51Rz3WYllEno/cF eCDUj54k0a8tSpqMijj7FDWAPD9/S39/E+FIxtiU+HVgKzFk86waK70q1b+BF99F8CcR TFO25z2/3z80TSOwz7ypKBV3o3OEnoKL+m+pviYcgILK0g06B68u9GTTRp4zWHaWi3ny KUFIzt/UsO67Gas41Z/ulVQbYxxiedx+w2ZnUndR3YT7FJ9V0lcKruZNNbNhpShVIa1d Tg4Q6ANT8q72mv8PMkEPfrMayxomVzeeIO87lvwcXQuGDrjuTxm6k080JiXSZPjVYEWP t0oA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Nz81GVOgana74Bp1QaY5YTBBXhmHNVeDV9q8/iX56SU=; b=IAz0fpICSND+uchai3lqgW9gS4W1yvUFDHrQB2W6U7GEX0UeDQSoWIi/sw+d2qJ4A4 o2f5DGzgD8zgTp5jPRYErYTxvI/Tt2FM7fzAyrkuMLOFfU43nRoN1GJ49i7b9SfQZVsF hoL4G03aU0q5dU3SG1bMHZMTOSF5jiVFZ6xv3CqpHtexxk4l0CXlQV2+hTx5nqf4jC9v zOUX4UuDjZcdf2LaLMS/LWn0akjD9p1VlzuEp6/HWoHNqEAtpQADnCztK17BgLNsvjKl I19Bfb1VzrFyS02pjsOQ3hEO7H64AsiX0CglhidxCck1THXYFDh5KZ0O12CaQfEwwpt5 Wv9A== X-Gm-Message-State: AOAM533zp88uE2fpkkqjywBEdNrX6LQkbsC5WK0LjKV7E9gO5azx+9Os KiudT0uFse1nxgm993a0gEX62bhrUNHFBsIZUG0= X-Google-Smtp-Source: ABdhPJxFifK7rmpfZ94DX63Ct+sOAzsnGVaqnamgsJ1A8kFJ6wR+LqRIhUklwxsBXBN9MZfNX65ND5A4jq7Gb2JWEko= X-Received: by 2002:a05:6808:d47:: with SMTP id w7mr17678678oik.150.1615221212401; Mon, 08 Mar 2021 08:33:32 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Philipp Stephani Date: Mon, 8 Mar 2021 17:33:21 +0100 Message-ID: Subject: Re: bug#41988: 28.0.50; Edebug unconditionally instruments definitions with &define specs To: Stefan Monnier Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 41988-done Cc: 41988-done@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: -0.8 (/) Am Di., 2. M=C3=A4rz 2021 um 18:28 Uhr schrieb Philipp Stephani : > > Am Di., 2. M=C3=A4rz 2021 um 16:59 Uhr schrieb Stefan Monnier > : > > > > > As an example, edebug-instrument (C-u C-M-x) the following definition= : > > > > > > (defun bar () > > > (cl-flet ((foo () 1)) > > > (foo))) > > > > > > The *Messages* buffer now says > > > > > > Edebug: foo [2 times] > > > Edebug: bar > > > > I believe this is now fixed in `master`. > > At least we only get a total of 2 messages rather than "3 collapsed to = 2". > > But I don't know enough about the code coverage to be sure that the > > underlying problem you saw is also fixed. Can you confirm? > > Thanks! I'll check (hopefully in the next few days). Confirmed that the original issue is indeed fixed. From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 08 11:38:03 2021 Received: (at 41988) by debbugs.gnu.org; 8 Mar 2021 16:38:03 +0000 Received: from localhost ([127.0.0.1]:44625 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lJItP-0000en-Ke for submit@debbugs.gnu.org; Mon, 08 Mar 2021 11:38:03 -0500 Received: from mail-oo1-f51.google.com ([209.85.161.51]:44516) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lJItO-0000eH-FU for 41988@debbugs.gnu.org; Mon, 08 Mar 2021 11:38:02 -0500 Received: by mail-oo1-f51.google.com with SMTP id n19so2320848ooj.11 for <41988@debbugs.gnu.org>; Mon, 08 Mar 2021 08:38:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=DEug/6VJ1TmtnwCttqwjdKjXyyFEilNazt5cmNQ8M+o=; b=EcVNIxcOSma44chMFFUXNVkmMi7dqAUfnIuQPBeD2o3tZFlBYsIgA9eTWscvC+a6C2 5AJ4npEAB/ZJjpVOq8JZJvqTFO7clwh5FFjHi2Q6NWQQClUiAC5yRPaJTq7M/4NfePtc GCLswlgAL/fYtFVVML4b9vp45tfXmOvHpmRA3idv9Izu9GtB9gOX9+sUX8lTFI+VE7j3 JeV5q/Fwdmk+UfJ1uBmRAfDrPzpNR4XwhoBMz8oUT5MUZO6wGdP7kglBpj5HFpAtV953 ij348uS1s6WZp8PxHhlj5wMmzDSt6xRQlRFshB1v5iHKe8fBBO3bNKt9OD5eER6Napjy iXXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=DEug/6VJ1TmtnwCttqwjdKjXyyFEilNazt5cmNQ8M+o=; b=Lxa6Y1Mr7jes3XlTlS34eiX3RWgnSU9eDQRM3cmP0Jhw5ZrzwNhYwJf0t6qOoALgQT KlbxMW6eXKBjPgdPt2t3dRvhpXhgu3kY2yGbKHc6ThYaWWWa6ZePGECh6jPzax4hkvYa epphh+n7/WeUUCuv0ai+1HtweFH7uqBZRiwULOdIVPVKnJPmTZb8Mblx6qfuNyv6PjDg 1DG8A4LZAnLdfnQ3Kb7BzuZ+UyOIDPMXJKLN9+pdGdrS9qEKn+v48bk4aJnq0gyMWPQv Aow2WWrkETq5+Pcw//M6+ytiXSMdp7O18u+ueElTvlcFL3zE8UwOCXTvtUQpLSyM8eoK mzBQ== X-Gm-Message-State: AOAM531sMkoRM8gRk83uKiVFQBBLwTrSKLvcG1SriwY1BjXSz8kDl38I otjO59nTouuonSJYUFrAZ8bkxh2FJniBGPUkUuw= X-Google-Smtp-Source: ABdhPJxWg1wXcZMG8nCqcRGY7cy3XTL4tYqdpZMr/DdjX7IakwCmLaA2TTgqhbXydIJZtpwJnop+XpMs0/KEvoJKmso= X-Received: by 2002:a4a:e615:: with SMTP id f21mr19151104oot.91.1615221476826; Mon, 08 Mar 2021 08:37:56 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Philipp Stephani Date: Mon, 8 Mar 2021 17:37:45 +0100 Message-ID: Subject: Re: bug#41988: 28.0.50; Edebug unconditionally instruments definitions with &define specs To: Stefan Monnier Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 41988 Cc: 41988@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: -0.7 (/) Am Mo., 8. M=C3=A4rz 2021 um 17:33 Uhr schrieb Philipp Stephani : > > Am Di., 2. M=C3=A4rz 2021 um 18:28 Uhr schrieb Philipp Stephani > : > > > > Am Di., 2. M=C3=A4rz 2021 um 16:59 Uhr schrieb Stefan Monnier > > : > > > > > > > As an example, edebug-instrument (C-u C-M-x) the following definiti= on: > > > > > > > > (defun bar () > > > > (cl-flet ((foo () 1)) > > > > (foo))) > > > > > > > > The *Messages* buffer now says > > > > > > > > Edebug: foo [2 times] > > > > Edebug: bar > > > > > > I believe this is now fixed in `master`. > > > At least we only get a total of 2 messages rather than "3 collapsed t= o 2". > > > But I don't know enough about the code coverage to be sure that the > > > underlying problem you saw is also fixed. Can you confirm? > > > > Thanks! I'll check (hopefully in the next few days). > > Confirmed that the original issue is indeed fixed. Hmm, maybe I spoke too soon. The original issue with cl-flet is indeed fixed, but I think one likely explanation for that is that it now only has a single &define form. What about other macros that still have multiple &define forms in an &or form? Are they fixed as well? From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 08 12:41:18 2021 Received: (at 41988) by debbugs.gnu.org; 8 Mar 2021 17:41:19 +0000 Received: from localhost ([127.0.0.1]:44711 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lJJsc-0002DA-LL for submit@debbugs.gnu.org; Mon, 08 Mar 2021 12:41:18 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:10161) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lJJsb-0002Cv-5V for 41988@debbugs.gnu.org; Mon, 08 Mar 2021 12:41:17 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 99CE380229; Mon, 8 Mar 2021 12:41:11 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 20DFE804E6; Mon, 8 Mar 2021 12:41:10 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1615225270; bh=UuHKADki7FmVJuKPBzMcprq2s71Otq+p8FQ1B1piStI=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=DMi3heLXw8zpwU2T+gWszAUlPpftytMZ5/iXJuqhjOetKJlN1C4ucRngRX377tAo/ MYI+oTDScIY6wHPuSbj5gcyuGsgsE3yH/ylq/1NXaQf8903netgxHdVxkKyONBWsJ1 3o0kopJbhre5CQP5YkH1+XgbIg7GCT6oMXnvA0WLl/4QswkY1uYoUX1vRTFuc3Hd2y OsF6eaW0jWH8NfkzyHtIOXHVh1xbatZCWwBWz92uLkMrvFtwXf0Upf94d9DaGflviF mJKiRvSkDaZeElzgnHhyLlUzKb7ai9Qr1SP5TUPtuJly5XPx+F+B1tnmb5DbHoAezp ndYYDDQ+GgEyg== Received: from alfajor (unknown [216.154.43.249]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id C6EDD1201AA; Mon, 8 Mar 2021 12:41:09 -0500 (EST) From: Stefan Monnier To: Philipp Stephani Subject: Re: bug#41988: 28.0.50; Edebug unconditionally instruments definitions with &define specs Message-ID: References: Date: Mon, 08 Mar 2021 12:41:09 -0500 In-Reply-To: (Philipp Stephani's message of "Mon, 8 Mar 2021 17:37:45 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.095 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 X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41988 Cc: 41988@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 (---) > Hmm, maybe I spoke too soon. The original issue with cl-flet is indeed > fixed, but I think one likely explanation for that is that it now only > has a single &define form. What about other macros that still have > multiple &define forms in an &or form? Are they fixed as well? No, I don't think they'd be fixed either. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 14 12:32:58 2021 Received: (at 41988) by debbugs.gnu.org; 14 Mar 2021 16:32:58 +0000 Received: from localhost ([127.0.0.1]:34114 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lLTfm-0003Aa-Je for submit@debbugs.gnu.org; Sun, 14 Mar 2021 12:32:58 -0400 Received: from mail-ed1-f41.google.com ([209.85.208.41]:38803) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lLTfl-0003AN-0t for 41988@debbugs.gnu.org; Sun, 14 Mar 2021 12:32:57 -0400 Received: by mail-ed1-f41.google.com with SMTP id h13so14506419eds.5 for <41988@debbugs.gnu.org>; Sun, 14 Mar 2021 09:32:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xZyqLEkScmxCigX9+7g1FosI/5F58iUzIip1LZRiXXk=; b=OLRDVuKXrwElAM9ZR1uP9Sd5nAtVA/aqc57KlWWLZMHCgDrn7Mq4iDZzxXIO4UXipA 2sCyD72MZr3Xdhh9HdLbNXbplUXctfYWuy82rHUicXTbWWUJe/MXd2dqjw7Ul1pq25+T hRzCE+w0N2V76RE5KXqD6eu+Bgy6LyYkn3T0VSMbMi5AanoeHbs82w2JfZKezgDSU4a3 m6wKMcVN8PFvFQCNzpZd054lWJyAPryXxMpGmjDdNa1eLvhIAAi6loRyDdSFqJnXCWOV eFEDFapp0l2d3kYCNGPfa19Chx7eGfeTjrDCT5GxccmyPx6F/11HpSnva4wXONY6rbyK ILGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xZyqLEkScmxCigX9+7g1FosI/5F58iUzIip1LZRiXXk=; b=hoWH8dZYwwDj5k6nmVGfhurOXVBVzdO4ypmt+aNwaqBu6o9pBxtTIgd27wCvI1WT36 hv//dCj1SE1eREygTPb4mN8aqqoHAOGPRKDYkscntDH8+AYeNzBqWfbXqIFBP9OhslVS DZofL/PPIx/jmRGj8hG57cypbJIqHLmtgZwHV3C2a80bnzk14GuGNLP7YcZDuyfIqwTk p7/ubLVkMHu9h6PSQKoh1/4MP/JoX55luwMwPw7xEWA6cqvZACW+evEQcMfGDeSra++7 ZI2uipAbfufwtQ2FQk1qS5aKWek93ZDOLFmK9eqhv/fZaEdWBgc2/QJk58nfGCkweMsq epfA== X-Gm-Message-State: AOAM530psz3HYVaXxkk7P+GjYSSnkYde4BaOXTDawG5ejBCG795viLbQ lc8XiZz1+BPzu3G1iAvpVag= X-Google-Smtp-Source: ABdhPJyQd/2KbTNDkH8+ztIJwM5x3CeBC2GXSWwh8DKw0a0USrI5/590oj/cR2o16ALBPO9ZvUNDmQ== X-Received: by 2002:a05:6402:9:: with SMTP id d9mr25334500edu.67.1615739571069; Sun, 14 Mar 2021 09:32:51 -0700 (PDT) Received: from philipps-mbp.fritz.box ([46.128.208.19]) by smtp.gmail.com with ESMTPSA id c17sm7156993edw.32.2021.03.14.09.32.50 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 Mar 2021 09:32:50 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Subject: Re: bug#41988: 28.0.50; Edebug unconditionally instruments definitions with &define specs From: Philipp In-Reply-To: Date: Sun, 14 Mar 2021 17:32:49 +0100 Content-Transfer-Encoding: 7bit Message-Id: <6D19F14E-0133-4751-B0BD-EC2A73C1D21F@gmail.com> References: To: Stefan Monnier X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 41988 Cc: 41988@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: -0.8 (/) > Am 08.03.2021 um 18:41 schrieb Stefan Monnier : > >> Hmm, maybe I spoke too soon. The original issue with cl-flet is indeed >> fixed, but I think one likely explanation for that is that it now only >> has a single &define form. What about other macros that still have >> multiple &define forms in an &or form? Are they fixed as well? > > No, I don't think they'd be fixed either. > OK, then maybe it would make sense to reopen this bug. Do you know of a similar example that still reproduces the bug? From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 14 13:38:15 2021 Received: (at 41988) by debbugs.gnu.org; 14 Mar 2021 17:38:15 +0000 Received: from localhost ([127.0.0.1]:34143 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lLUgw-0004nc-UG for submit@debbugs.gnu.org; Sun, 14 Mar 2021 13:38:15 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:53905) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lLUgu-0004nN-NN for 41988@debbugs.gnu.org; Sun, 14 Mar 2021 13:38:13 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 131FD440940; Sun, 14 Mar 2021 13:38:07 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id CA8BD440BDA; Sun, 14 Mar 2021 13:38:05 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1615743485; bh=35OUBqCeaRRzlYVkvFbhpTu9N3g1m1I131svkybtUb8=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=HEVwhvhVwu7kdJycyi0mi+/wQztcvCchk1rGfLFePp7ZFl92HlX5h2FR3FbDKcEm9 hZpjfK0LkAsorQMfUg2uuNEDRmnW4e8q5ZUdeE8ZLL4Gr0BqrZS/LnM8eekeHWHXbi HWZt4rcBDuUOwrVKnZKTnE/glM4KOT19sfPOOmoiPTvJtfXGP17gj0rKdU3DBpbN88 4XHt/Rt5Q/Iz+/MdzWQJfgV/O8uBUOunENwXmqj9EGm+5lveHNip/n3urbthpO9jm4 R+7uG5tBCXxHNjF59giAxL6mPb2UQ8EXqLwOqlGPZGq/TwVkurXUob23LZIxsGdfdt ivBRnsXF63RgA== Received: from alfajor (unknown [216.154.43.249]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id B2A6F12020D; Sun, 14 Mar 2021 13:38:05 -0400 (EDT) From: Stefan Monnier To: Philipp Subject: Re: bug#41988: 28.0.50; Edebug unconditionally instruments definitions with &define specs Message-ID: References: <6D19F14E-0133-4751-B0BD-EC2A73C1D21F@gmail.com> Date: Sun, 14 Mar 2021 13:38:04 -0400 In-Reply-To: <6D19F14E-0133-4751-B0BD-EC2A73C1D21F@gmail.com> (Philipp's message of "Sun, 14 Mar 2021 17:32:49 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.104 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 X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41988 Cc: 41988@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 (---) >>> Hmm, maybe I spoke too soon. The original issue with cl-flet is indeed >>> fixed, but I think one likely explanation for that is that it now only >>> has a single &define form. What about other macros that still have >>> multiple &define forms in an &or form? Are they fixed as well? >> No, I don't think they'd be fixed either. > OK, then maybe it would make sense to reopen this bug. It might be easier to declare this as a known limitation. > Do you know of a similar example that still reproduces the bug? No. And I'd hope the problem can be avoided in all cases. I guess we could try and make it more "official" by imposing some kind of "cut" such that after passing a `&define` we can't backtrack. Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 18 07:19:34 2021 Received: (at 41988) by debbugs.gnu.org; 18 Mar 2021 11:19:35 +0000 Received: from localhost ([127.0.0.1]:45256 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lMqgg-0002b2-MC for submit@debbugs.gnu.org; Thu, 18 Mar 2021 07:19:34 -0400 Received: from mail-wm1-f54.google.com ([209.85.128.54]:35345) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lMqgf-0002ap-FA for 41988@debbugs.gnu.org; Thu, 18 Mar 2021 07:19:33 -0400 Received: by mail-wm1-f54.google.com with SMTP id a132-20020a1c668a0000b029010f141fe7c2so2952866wmc.0 for <41988@debbugs.gnu.org>; Thu, 18 Mar 2021 04:19:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Lgi4olm8sVRdNwPkCAMyktMtNs9jpPe+xmPB7/qzR9Y=; b=IS4yy79lnMl59iFyfhQSNHWWNz+tdeRkyi04MHxrAZL/xhkPPFH5iHrCgqWLzYy9JJ AAZxa9XOJIbPcdePVnfDVkVi9yA6mgIPuF6AQEIPa4h4s39t5P/DL/XEFHS6CvycUaBo nr7eKXYEPRdOnFau3Rc3ZPlK4uE03Qb1I1UnbtfXjLJR0l+zBYB9SCKn5rQTNGzockP6 qa8Pm4DyxN2pYVZjmjb2FHG1RS2XI+7Q66/tbXMvGnWgRriQONWDEyXwAvXZOXrRFozm MU59z2Ryhu63Lk0IV4QRSTGDEY02VJBqqET2Qcb+6c5c18uh3i4kuIxruJUXb1JHTswx PWUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Lgi4olm8sVRdNwPkCAMyktMtNs9jpPe+xmPB7/qzR9Y=; b=lyLaTMKnnyfV5MB8oC2DohbFXkXcao8LvZ1iPAvbsTrAdTw3LSiLiAl0gl1rthf1RT 67VcixCH0jYePUSNN4rMG23LVKGE4EefqpC0LJJNbngyvG8ZYK4z3ImfxjEAlYDP0U8p d9ANrvaWckkOFpVSzHNRAA+1JH53/A77QpBfY/m4u2oJ8twkGe6nsk8kVEwCFe5TJpeU 00nOcaD9ofVAIQrlVGl/2MeKxgNC2QKUNp76USIOYFFLY7EHQRygLCVX3dOa+WcyWyXE DZ3C4DKIssJ04eYxI3nH3EDgfLf5rWHoe0YIXo67ksUO7WScrs85WovO9vifhUxDuBSx egMw== X-Gm-Message-State: AOAM533QT6YPh2BgPPj15leqA3fSXt5CHQRRGJOGk1zgrGivj5dMKY7k csWOmBUHATGNI9oSr5+tRdE= X-Google-Smtp-Source: ABdhPJzw14+3HYU9xS97Alz+mDAIdIJj/u9ZlEJpU9cWpaiyS/z37HeRxD0P2OV4/CqzIUa1LlRlNg== X-Received: by 2002:a1c:4182:: with SMTP id o124mr3232443wma.61.1616066367565; Thu, 18 Mar 2021 04:19:27 -0700 (PDT) Received: from philipps-macbook-pro.fritz.box (p57aafc25.dip0.t-ipconnect.de. [87.170.252.37]) by smtp.gmail.com with ESMTPSA id w11sm2552539wrv.88.2021.03.18.04.19.26 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Mar 2021 04:19:26 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Subject: Re: bug#41988: 28.0.50; Edebug unconditionally instruments definitions with &define specs From: Philipp In-Reply-To: Date: Thu, 18 Mar 2021 12:19:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6D19F14E-0133-4751-B0BD-EC2A73C1D21F@gmail.com> To: Stefan Monnier X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 41988 Cc: 41988@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: -0.8 (/) > Am 14.03.2021 um 18:38 schrieb Stefan Monnier = : >=20 >>>> Hmm, maybe I spoke too soon. The original issue with cl-flet is = indeed >>>> fixed, but I think one likely explanation for that is that it now = only >>>> has a single &define form. What about other macros that still have >>>> multiple &define forms in an &or form? Are they fixed as well? >>> No, I don't think they'd be fixed either. >> OK, then maybe it would make sense to reopen this bug. >=20 > It might be easier to declare this as a known limitation. >=20 >> Do you know of a similar example that still reproduces the bug? >=20 > No. And I'd hope the problem can be avoided in all cases. > I guess we could try and make it more "official" by imposing some kind = of "cut" > such that after passing a `&define` we can't backtrack. >=20 =46rom looking at the code, would it be possible to achieve this by = setting edebug-gate to non-nil in the right places? If so, then this seems to be only a matter of finding the right places = ;-)= From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 18 10:02:08 2021 Received: (at 41988) by debbugs.gnu.org; 18 Mar 2021 14:02:08 +0000 Received: from localhost ([127.0.0.1]:47603 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lMtDz-0006p3-Ka for submit@debbugs.gnu.org; Thu, 18 Mar 2021 10:02:07 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:41430) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lMtDx-0006iW-3T for 41988@debbugs.gnu.org; Thu, 18 Mar 2021 10:02:05 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id B16834410B9; Thu, 18 Mar 2021 10:01:59 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 70BEA4410C9; Thu, 18 Mar 2021 10:01:58 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1616076118; bh=P5IZZKlvlUKiMUllp6IcNWQYufFDxjuWDOxlnAWIsOg=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=A3syElo3uoIkb808MHLyQkykL3rxhrIEA139UfTocnq2dGDAvm4wwM+5jr0P6SRUJ PEA5ktfCQ7q/kbZXo4a//ug7VBy23TyL9ZUAm3qf0AJLKKcTEK0hl7vX+YgtkbvwlU yy9QBv//fwuyie7PHnRJJum5k/JyFuIl3QbGzquJNXXz6ImiuoPVEmApYTgydXodbm fcGh18/p+sdpxGrbpVxcY3GIfpTSeXqCXU5SeZrNLhZbFz4my7EO6naBGyoKLzNugz AIGI3ehtbSD8SHEzTCLWX4ZG2Xiy5SRSWb2vV6LN1/DKf1sWYeErplTqROwtaKuGzm aQ+aw4my2PCWA== Received: from alfajor (unknown [216.154.43.249]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 19B4D120230; Thu, 18 Mar 2021 10:01:58 -0400 (EDT) From: Stefan Monnier To: Philipp Subject: Re: bug#41988: 28.0.50; Edebug unconditionally instruments definitions with &define specs Message-ID: References: <6D19F14E-0133-4751-B0BD-EC2A73C1D21F@gmail.com> Date: Thu, 18 Mar 2021 10:01:56 -0400 In-Reply-To: (Philipp's message of "Thu, 18 Mar 2021 12:19:26 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.103 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 X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41988 Cc: 41988@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 (---) >> No. And I'd hope the problem can be avoided in all cases. >> I guess we could try and make it more "official" by imposing some kind of "cut" >> such that after passing a `&define` we can't backtrack. > From looking at the code, would it be possible to achieve this by setting > edebug-gate to non-nil in the right places? > If so, then this seems to be only a matter of finding the right places ;-) It's possible, but: - I don't understand enough the way backtracking works in Edebug to know what `edebug-gate` does, really. - The old spec of `cl-flet` would be broken by such a change, so if we want to make such a change, we'd probably want to arrange so that it emits a clear warning. I'm not sure it's worth the trouble: the pain seems higher than the gain. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 21 09:34:20 2021 Received: (at 41988) by debbugs.gnu.org; 21 Mar 2021 13:34:20 +0000 Received: from localhost ([127.0.0.1]:53754 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lNyDk-00011E-00 for submit@debbugs.gnu.org; Sun, 21 Mar 2021 09:34:20 -0400 Received: from mail-wr1-f54.google.com ([209.85.221.54]:38906) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lNyDf-00010x-MG for 41988@debbugs.gnu.org; Sun, 21 Mar 2021 09:34:18 -0400 Received: by mail-wr1-f54.google.com with SMTP id z2so13904214wrl.5 for <41988@debbugs.gnu.org>; Sun, 21 Mar 2021 06:34:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/W9ACUyVWsAsjk6zZHSocOXyvQgZY5+CS/irokXx03o=; b=SnIC6Lg9cMSWAc89wAluOX3nG4n76lvAw8ar/8wjkOABzgP344/7Vz+8kOHsSeEp9C ehsyJr2fbhOVqiezV/KLBh5Twn4Pm1+zyEYpvBabDMzmt764oldtQMhOuTw5Kv9tNehz ZMi6H0uuHty4tBGIZjGg3e9GaDja0Jdyb+ovkOeA0mqN0/CzJIgTxph6D+i6mT7UJnAM 5ifsnYFQyybcDEMXXKbGcL68AN8anvSpm3WrliC0l4C2Nuz72kCHDUg5aACJ7YcHZ4Vc /pEY6SzR+As0sjuZFFpmHJYE69vx5T0zsUBFxho1xfv8GOtRDP/eRqzeRugl8f2BrvO2 02AQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/W9ACUyVWsAsjk6zZHSocOXyvQgZY5+CS/irokXx03o=; b=WMzbh4mtr5y7qTFkqUMBPxMJm/wxbwWDz6LbpSKYPfeDQEcMoiv+/OXrXLQ8HOiXGc tOklHkIqSB7ho43MW9IVKTdqxa4jJDSY18E5nf2hw5xWQPsfDZ1FZSbvXAV51iXWhVhU teAhOxyvHuqWLqgcswQvVgZmdmpYoivjGesLDtxzvKI7Liwn9yuJH5ojPkXJ6PeHOb6e C5aqRRDj8GEv4yN49Jgq+l8T+85zIx/11RxRz6Rv8m1KC7pVJXHdwoWHsT0A5STTU2Pw 8yopxaKpilABzx10b39Ah620IESW9h83XU/Kx8x4tB6JHuLFUrUPWgIixCZijk+8MeFL OprA== X-Gm-Message-State: AOAM532SXVqQlarDMVO0qNGd05dh5zVRLEDhCV4IgxqSqrYTwoYr5Agf TDDzcf5o1tRcLD5kgutU8ko= X-Google-Smtp-Source: ABdhPJweuzDmCnv756enes3qzlxYIz9MGNcAg8mwFiAnWusl10atL6hWldVVA5FOzpKZOyz/fnhepg== X-Received: by 2002:adf:fb05:: with SMTP id c5mr14214677wrr.302.1616333649669; Sun, 21 Mar 2021 06:34:09 -0700 (PDT) Received: from philipps-macbook-pro.fritz.box (p57aaf893.dip0.t-ipconnect.de. [87.170.248.147]) by smtp.gmail.com with ESMTPSA id n1sm19667629wro.36.2021.03.21.06.34.08 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 21 Mar 2021 06:34:09 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Subject: Re: bug#41988: 28.0.50; Edebug unconditionally instruments definitions with &define specs From: Philipp In-Reply-To: Date: Sun, 21 Mar 2021 14:34:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3619E155-8F06-4F8F-B239-121ED3D164A8@gmail.com> References: <6D19F14E-0133-4751-B0BD-EC2A73C1D21F@gmail.com> To: Stefan Monnier X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 41988 Cc: 41988@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: -0.8 (/) > Am 18.03.2021 um 15:01 schrieb Stefan Monnier = : >=20 >>> No. And I'd hope the problem can be avoided in all cases. >>> I guess we could try and make it more "official" by imposing some = kind of "cut" >>> such that after passing a `&define` we can't backtrack. >> =46rom looking at the code, would it be possible to achieve this by = setting >> edebug-gate to non-nil in the right places? >> If so, then this seems to be only a matter of finding the right = places ;-) >=20 > It's possible, but: > - I don't understand enough the way backtracking works in Edebug to = know > what `edebug-gate` does, really. It looks like you can set edebug-gate to t in edebug--match-&-spec-op = (the &define branch). That should have the same effect as a [gate ...] = construct around each &define form. > - The old spec of `cl-flet` would be broken by such a change, so if we > want to make such a change, we'd probably want to arrange so that it > emits a clear warning. Where? When setting the debug specification (byte-run--set-debug), or = in some other place? >=20 > I'm not sure it's worth the trouble: the pain seems higher than the = gain. >=20 This bug is rather nasty when it's hit (it took me quite a while to = debug/hunt down), so I think it would be reasonable to prevent. We = already disable backtracking for literal symbols, and I think forms that = require multiple &define forms with backtracking should be exceedingly = rare and can be rewritten as you did with cl-flet.= From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 21 10:37:57 2021 Received: (at 41988) by debbugs.gnu.org; 21 Mar 2021 14:37:57 +0000 Received: from localhost ([127.0.0.1]:55233 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lNzDJ-0002ur-2t for submit@debbugs.gnu.org; Sun, 21 Mar 2021 10:37:57 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:8717) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lNzDE-0002uU-UT for 41988@debbugs.gnu.org; Sun, 21 Mar 2021 10:37:55 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 5B83D8024F; Sun, 21 Mar 2021 10:37:47 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id DBE6980385; Sun, 21 Mar 2021 10:37:45 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1616337465; bh=PBJ6BSrYjf/JVPeSB8LqLXOYjF8HeAXKqTQUESEfGx4=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=U+RHTNOpdKXOFThU0yALyVp6AtDyXIDmo6ohvCDkbR2R0MKJBHHtfMcRRB1PEE/Dy c/RkpC/zTuYC7rCJ3imyvwepHo4/oONDtgF9/A3nmpvQwyXYrpavPbcRSETphWzCg+ zCH0sqK4RXmSHmqhmvE6IBB4taXgi/70dSSzSb3N8+u+3JE4IpviVQjtZsgD5IdmJE CbG6IZT5iIdJTDsxlmJlbnxNICGgUoUqtxEITCKuGwDPmJmp8909qSOcdxzp33MKa5 tpsiDk3C00TfPkDtpHVSgwgjdUfaNDR1jGqQl4bhf2Ttjc/rpmr0iujbZQlcspTpeR t+5qMOiWq4jAg== Received: from alfajor (unknown [216.154.43.249]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id B3D7312016F; Sun, 21 Mar 2021 10:37:45 -0400 (EDT) From: Stefan Monnier To: Philipp Subject: Re: bug#41988: 28.0.50; Edebug unconditionally instruments definitions with &define specs Message-ID: References: <6D19F14E-0133-4751-B0BD-EC2A73C1D21F@gmail.com> <3619E155-8F06-4F8F-B239-121ED3D164A8@gmail.com> Date: Sun, 21 Mar 2021 10:37:44 -0400 In-Reply-To: <3619E155-8F06-4F8F-B239-121ED3D164A8@gmail.com> (Philipp's message of "Sun, 21 Mar 2021 14:34:08 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.096 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 X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41988 Cc: 41988@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 (---) >> - The old spec of `cl-flet` would be broken by such a change, so if we >> want to make such a change, we'd probably want to arrange so that it >> emits a clear warning. > Where? When setting the debug specification (byte-run--set-debug), or in some other place? The old spec was of the form (or (&define name form) (&define name sexp body)), so if we put a gate at `&define`, this will probably fail to even match the (&define name sexp body) part. [ Disclaimer: I don't understand the precise semantics of `gate`, tho I do remember using it once via trial-and-error. So maybe it wouldn't prevent it, but if doesn't prevent it, then it doesn't likely "fix" our problem ;-) ] >> I'm not sure it's worth the trouble: the pain seems higher than the gain. > This bug is rather nasty when it's hit (it took me quite a while to > debug/hunt down), Could you remind me what was this nasty outcome? In the context of Edebug the effect is negligible (it just emits a spurious message about defining an extra something, but other than that debugging works just fine). > so I think it would be reasonable to prevent. We already > disable backtracking for literal symbols, and I think forms that require > multiple &define forms with backtracking should be exceedingly rare and can > be rewritten as you did with cl-flet. Emitting a warning would be much more helpful than just silently "cut"ting the backtracking. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 04 14:40:29 2021 Received: (at 41988) by debbugs.gnu.org; 4 Apr 2021 18:40:29 +0000 Received: from localhost ([127.0.0.1]:36452 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lT7fh-0005gj-Fc for submit@debbugs.gnu.org; Sun, 04 Apr 2021 14:40:29 -0400 Received: from mail-oo1-f53.google.com ([209.85.161.53]:39725) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lT7fg-0005gU-9D for 41988@debbugs.gnu.org; Sun, 04 Apr 2021 14:40:28 -0400 Received: by mail-oo1-f53.google.com with SMTP id r17-20020a4acb110000b02901b657f28cdcso2427524ooq.6 for <41988@debbugs.gnu.org>; Sun, 04 Apr 2021 11:40:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=tWRcDBDJKn9qLaqsRWAueWctRvLL9CP5CJfSHYk+sRw=; b=ZUv+frYYHXWUAd5c6V+TDkGxtLqF7xBRo6OC8nN1uo8NWpGjeTzwNlh7i8WisTcLJd Q+z5sOMYeSV9P8AiBoToWQGmmXZrwpqf9amooZO2zWVrK2H16lAxY6DtfYdo0npHnnxo 9/AyzY3Jw8H58503snB/M28PpWknMHNB5HGLD+qNHHDuTI37UuL4EKuQ29VGRIO/lu2T LSdzWpnlBktbXkONONnl/5MZksz15zNPz/eC9AU3Mvgt6r3FFL0Q9Jzx3a1R1Y4lDj7T 1N73vYs+7jGb/o3n/d2VlCBqZNteyfNnSqr4i1pcpVzyibDdVqxLxAyJtZsNPjXO5aQw O2sQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=tWRcDBDJKn9qLaqsRWAueWctRvLL9CP5CJfSHYk+sRw=; b=W19cjTHMao9WTbROywV2F6sSoYvE1tGuTGb3Vhq2bCdCvp/O0iiSFv97vkuuVeJs3Z 2Fqeu27gBXGnEKh//XY6Bf4znk/6Ch+4gyYEjOBPoVJHm2BzNH55yO0RC7QGot0jsoJy LlczHJGwBYDZAxxd7NpjaXyLuu2/paRgvNktVPHGKi8BBatZJRy+e0lDbgK5/+B4ZK+f 93rBrgwZIHE0As93D4TZXYC/ThCJKrxgSjYNtaLOcJAHqKtOZ/zqURwXqNhiIP50NP0w yTqN58PQy+MQElARbggOVWF9ie8jPDAefS/pm+PokQ3P8xFxfvttXALMb4443+r32LRp eZGA== X-Gm-Message-State: AOAM530uwdK8935dQBPa923J/FqADVLaw3Zdrw0rbqcicugIVkxBEUOR hzZ+Cq1r+wBJpnJpoKkNhWAy5AD9cHpzLJYRtAo= X-Google-Smtp-Source: ABdhPJzxo0490g1hkhBdZ4cepQezzB/aZuHgO0GqTMK5EtJ5mH7aCEoEInhI99fsepXCJanhI1PAySlHCsxcW0EB+FY= X-Received: by 2002:a4a:bd1a:: with SMTP id n26mr19503741oop.45.1617561622524; Sun, 04 Apr 2021 11:40:22 -0700 (PDT) MIME-Version: 1.0 References: <6D19F14E-0133-4751-B0BD-EC2A73C1D21F@gmail.com> <3619E155-8F06-4F8F-B239-121ED3D164A8@gmail.com> In-Reply-To: From: Philipp Stephani Date: Sun, 4 Apr 2021 20:40:11 +0200 Message-ID: Subject: Re: bug#41988: 28.0.50; Edebug unconditionally instruments definitions with &define specs To: Stefan Monnier Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 41988 Cc: 41988@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: -0.8 (/) Am So., 21. M=C3=A4rz 2021 um 15:37 Uhr schrieb Stefan Monnier : > > >> - The old spec of `cl-flet` would be broken by such a change, so if we > >> want to make such a change, we'd probably want to arrange so that it > >> emits a clear warning. > > Where? When setting the debug specification (byte-run--set-debug), or = in some other place? > > The old spec was of the form (or (&define name form) (&define name sexp > body)), so if we put a gate at `&define`, this will probably fail to even= match > the (&define name sexp body) part. Correct, this would turn a mismatch into a hard error. > > [ Disclaimer: I don't understand the precise semantics of `gate`, tho > I do remember using it once via trial-and-error. So maybe it wouldn't > prevent it, but if doesn't prevent it, then it doesn't likely "fix" > our problem ;-) ] AIUI the semantics of "gate" aren't that complex, it just means "don't backtrack beyond this point." > > >> I'm not sure it's worth the trouble: the pain seems higher than the ga= in. > > This bug is rather nasty when it's hit (it took me quite a while to > > debug/hunt down), > > Could you remind me what was this nasty outcome? The original bug report was https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D41853 (extremely subtle bug due to mismatch between frequency and offset vector). I don't know whether that problem would appear here as well, but it's nasty enough that I'd like to prevent duplicate definitions altogether. > In the context of > Edebug the effect is negligible (it just emits a spurious message about > defining an extra something, but other than that debugging works just fin= e). That's only true if edebug-new-definition-function handles the "duplicate definition" case well. For example, to prevent bug#41853 I bail out on duplicate definitions in https://github.com/phst/rules_elisp/blob/b67339e66fed8117dc26d4d2fb2ad321c6= 6a3632/elisp/ert/runner.el#L127-L136; that doesn't work if this bug isn't fixed. > > > so I think it would be reasonable to prevent. We already > > disable backtracking for literal symbols, and I think forms that requir= e > > multiple &define forms with backtracking should be exceedingly rare and= can > > be rewritten as you did with cl-flet. > > Emitting a warning would be much more helpful than just silently > "cut"ting the backtracking. A gate isn't silent, it would cause a hard error in this case. From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 04 16:16:32 2021 Received: (at 41988) by debbugs.gnu.org; 4 Apr 2021 20:16:33 +0000 Received: from localhost ([127.0.0.1]:36525 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lT9Ae-000579-Fg for submit@debbugs.gnu.org; Sun, 04 Apr 2021 16:16:32 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:21239) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lT9Ab-0004zg-4m for 41988@debbugs.gnu.org; Sun, 04 Apr 2021 16:16:31 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id B51E280695; Sun, 4 Apr 2021 16:16:23 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 131BD8070D; Sun, 4 Apr 2021 16:16:18 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1617567378; bh=wSsMZz0/L/9so0l5w3jl5wk06YAJY7CHzFL10AfPyq8=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=JdM8622J7nejrSkz/ZP3yM2OakvjUVGsbd7X8EO+qO60GTFI3OD8F4YGtzHgJECNt 18ynU3L6Jdmz9Zmc/ae1wPqbwzguyrpu/qR5pmIDqePcsZdMoyu8qGHe/7r96++SX8 BEP4OEkr3pJFtVe9huORYYmR8FH7mV8HOU9M7UXblHpuSOtVqpWYCNlvX2zTvbDcRg QuUSJudp1PySFm6SQdHeCuLWaBFvyDe04lDLUtqk1ex4XD9mmFbdla8e6SZCB9BOYr Qq4qcD5kMD1UBgaLTLMHJULf4fstMbbUwOd6unU1H2CsgEDcW5IlttxAGC9WVGmfXi bdmE9X1Ju5LtQ== Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D10EC120058; Sun, 4 Apr 2021 16:16:17 -0400 (EDT) From: Stefan Monnier To: Philipp Stephani Subject: Re: bug#41988: 28.0.50; Edebug unconditionally instruments definitions with &define specs Message-ID: References: <6D19F14E-0133-4751-B0BD-EC2A73C1D21F@gmail.com> <3619E155-8F06-4F8F-B239-121ED3D164A8@gmail.com> Date: Sun, 04 Apr 2021 16:16:16 -0400 In-Reply-To: (Philipp Stephani's message of "Sun, 4 Apr 2021 20:40:11 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.048 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 X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41988 Cc: 41988@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 (---) >> [ Disclaimer: I don't understand the precise semantics of `gate`, tho >> I do remember using it once via trial-and-error. So maybe it wouldn't >> prevent it, but if doesn't prevent it, then it doesn't likely "fix" >> our problem ;-) ] > AIUI the semantics of "gate" aren't that complex, it just means "don't > backtrack beyond this point." [ Yes, that's the part I understand. But it's not clear where backtracking is possible and where it's not. At least, the code that I saw in edebug.el didn't match my expectations back when I looked at it, hence my not feeling quite sure what the semantics are (and/or should be). IIRC the issue was that the scope of that effect wasn't clear: if you think of Prolog's cut, its effect is local to a particular definition, whereas I think the scope of `gate` is not nearly as clear because there isn't such a notion of "definition". ] >> >> I'm not sure it's worth the trouble: the pain seems higher than the gain. >> > This bug is rather nasty when it's hit (it took me quite a while to >> > debug/hunt down), >> Could you remind me what was this nasty outcome? > The original bug report was > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41853 (extremely subtle > bug due to mismatch between frequency and offset vector). Thanks, that's worst than I thought indeed. >> > so I think it would be reasonable to prevent. We already >> > disable backtracking for literal symbols, and I think forms that require >> > multiple &define forms with backtracking should be exceedingly rare and can >> > be rewritten as you did with cl-flet. >> Emitting a warning would be much more helpful than just silently >> "cut"ting the backtracking. > A gate isn't silent, it would cause a hard error in this case. What I meant is that a gate would just make the old cl-flet spec fail in most cases, with no explanation why that spec now fails even though it worked in the past. Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 05 10:32:35 2021 Received: (at 41988) by debbugs.gnu.org; 5 Apr 2021 14:32:35 +0000 Received: from localhost ([127.0.0.1]:38384 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lTQHL-0006Ae-3T for submit@debbugs.gnu.org; Mon, 05 Apr 2021 10:32:35 -0400 Received: from mail-oi1-f174.google.com ([209.85.167.174]:47065) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lTQHJ-0006AR-Q0 for 41988@debbugs.gnu.org; Mon, 05 Apr 2021 10:32:34 -0400 Received: by mail-oi1-f174.google.com with SMTP id m13so11775682oiw.13 for <41988@debbugs.gnu.org>; Mon, 05 Apr 2021 07:32:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=a22nBunIT0Zfr/Wi6yaMYBN+gT4bCqbjFDv19v+LuyM=; b=B9LZA7ML3NzaqfG/XQuTAXOeue2JlwLTM47SHbsqpBPKk2awt4tqujBFAuaCXMYobP L9+uo9MgnMgTrE/qFqIU05ratmpeCUf2r7vjb6qpOVdY3g5x9ROOle4hmMcqvr6wcZPk aCE4lFoqzam8U7hNUEYRBAmPgj3GPXCUpqSmQlJeVIFNvFen5ss+zOSsyrhKfxFLv9HJ HEfbxL2RbWk/Gm2xcFjKeXH5SPkJtCrfnedKjSMQvC0W7ZdqdDPY6Mqct+FKn62h3QPM 26XsS8dsQZRlzNAVEvLe5zDJMe/BAZHJiGvlw8Q7zyLzU+cuRu1oMNRTmVX5RaBDciGp cjfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=a22nBunIT0Zfr/Wi6yaMYBN+gT4bCqbjFDv19v+LuyM=; b=rsK33gxIDvuhP5DkJUyv+PDsKqhhgc5ga6IYw7VwIdbZU97gQmqTBYyrcKEyWuvQoE auIuZWqOxXg2v6n/kQLu0I0sbEe/Az0Xf7Q6rCYIQuIVGl5eCTyKURsxUB0sJfyN8mlv VUOakyHtYee59nFxzIBsVUgvC/KctygDA3Qhy0Ye6pYrVJ/6ZSjZMAkbrSc5iLFITE4h rFJMovAfviJae51+7RI1c8jbxVkDuzJQvOX3mrZ5jBsN1ib0dQorPB2dh1Pahma/m2et xT9fWgD+VFfEKFou/r9slZp5ZWJNpdp2eVf4/kiUT9VEfQkcBGvarAkn68dfT47loDFk BIfw== X-Gm-Message-State: AOAM530tiirpHgtqN74esLpZZ+JBVEFbEabv9iiwzxR7Je0JooSjbDor 03rg7Qb30GvXWdHu5G57SP8iDk7Irf+3X45p5E4= X-Google-Smtp-Source: ABdhPJwECvp2eg1NKI9YfIIKnmkxvsQfGpJXBR0LE9F/vmbNV3h8tbKh2gWLZThNARut9/i0OFpdo9vMdNpwQkhomYw= X-Received: by 2002:aca:6543:: with SMTP id j3mr18510830oiw.158.1617633147856; Mon, 05 Apr 2021 07:32:27 -0700 (PDT) MIME-Version: 1.0 References: <6D19F14E-0133-4751-B0BD-EC2A73C1D21F@gmail.com> <3619E155-8F06-4F8F-B239-121ED3D164A8@gmail.com> In-Reply-To: From: Philipp Stephani Date: Mon, 5 Apr 2021 16:32:16 +0200 Message-ID: Subject: Re: bug#41988: 28.0.50; Edebug unconditionally instruments definitions with &define specs To: Stefan Monnier Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 41988 Cc: 41988@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: -0.8 (/) Am So., 4. Apr. 2021 um 22:16 Uhr schrieb Stefan Monnier : > > >> [ Disclaimer: I don't understand the precise semantics of `gate`, tho > >> I do remember using it once via trial-and-error. So maybe it wouldn't > >> prevent it, but if doesn't prevent it, then it doesn't likely "fix" > >> our problem ;-) ] > > AIUI the semantics of "gate" aren't that complex, it just means "don't > > backtrack beyond this point." > > [ Yes, that's the part I understand. But it's not clear where > backtracking is possible and where it's not. At least, the code that > I saw in edebug.el didn't match my expectations back when I looked at > it, hence my not feeling quite sure what the semantics are (and/or > should be). > IIRC the issue was that the scope of that effect wasn't clear: if you > think of Prolog's cut, its effect is local to a particular definition, > whereas I think the scope of `gate` is not nearly as clear because > there isn't such a notion of "definition". ] I agree that the code isn't terribly clear and probably has some bugs. However, the "prevent backtracking through gates" seems to work at least somewhat (experimentally, in this case I can turn the double definition into an error). > >> > so I think it would be reasonable to prevent. We already > >> > disable backtracking for literal symbols, and I think forms that require > >> > multiple &define forms with backtracking should be exceedingly rare and can > >> > be rewritten as you did with cl-flet. > >> Emitting a warning would be much more helpful than just silently > >> "cut"ting the backtracking. > > A gate isn't silent, it would cause a hard error in this case. > > What I meant is that a gate would just make the old cl-flet spec fail in > most cases, with no explanation why that spec now fails even though it > worked in the past. Yes, we'd need to at least announce the change in NEWS as an incompatible Lisp change. However, I think overall that's still better than the current situation: with your fix to cl-flet the problematic constructs shouldn't occur any more in the Emacs codebase, and I wouldn't expect such constructs to be very frequent "in the wild", so the overall breakage would be very small, and if it can avoid similarly subtle bugs then I think it's warranted. From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 10 11:07:58 2021 Received: (at 41988) by debbugs.gnu.org; 10 Apr 2021 15:07:58 +0000 Received: from localhost ([127.0.0.1]:53038 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lVFDJ-0000ap-T9 for submit@debbugs.gnu.org; Sat, 10 Apr 2021 11:07:58 -0400 Received: from mail-wm1-f43.google.com ([209.85.128.43]:37668) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lVFDH-0000aZ-KG for 41988@debbugs.gnu.org; Sat, 10 Apr 2021 11:07:56 -0400 Received: by mail-wm1-f43.google.com with SMTP id g66-20020a1c39450000b0290125d187ba22so3942438wma.2 for <41988@debbugs.gnu.org>; Sat, 10 Apr 2021 08:07:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=VKhYDmh4zFGMPNMDL4yIYUbG84J+HjHt0euao4Mt5oI=; b=VXbt4tVptlin+Gr+r/mdCbzfWEsZHa6ZXTvOCR0cSUHf9689rvVZAQX4tkOegU4k78 TA3E/pSRybFuTpP9rdzJG1oH+FtdGGZJ/94aw9Mdjgd/wK2y5v2TzRZlOSzLQb5WaQoB gPHGPNK2ZpXAPgi3bMDBQDwDSeTMq6qmNjHjErzK3XK4hN8TyT+9Ub8l/vmoMzw5i3Yh 8braU12+oXWUlMNvPErD9UfkxvQSNKiCCB92xoG5Y6Gc8Tc8pUAlBLw2Bqw97p6TAfGj ASo93QzA4kBMuPZtbQXMaVGYl0GE9CUsLPGCn/u7JVXR0Q3a1iuVubvygbAcPbdavw8d XiiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=VKhYDmh4zFGMPNMDL4yIYUbG84J+HjHt0euao4Mt5oI=; b=gvM9mL5kvgtE3OZHb6CzwLVSCafHOBDyio9upOUUS4W6ZKatYmMtN2xAxiuTpiWdxB YCoVpaJfmdhGSgDeXHGE9MyWSJl53UWUpkRsJ82mNJZXd8eYQGm0lcKgBqQUe1YLyqsf uGAqV878Pc+/URKT3Peu1b2ojd9drPMqmlRXg3xjk7p+iB9TijEbXL206I7ss9hnSbHD Bd5iPHbrgmR0I22e0m351ioPFKMeQcGn3rkhflPrujh4zjBB3IPXg7h0gvXcJdEWOInw ABwQWUO3ckMkJ4nrnh61XvUAg/bmNXeGnpUFufyWW7TuIktiIj+37//rWpNW1B3Fa5B2 9apQ== X-Gm-Message-State: AOAM5308IzHpRYghhaM9jtFscdXoqy07JKA5ZiE1OHkOJJXWLdQh8udc O6pA/N71tpmz/K9mf979ET4= X-Google-Smtp-Source: ABdhPJyR6R8nj7atYPhaMLgNTy2Mt8wyRmAtagQudQRxRxb0XUslPMI4BPHalAbpxScgxy98D950qQ== X-Received: by 2002:a7b:cbc4:: with SMTP id n4mr19022582wmi.153.1618067269773; Sat, 10 Apr 2021 08:07:49 -0700 (PDT) Received: from philipps-macbook-pro.fritz.box (p57997a31.dip0.t-ipconnect.de. [87.153.122.49]) by smtp.gmail.com with ESMTPSA id w22sm8145629wmc.13.2021.04.10.08.07.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 10 Apr 2021 08:07:49 -0700 (PDT) From: Philipp Message-Id: Content-Type: multipart/mixed; boundary="Apple-Mail=_0FA6AC35-A661-4A8B-A5A4-E683CEB3EE33" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Subject: Re: bug#41988: 28.0.50; Edebug unconditionally instruments definitions with &define specs Date: Sat, 10 Apr 2021 17:07:48 +0200 In-Reply-To: To: Stefan Monnier References: <6D19F14E-0133-4751-B0BD-EC2A73C1D21F@gmail.com> <3619E155-8F06-4F8F-B239-121ED3D164A8@gmail.com> X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 41988 Cc: 41988@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: -0.8 (/) --Apple-Mail=_0FA6AC35-A661-4A8B-A5A4-E683CEB3EE33 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > Am 05.04.2021 um 16:32 schrieb Philipp Stephani = : >=20 >>>>> so I think it would be reasonable to prevent. We already >>>>> disable backtracking for literal symbols, and I think forms that = require >>>>> multiple &define forms with backtracking should be exceedingly = rare and can >>>>> be rewritten as you did with cl-flet. >>>> Emitting a warning would be much more helpful than just silently >>>> "cut"ting the backtracking. >>> A gate isn't silent, it would cause a hard error in this case. >>=20 >> What I meant is that a gate would just make the old cl-flet spec fail = in >> most cases, with no explanation why that spec now fails even though = it >> worked in the past. >=20 > Yes, we'd need to at least announce the change in NEWS as an > incompatible Lisp change. However, I think overall that's still better > than the current situation: with your fix to cl-flet the problematic > constructs shouldn't occur any more in the Emacs codebase, and I > wouldn't expect such constructs to be very frequent "in the wild", so > the overall breakage would be very small, and if it can avoid > similarly subtle bugs then I think it's warranted. Here's a patch. --Apple-Mail=_0FA6AC35-A661-4A8B-A5A4-E683CEB3EE33 Content-Disposition: attachment; filename=0001-Edebug-Disable-backtracking-when-hitting-a-define-ke.patch Content-Type: application/octet-stream; x-unix-mode=0644; name="0001-Edebug-Disable-backtracking-when-hitting-a-define-ke.patch" Content-Transfer-Encoding: quoted-printable =46rom=209e2183edea41adf275f057a75232ea0b2c51e726=20Mon=20Sep=2017=20= 00:00:00=202001=0AFrom:=20Philipp=20Stephani=20=0ADate:=20= Thu,=2018=20Mar=202021=2012:40:08=20+0100=0ASubject:=20[PATCH]=20Edebug:=20= Disable=20backtracking=20when=20hitting=20a=20&define=20keyword.=0A=0A= Edebug=20doesn't=20deal=20well=20with=20backtracking=20out=20of=20= definitions,=20see=0ABug#41988.=20=20Rather=20than=20trying=20to=20= support=20this=20rare=20situation=20(e.g.=20by=0Aimplementing=20a=20= multipass=20parser),=20prevent=20it=20by=20adding=20an=20implicit=0A= gate.=0A=0A*=20lisp/emacs-lisp/edebug.el=20(edebug--match-&-spec-op):=20= Disable=0Abacktracking=20when=20hitting=20a=20&define=20keyword.=0A=0A*=20= test/lisp/emacs-lisp/edebug-tests.el=0A(edebug-tests-duplicate-&define):=20= New=20unit=20test.=0A(edebug-tests--duplicate-&define):=20New=20helper=20= macro.=0A=0A*=20doc/lispref/edebug.texi=20(Backtracking):=20Mention=20= &define=20in=20the=20list=0Aof=20constructs=20that=20disable=20= backtracking.=0A=0A*=20etc/NEWS:=20Document=20new=20behavior.=0A---=0A=20= doc/lispref/edebug.texi=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=2010=20= +++++-----=0A=20etc/NEWS=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20|=20=203=20+++=0A=20= lisp/emacs-lisp/edebug.el=20=20=20=20=20=20=20=20=20=20=20=20|=2018=20= ++++++++++--------=0A=20test/lisp/emacs-lisp/edebug-tests.el=20|=2025=20= +++++++++++++++++++++++++=0A=204=20files=20changed,=2043=20= insertions(+),=2013=20deletions(-)=0A=0Adiff=20--git=20= a/doc/lispref/edebug.texi=20b/doc/lispref/edebug.texi=0Aindex=20= 8942f55aff..323130f237=20100644=0A---=20a/doc/lispref/edebug.texi=0A+++=20= b/doc/lispref/edebug.texi=0A@@=20-1510,11=20+1510,11=20@@=20Backtracking=0A= =20must=20be=20in=20the=20form=20itself=20rather=20than=20at=20a=20= higher=20level.=0A=20=0A=20Backtracking=20is=20also=20disabled=20after=20= successfully=20matching=20a=20quoted=0A-symbol=20or=20string=20= specification,=20since=20this=20usually=20indicates=20a=0A-recognized=20= construct.=20=20But=20if=20you=20have=20a=20set=20of=20alternative=20= constructs=20that=0A-all=20begin=20with=20the=20same=20symbol,=20you=20= can=20usually=20work=20around=20this=0A-constraint=20by=20factoring=20= the=20symbol=20out=20of=20the=20alternatives,=20e.g.,=0A-@code{["foo"=20= &or=20[first=20case]=20[second=20case]=20...]}.=0A+symbol,=20string=20= specification,=20or=20@code{&define}=20keyword,=20since=20this=0A= +usually=20indicates=20a=20recognized=20construct.=20=20But=20if=20you=20= have=20a=20set=20of=0A+alternative=20constructs=20that=20all=20begin=20= with=20the=20same=20symbol,=20you=20can=0A+usually=20work=20around=20= this=20constraint=20by=20factoring=20the=20symbol=20out=20of=20the=0A= +alternatives,=20e.g.,=20@code{["foo"=20&or=20[first=20case]=20[second=20= case]=20...]}.=0A=20=0A=20Most=20needs=20are=20satisfied=20by=20these=20= two=20ways=20that=20backtracking=20is=0A=20automatically=20disabled,=20= but=20occasionally=20it=20is=20useful=20to=20explicitly=0Adiff=20--git=20= a/etc/NEWS=20b/etc/NEWS=0Aindex=20a0f05d8cf1..9ae3740482=20100644=0A---=20= a/etc/NEWS=0A+++=20b/etc/NEWS=0A@@=20-2524,6=20+2524,9=20@@=20back=20in=20= Emacs=2023.1.=20=20The=20affected=20functions=20are:=20'make-obsolete',=0A= =20=0A=20**=20The=20'values'=20variable=20is=20now=20obsolete.=0A=20=0A= +**=20The=20'&define'=20keyword=20in=20an=20Edebug=20specification=20now=20= disables=0A+backtracking.=0A+=0A=20=0C=0A=20*=20Lisp=20Changes=20in=20= Emacs=2028.1=0A=20=0Adiff=20--git=20a/lisp/emacs-lisp/edebug.el=20= b/lisp/emacs-lisp/edebug.el=0Aindex=20f1455ffe73..365bc74874=20100644=0A= ---=20a/lisp/emacs-lisp/edebug.el=0A+++=20b/lisp/emacs-lisp/edebug.el=0A= @@=20-1942,14=20+1942,16=20@@=20edebug--match-&-spec-op=0A=20=20=20;;=20= Normally,=20&define=20is=20interpreted=20specially=20other=20places.=0A=20= =20=20;;=20This=20should=20only=20be=20called=20inside=20of=20a=20spec=20= list=20to=20match=20the=20remainder=0A=20=20=20;;=20of=20the=20current=20= list.=20=20e.g.=20("lambda"=20&define=20args=20def-body)=0A-=20=20=20= (edebug-make-form-wrapper=0A-=20=20=20=20cursor=0A-=20=20=20=20= (edebug-before-offset=20cursor)=0A-=20=20=20=20;;=20Find=20the=20last=20= offset=20in=20the=20list.=0A-=20=20=20=20(let=20((offsets=20= (edebug-cursor-offsets=20cursor)))=0A-=20=20=20=20=20=20(while=20(consp=20= offsets)=20(setq=20offsets=20(cdr=20offsets)))=0A-=20=20=20=20=20=20= offsets)=0A-=20=20=20=20specs))=0A+=20=20(prog1=20= (edebug-make-form-wrapper=0A+=20=20=20=20=20=20=20=20=20=20cursor=0A+=20=20= =20=20=20=20=20=20=20=20(edebug-before-offset=20cursor)=0A+=20=20=20=20=20= =20=20=20=20=20;;=20Find=20the=20last=20offset=20in=20the=20list.=0A+=20=20= =20=20=20=20=20=20=20=20(let=20((offsets=20(edebug-cursor-offsets=20= cursor)))=0A+=20=20=20=20=20=20=20=20=20=20=20=20(while=20(consp=20= offsets)=20(setq=20offsets=20(cdr=20offsets)))=0A+=20=20=20=20=20=20=20=20= =20=20=20=20offsets)=0A+=20=20=20=20=20=20=20=20=20=20specs)=0A+=20=20=20= =20;;=20Stop=20backtracking=20here=20(Bug#41988).=0A+=20=20=20=20(setq=20= edebug-gate=20t)))=0A=20=0A=20(cl-defmethod=20edebug--match-&-spec-op=20= ((_=20(eql=20&name))=20cursor=20specs)=0A=20=20=20"Compute=20the=20name=20= for=20`&name=20SPEC=20FUN`=20spec=20operator.=0Adiff=20--git=20= a/test/lisp/emacs-lisp/edebug-tests.el=20= b/test/lisp/emacs-lisp/edebug-tests.el=0Aindex=20dcb261c2eb..7d45432e57=20= 100644=0A---=20a/test/lisp/emacs-lisp/edebug-tests.el=0A+++=20= b/test/lisp/emacs-lisp/edebug-tests.el=0A@@=20-1061,5=20+1061,30=20@@=20= edebug-tests-duplicate-symbol-backtrack=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20"edebug-anon10001"=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= "edebug-tests-duplicate-symbol-backtrack"))))))=0A=20=0A+(defmacro=20= edebug-tests--duplicate-&define=20(_arg)=0A+=20=20"Helper=20macro=20for=20= the=20ERT=20test=20`edebug-tests-duplicate-&define'.=0A+The=20Edebug=20= specification=20is=20similar=20to=20the=20one=20used=20by=20`cl-flet'=0A= +previously;=20see=20Bug#41988."=0A+=20=20(declare=20(debug=20(&or=20= (&define=20name=20function-form)=20(defun)))))=0A+=0A+(ert-deftest=20= edebug-tests-duplicate-&define=20()=0A+=20=20"Check=20that=20Edebug=20= doesn't=20backtrack=20out=20of=20`&define'=20forms.=0A+This=20avoids=20= potential=20duplicate=20definitions=20(Bug#41988)."=0A+=20=20= (with-temp-buffer=0A+=20=20=20=20(print=20'(defun=20= edebug-tests-duplicate-&define=20()=0A+=20=20=20=20=20=20=20=20=20=20=20=20= =20=20(edebug-tests--duplicate-&define=0A+=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20(edebug-tests-duplicate-&define-inner=20()=20nil)))=0A+=20=20= =20=20=20=20=20=20=20=20=20(current-buffer))=0A+=20=20=20=20(let*=20= ((edebug-all-defs=20t)=0A+=20=20=20=20=20=20=20=20=20=20=20= (edebug-initial-mode=20'Go-nonstop)=0A+=20=20=20=20=20=20=20=20=20=20=20= (instrumented-names=20())=0A+=20=20=20=20=20=20=20=20=20=20=20= (edebug-new-definition-function=0A+=20=20=20=20=20=20=20=20=20=20=20=20= (lambda=20(name)=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20(when=20= (memq=20name=20instrumented-names)=0A+=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20(error=20"Duplicate=20definition=20of=20`%s'"=20name))=0A+=20= =20=20=20=20=20=20=20=20=20=20=20=20=20(push=20name=20= instrumented-names)=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20= (edebug-new-definition=20name))))=0A+=20=20=20=20=20=20(should-error=20= (eval-buffer)=20:type=20'invalid-read-syntax))))=0A+=0A=20(provide=20= 'edebug-tests)=0A=20;;;=20edebug-tests.el=20ends=20here=0A--=20=0A2.24.3=20= (Apple=20Git-128)=0A=0A= --Apple-Mail=_0FA6AC35-A661-4A8B-A5A4-E683CEB3EE33-- From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 10 11:52:03 2021 Received: (at 41988) by debbugs.gnu.org; 10 Apr 2021 15:52:03 +0000 Received: from localhost ([127.0.0.1]:53071 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lVFty-0001du-Lg for submit@debbugs.gnu.org; Sat, 10 Apr 2021 11:52:03 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:57992) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lVFtw-0001dP-AF for 41988@debbugs.gnu.org; Sat, 10 Apr 2021 11:52:01 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id A3E1F1001D2; Sat, 10 Apr 2021 11:51:54 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 85A861000DA; Sat, 10 Apr 2021 11:51:52 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1618069912; bh=csAUf5IAr9DUxpEtYDhR7JxBQ2/L2e0s+H90017RHSk=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=g6GWvu54HUGkK8tRzc3AsbIoziqqWBfi4az2aLJAwWgBARDzG+5cr5qUo4C3ciWGI BdQqm6KYY2+umUgwAxR7ysETveLFZ/hc6s3E3HIsFtSxDt6LdOBDjEkXa1tqbk605e OEMgpEo3i9XTUEUmQu+Asm9iXKH4qv7QTr2rz6n2p7PBNbK2XY9e4AkMCsLuPZOvh/ ImzjmwIVe4rFxrHh7DBc8Jo8tEhGLlPhZrXk0n6xdlRFkFx9w9P0QZek4wsSPvCuPJ 7tRMk5jnHCpTqd6JfDHQYFXdlhHDexlmGuGLWvBZCt5zcgwNT45aSD0W9Q5bT7sA/X Sy5KEZiPbWGNw== Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 54CC8120228; Sat, 10 Apr 2021 11:51:52 -0400 (EDT) From: Stefan Monnier To: Philipp Subject: Re: bug#41988: 28.0.50; Edebug unconditionally instruments definitions with &define specs Message-ID: References: <6D19F14E-0133-4751-B0BD-EC2A73C1D21F@gmail.com> <3619E155-8F06-4F8F-B239-121ED3D164A8@gmail.com> Date: Sat, 10 Apr 2021 11:51:50 -0400 In-Reply-To: (Philipp's message of "Sat, 10 Apr 2021 17:07:48 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.008 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 X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41988 Cc: 41988@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 (---) > Here's a patch. LGTM, as far as I'm concerned you can push it to `master` and we'll just cross our fingers ;-) Stefan > From 9e2183edea41adf275f057a75232ea0b2c51e726 Mon Sep 17 00:00:00 2001 > From: Philipp Stephani > Date: Thu, 18 Mar 2021 12:40:08 +0100 > Subject: [PATCH] Edebug: Disable backtracking when hitting a &define keyword. > > Edebug doesn't deal well with backtracking out of definitions, see > Bug#41988. Rather than trying to support this rare situation (e.g. by > implementing a multipass parser), prevent it by adding an implicit > gate. > > * lisp/emacs-lisp/edebug.el (edebug--match-&-spec-op): Disable > backtracking when hitting a &define keyword. > > * test/lisp/emacs-lisp/edebug-tests.el > (edebug-tests-duplicate-&define): New unit test. > (edebug-tests--duplicate-&define): New helper macro. > > * doc/lispref/edebug.texi (Backtracking): Mention &define in the list > of constructs that disable backtracking. > > * etc/NEWS: Document new behavior. > --- > doc/lispref/edebug.texi | 10 +++++----- > etc/NEWS | 3 +++ > lisp/emacs-lisp/edebug.el | 18 ++++++++++-------- > test/lisp/emacs-lisp/edebug-tests.el | 25 +++++++++++++++++++++++++ > 4 files changed, 43 insertions(+), 13 deletions(-) > > diff --git a/doc/lispref/edebug.texi b/doc/lispref/edebug.texi > index 8942f55aff..323130f237 100644 > --- a/doc/lispref/edebug.texi > +++ b/doc/lispref/edebug.texi > @@ -1510,11 +1510,11 @@ Backtracking > must be in the form itself rather than at a higher level. > > Backtracking is also disabled after successfully matching a quoted > -symbol or string specification, since this usually indicates a > -recognized construct. But if you have a set of alternative constructs that > -all begin with the same symbol, you can usually work around this > -constraint by factoring the symbol out of the alternatives, e.g., > -@code{["foo" &or [first case] [second case] ...]}. > +symbol, string specification, or @code{&define} keyword, since this > +usually indicates a recognized construct. But if you have a set of > +alternative constructs that all begin with the same symbol, you can > +usually work around this constraint by factoring the symbol out of the > +alternatives, e.g., @code{["foo" &or [first case] [second case] ...]}. > > Most needs are satisfied by these two ways that backtracking is > automatically disabled, but occasionally it is useful to explicitly > diff --git a/etc/NEWS b/etc/NEWS > index a0f05d8cf1..9ae3740482 100644 > --- a/etc/NEWS > +++ b/etc/NEWS > @@ -2524,6 +2524,9 @@ back in Emacs 23.1. The affected functions are: 'make-obsolete', > > ** The 'values' variable is now obsolete. > > +** The '&define' keyword in an Edebug specification now disables > +backtracking. > + > > * Lisp Changes in Emacs 28.1 > > diff --git a/lisp/emacs-lisp/edebug.el b/lisp/emacs-lisp/edebug.el > index f1455ffe73..365bc74874 100644 > --- a/lisp/emacs-lisp/edebug.el > +++ b/lisp/emacs-lisp/edebug.el > @@ -1942,14 +1942,16 @@ edebug--match-&-spec-op > ;; Normally, &define is interpreted specially other places. > ;; This should only be called inside of a spec list to match the remainder > ;; of the current list. e.g. ("lambda" &define args def-body) > - (edebug-make-form-wrapper > - cursor > - (edebug-before-offset cursor) > - ;; Find the last offset in the list. > - (let ((offsets (edebug-cursor-offsets cursor))) > - (while (consp offsets) (setq offsets (cdr offsets))) > - offsets) > - specs)) > + (prog1 (edebug-make-form-wrapper > + cursor > + (edebug-before-offset cursor) > + ;; Find the last offset in the list. > + (let ((offsets (edebug-cursor-offsets cursor))) > + (while (consp offsets) (setq offsets (cdr offsets))) > + offsets) > + specs) > + ;; Stop backtracking here (Bug#41988). > + (setq edebug-gate t))) > > (cl-defmethod edebug--match-&-spec-op ((_ (eql &name)) cursor specs) > "Compute the name for `&name SPEC FUN` spec operator. > diff --git a/test/lisp/emacs-lisp/edebug-tests.el b/test/lisp/emacs-lisp/edebug-tests.el > index dcb261c2eb..7d45432e57 100644 > --- a/test/lisp/emacs-lisp/edebug-tests.el > +++ b/test/lisp/emacs-lisp/edebug-tests.el > @@ -1061,5 +1061,30 @@ edebug-tests-duplicate-symbol-backtrack > "edebug-anon10001" > "edebug-tests-duplicate-symbol-backtrack")))))) > > +(defmacro edebug-tests--duplicate-&define (_arg) > + "Helper macro for the ERT test `edebug-tests-duplicate-&define'. > +The Edebug specification is similar to the one used by `cl-flet' > +previously; see Bug#41988." > + (declare (debug (&or (&define name function-form) (defun))))) > + > +(ert-deftest edebug-tests-duplicate-&define () > + "Check that Edebug doesn't backtrack out of `&define' forms. > +This avoids potential duplicate definitions (Bug#41988)." > + (with-temp-buffer > + (print '(defun edebug-tests-duplicate-&define () > + (edebug-tests--duplicate-&define > + (edebug-tests-duplicate-&define-inner () nil))) > + (current-buffer)) > + (let* ((edebug-all-defs t) > + (edebug-initial-mode 'Go-nonstop) > + (instrumented-names ()) > + (edebug-new-definition-function > + (lambda (name) > + (when (memq name instrumented-names) > + (error "Duplicate definition of `%s'" name)) > + (push name instrumented-names) > + (edebug-new-definition name)))) > + (should-error (eval-buffer) :type 'invalid-read-syntax)))) > + > (provide 'edebug-tests) > ;;; edebug-tests.el ends here From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 10 12:23:27 2021 Received: (at 41988) by debbugs.gnu.org; 10 Apr 2021 16:23:27 +0000 Received: from localhost ([127.0.0.1]:53106 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lVGOM-0004Wv-Ti for submit@debbugs.gnu.org; Sat, 10 Apr 2021 12:23:27 -0400 Received: from mail-wm1-f43.google.com ([209.85.128.43]:46710) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lVGOL-0004Wj-Km for 41988@debbugs.gnu.org; Sat, 10 Apr 2021 12:23:26 -0400 Received: by mail-wm1-f43.google.com with SMTP id z24-20020a1cf4180000b029012463a9027fso4507155wma.5 for <41988@debbugs.gnu.org>; Sat, 10 Apr 2021 09:23:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=s4hARio9ca1LW7//m72q4q3rGxnqmQ6GYOeL7GjOQH8=; b=Wcpy8Avpj+GA57+y40tQBv0mWz2bHLmFmIGQLF6QPY1n8xzeP3zYAMQYZBbc3XdNED o7RgTjvP95TK5ft+p1dCITxSAXBxLR91JzXPv28AsEoesEFrjKSonDx9+rMrrc5NVfZK zXTJ3XuATLrXuxKuIrKfdCPzXW75v7ZXEYPpOiBBrqJiZ7zJs1+WMJrNqcOO6qZRN9D2 qNhh+PE4lg77JgSlugnX8gP0mtkZar5gORNXIfnQrt2wTUS/LrPoYtVMjiS/lP+Dbr0c BXbP9AzXuR4qJCrW751YJpcfXbuVXQEal1TBrhDAeYSo/FHsQlvGyoNuaqX/nn448ptt r7LA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=s4hARio9ca1LW7//m72q4q3rGxnqmQ6GYOeL7GjOQH8=; b=TKdOPgAQoZPC/kHvUh+HkebH5sYahyo9m2R+fgM70DZmcvfsi1VKh0AuQQzxw001qa VOFf+1vn9sGwc/rr7oT3XQNjXJzcH5Dk3Av3G+D0a+ay9ven10fAKu/OK0eUhHlzPjJo 8qVQpe8VEcx699padNQHOEC8GU15Wjz6bF5Zlx7bQlKVERHmRJsV9HXK0MSRExbuFapq +mfxYsgrYwxiKfVx9F4Pxqx4o//kxg5+9t1QxJ45V3PrPAcwxnQ3QRXo5WxNdpykrQSu TB1zLTrpzm4teTLzRk/hXn7s3ro4cT5jc/z6daHYTjZ2TLXa/39kdQBXfgNITrgNA/Zt kb2w== X-Gm-Message-State: AOAM532hCOuHh7QF54wwmqVsUkqhG3kPENZ0rIfganPJDlI+7qARUDFe ew54aGe2Q6m0o/S7y3csvFA= X-Google-Smtp-Source: ABdhPJxiNjpIurcFHcPuGgsvn5raajGSMC8QajU8ovOrOwLdqQVYARbgQlz0ulLZ03dSJaF1E58Dbw== X-Received: by 2002:a1c:7409:: with SMTP id p9mr17891542wmc.153.1618071799800; Sat, 10 Apr 2021 09:23:19 -0700 (PDT) Received: from philipps-macbook-pro.fritz.box (p57997a31.dip0.t-ipconnect.de. [87.153.122.49]) by smtp.gmail.com with ESMTPSA id f8sm7996329wmc.8.2021.04.10.09.23.18 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 10 Apr 2021 09:23:19 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Subject: Re: bug#41988: 28.0.50; Edebug unconditionally instruments definitions with &define specs From: Philipp In-Reply-To: Date: Sat, 10 Apr 2021 18:23:18 +0200 Content-Transfer-Encoding: 7bit Message-Id: <92D09CB5-67FE-4227-964C-C8060F52E507@gmail.com> References: <6D19F14E-0133-4751-B0BD-EC2A73C1D21F@gmail.com> <3619E155-8F06-4F8F-B239-121ED3D164A8@gmail.com> To: Stefan Monnier X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 41988 Cc: 41988@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: -0.8 (/) > Am 10.04.2021 um 17:51 schrieb Stefan Monnier : > >> Here's a patch. > > LGTM, as far as I'm concerned you can push it to `master` and we'll just > cross our fingers ;-) > Done From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 10 13:29:30 2021 Received: (at 41988) by debbugs.gnu.org; 10 Apr 2021 17:29:30 +0000 Received: from localhost ([127.0.0.1]:53181 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lVHQH-00069q-Na for submit@debbugs.gnu.org; Sat, 10 Apr 2021 13:29:29 -0400 Received: from eggs.gnu.org ([209.51.188.92]:46064) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lVHQF-00069d-Sv for 41988@debbugs.gnu.org; Sat, 10 Apr 2021 13:29:28 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:47807) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lVHQA-0004Ca-GE; Sat, 10 Apr 2021 13:29:22 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3499 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lVHQ8-0008CJ-1v; Sat, 10 Apr 2021 13:29:22 -0400 Date: Sat, 10 Apr 2021 20:29:03 +0300 Message-Id: <83blam59r4.fsf@gnu.org> From: Eli Zaretskii To: Philipp In-Reply-To: (message from Philipp on Sat, 10 Apr 2021 17:07:48 +0200) Subject: Re: bug#41988: 28.0.50; Edebug unconditionally instruments definitions with &define specs References: <6D19F14E-0133-4751-B0BD-EC2A73C1D21F@gmail.com> <3619E155-8F06-4F8F-B239-121ED3D164A8@gmail.com> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 41988 Cc: 41988@debbugs.gnu.org, monnier@iro.umontreal.ca 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.7 (-) > From: Philipp > Date: Sat, 10 Apr 2021 17:07:48 +0200 > Cc: 41988@debbugs.gnu.org > > diff --git a/etc/NEWS b/etc/NEWS > index a0f05d8cf1..9ae3740482 100644 > --- a/etc/NEWS > +++ b/etc/NEWS > @@ -2524,6 +2524,9 @@ back in Emacs 23.1. The affected functions are: 'make-obsolete', > > ** The 'values' variable is now obsolete. > > +** The '&define' keyword in an Edebug specification now disables > +backtracking. Please add here a pointer to the ELisp manual where this is described, as the text otherwise is too terse to speak for itself. Also, the heading line should be a single complete sentence, and the NEWS entry should be marked "+++", since the manual is being updated by the same changeset. (I have no opinion on the change itself, although it strikes me as unusual to delete a feature rather than fix it.) Thanks. From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 10 14:12:11 2021 Received: (at 41988) by debbugs.gnu.org; 10 Apr 2021 18:12:11 +0000 Received: from localhost ([127.0.0.1]:53260 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lVI5b-0000wS-F6 for submit@debbugs.gnu.org; Sat, 10 Apr 2021 14:12:11 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:55932) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lVI5a-0000wG-4y for 41988@debbugs.gnu.org; Sat, 10 Apr 2021 14:12:10 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id D737F1001D2; Sat, 10 Apr 2021 14:12:04 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 11DAE1000DA; Sat, 10 Apr 2021 14:12:03 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1618078323; bh=aGXVTqILgntRBd72GJCxTgnteMpnQFyYoRAo2TX++/c=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=mBmqZMtJEQIfh9SVTuXXODWLeymNKhu0YQb27IFd1Puo7cIYPn+0WwrTW3VBRQTlQ CmFxtLr3FFuyH3ofg81ySLFKiODaWzajKVHTE1A9sYhYmQ7g5wWbUjb0XxSCgrIStg rRji3V0/PEuwSQwBzElAHjregrvIcczu6qcFx1YRubgsutOj9H+/QRi66ax9kj2kW2 3o4fjlQ0mlNGZ8tzMZQsDCMQIngcXtILlbIqmulAp7PEeYB3SBuX7sW9akdRl2F0c2 0C6y7v0UhTCVqDtf/Lfg1rMEl6oxlekZ+ItYfKLTTtvfCfUHFOFdq8h/VlTAMyzLgx qjvfJPAnQnYaA== Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D4D1C12067B; Sat, 10 Apr 2021 14:12:02 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#41988: 28.0.50; Edebug unconditionally instruments definitions with &define specs Message-ID: References: <6D19F14E-0133-4751-B0BD-EC2A73C1D21F@gmail.com> <3619E155-8F06-4F8F-B239-121ED3D164A8@gmail.com> <83blam59r4.fsf@gnu.org> Date: Sat, 10 Apr 2021 14:12:02 -0400 In-Reply-To: <83blam59r4.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 10 Apr 2021 20:29:03 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.009 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 X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41988 Cc: 41988@debbugs.gnu.org, Philipp 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 (---) >> +** The '&define' keyword in an Edebug specification now disables >> +backtracking. > > Please add here a pointer to the ELisp manual where this is described, > as the text otherwise is too terse to speak for itself. > > Also, the heading line should be a single complete sentence, and the > NEWS entry should be marked "+++", since the manual is being updated > by the same changeset. > > (I have no opinion on the change itself, although it strikes me as > unusual to delete a feature rather than fix it.) It's a "feature" that's been broken for ever, that noone knows how to fix, and for which we know no current user. Also the new `&name` can be useful to avoid the need for that feature, so in a sense we did provide a kind of fix in the form of a new alternative solution. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 10 15:55:03 2021 Received: (at 41988) by debbugs.gnu.org; 10 Apr 2021 19:55:04 +0000 Received: from localhost ([127.0.0.1]:53335 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lVJh9-0001KL-Ll for submit@debbugs.gnu.org; Sat, 10 Apr 2021 15:55:03 -0400 Received: from mail-wm1-f53.google.com ([209.85.128.53]:39934) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lVJh8-0001Jp-32 for 41988@debbugs.gnu.org; Sat, 10 Apr 2021 15:55:02 -0400 Received: by mail-wm1-f53.google.com with SMTP id g18-20020a7bc4d20000b0290116042cfdd8so6482090wmk.4 for <41988@debbugs.gnu.org>; Sat, 10 Apr 2021 12:55:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WWbJyjvCliRd3KP+n103CAh50vc79myvnBNqPRdKRpI=; b=q4VgQ/hzmkYQeuRbqbDMI7vnvTxtMp9LpgBhRvDt1IzzhCS5YC9GoxVfzlg7pCo/2U HUH6WSxOV1D4N2FWnD+aTUSoc8GuQEwuoEUvV/XJ4qdJZEsk6zkBshFVMMdacWgrQ17f zk9MgDifEymPw3Dh4qC7QbJKI9NHIk+MRuv64vNJwfDS2VWEmYsnU3FkdcVoDBvZNwrj xAXfl3V/QUbgxsSHndzF1jKz/I9n6Qyzp5WiI+bcLzZjr11LX12VhgCsRk4HDY6sihKQ KhkWRB3CMNhZIUMwEZKyMvNmg+6GA/PTvt2RPxlMFXS473HE4xzFG5Gc5v8/G2sepCxK 15DA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WWbJyjvCliRd3KP+n103CAh50vc79myvnBNqPRdKRpI=; b=hkxQH9h5MXT3uO7p5vL37K9+iViYS2jyoGKz2TbWDrcV9c7gpqzEyd8KuyBU53rH4T ALjTEdmS0qjn30dq19jFzKxxC7KxWN0/zO1Yprxc6VNjFkiFLK0G4RNS11hANiqCwIjP J7lQ2UKOx0DsN/ZfJkkxcaHIQHG5+KcpJYJoTVQZLbNi/Vh4T/4WZhVCQmJDYl6t3xUH l/S+T7HBmishiC4Q7ZvPAbjJGMh0ZQv3tADO+nLlqFhuqIfDyUwFK7+/7gF9F470Z+F2 ZtfmVbBND0bnpsSJPMjwGz7BPsmX4fln9Uxgf5rsuifxXItUicwDTlYM8klnCh/Y745J Y+ow== X-Gm-Message-State: AOAM5301gyw+HYw+vAKkPYCVkNjtDPYC64i1xpJsH4WAzLgoxccPbvKW +FxOf2wwUrcnfWI8vKUB4lrFvvN+HjNSVQ== X-Google-Smtp-Source: ABdhPJwagR7ZyWIIa2LkVpQ4Km9V3KhBeWyAVcA0Hqn0mSt2jd6bOuGU6bUygSZZJ4edcIR48lRD8A== X-Received: by 2002:a1c:f004:: with SMTP id a4mr19160712wmb.169.1618084495966; Sat, 10 Apr 2021 12:54:55 -0700 (PDT) Received: from philipps-macbook-pro.fritz.box (p57997a31.dip0.t-ipconnect.de. [87.153.122.49]) by smtp.gmail.com with ESMTPSA id i26sm9301007wmb.18.2021.04.10.12.54.55 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 10 Apr 2021 12:54:55 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Subject: Re: bug#41988: 28.0.50; Edebug unconditionally instruments definitions with &define specs From: Philipp In-Reply-To: <83blam59r4.fsf@gnu.org> Date: Sat, 10 Apr 2021 21:54:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <788A06EE-1FA0-4FD5-86C3-4B055FD85241@gmail.com> References: <6D19F14E-0133-4751-B0BD-EC2A73C1D21F@gmail.com> <3619E155-8F06-4F8F-B239-121ED3D164A8@gmail.com> <83blam59r4.fsf@gnu.org> To: Eli Zaretskii X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 41988 Cc: 41988@debbugs.gnu.org, monnier@iro.umontreal.ca 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.8 (/) > Am 10.04.2021 um 19:29 schrieb Eli Zaretskii : >=20 >> From: Philipp >> Date: Sat, 10 Apr 2021 17:07:48 +0200 >> Cc: 41988@debbugs.gnu.org >>=20 >> diff --git a/etc/NEWS b/etc/NEWS >> index a0f05d8cf1..9ae3740482 100644 >> --- a/etc/NEWS >> +++ b/etc/NEWS >> @@ -2524,6 +2524,9 @@ back in Emacs 23.1. The affected functions = are: 'make-obsolete', >>=20 >> ** The 'values' variable is now obsolete. >>=20 >> +** The '&define' keyword in an Edebug specification now disables >> +backtracking. >=20 > Please add here a pointer to the ELisp manual where this is described, > as the text otherwise is too terse to speak for itself. >=20 > Also, the heading line should be a single complete sentence, and the > NEWS entry should be marked "+++", since the manual is being updated > by the same changeset. Done in commit 1d474ad69d19d01b047012734530fb4c5eb82144.= From unknown Sun Aug 17 22:10:19 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 09 May 2021 11:24:10 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator