From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#41988: 28.0.50; Edebug unconditionally instruments definitions with &define specs Date: Sat, 8 Aug 2020 14:59:48 +0000 Message-ID: <20200808145948.GA10181@ACM> References: <20200621234816.88427.qmail@mail.muc.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32567"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 41988@debbugs.gnu.org To: Philipp Stephani Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Aug 08 17:00:12 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k4QKS-0008Mm-79 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 08 Aug 2020 17:00:12 +0200 Original-Received: from localhost ([::1]:57914 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k4QKR-0001DJ-8n for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 08 Aug 2020 11:00:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55108) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k4QKJ-0001D8-0f for bug-gnu-emacs@gnu.org; Sat, 08 Aug 2020 11:00:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:47927) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1k4QKI-00046O-MM for bug-gnu-emacs@gnu.org; Sat, 08 Aug 2020 11:00:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1k4QKI-0002FO-Lg for bug-gnu-emacs@gnu.org; Sat, 08 Aug 2020 11:00:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 08 Aug 2020 15:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 41988 X-GNU-PR-Package: emacs Original-Received: via spool by 41988-submit@debbugs.gnu.org id=B41988.15968987988604 (code B ref 41988); Sat, 08 Aug 2020 15:00:02 +0000 Original-Received: (at 41988) by debbugs.gnu.org; 8 Aug 2020 14:59:58 +0000 Original-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 Original-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 Original-Received: (qmail 80133 invoked by uid 3782); 8 Aug 2020 14:59:48 -0000 Original-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 Original-Received: (qmail 10453 invoked by uid 1000); 8 Aug 2020 14:59:48 -0000 Content-Disposition: inline In-Reply-To: X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:184361 Archived-At: 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).