From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.bugs Subject: bug#41988: 28.0.50; Edebug unconditionally instruments definitions with &define specs Date: Sat, 8 Aug 2020 13:01:50 +0200 Message-ID: References: <20200621234816.88427.qmail@mail.muc.de> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20918"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 41988@debbugs.gnu.org To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Aug 08 13:03:24 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 1k4MdH-0005Jt-HC for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 08 Aug 2020 13:03:23 +0200 Original-Received: from localhost ([::1]:35588 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k4MdG-0000o4-Im for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 08 Aug 2020 07:03:22 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46216) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k4Mcw-0000mw-J5 for bug-gnu-emacs@gnu.org; Sat, 08 Aug 2020 07:03:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:46737) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1k4Mcw-0004X0-9K for bug-gnu-emacs@gnu.org; Sat, 08 Aug 2020 07:03:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1k4Mcw-0007qH-6b for bug-gnu-emacs@gnu.org; Sat, 08 Aug 2020 07:03:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 08 Aug 2020 11:03: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.159688453030065 (code B ref 41988); Sat, 08 Aug 2020 11:03:02 +0000 Original-Received: (at 41988) by debbugs.gnu.org; 8 Aug 2020 11:02:10 +0000 Original-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 Original-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 Original-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) In-Reply-To: <20200621234816.88427.qmail@mail.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:184324 Archived-At: 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.