From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Newsgroups: gmane.emacs.bugs Subject: bug#65344: 28.2; Unable to Edebug cl-flet form which uses argument destructuring Date: Sun, 03 Sep 2023 07:51:14 +0200 Message-ID: References: <5184DD53-F121-405D-AEE9-6E72E17127EA@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22704"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Michael Heerdegen , brandon.irizarry@gmail.com, Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Michael Albinus , 65344@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Sep 03 07:52:15 2023 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 1qcg1v-0005je-IT for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 03 Sep 2023 07:52:15 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qcg1d-0006cJ-J5; Sun, 03 Sep 2023 01:51:57 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qcg1Y-0006c6-6G for bug-gnu-emacs@gnu.org; Sun, 03 Sep 2023 01:51:52 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qcg1X-0007LS-Tk for bug-gnu-emacs@gnu.org; Sun, 03 Sep 2023 01:51:51 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qcg1h-0007Dh-Oc for bug-gnu-emacs@gnu.org; Sun, 03 Sep 2023 01:52:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 03 Sep 2023 05:52:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65344 X-GNU-PR-Package: emacs Original-Received: via spool by 65344-submit@debbugs.gnu.org id=B65344.169372030127725 (code B ref 65344); Sun, 03 Sep 2023 05:52:01 +0000 Original-Received: (at 65344) by debbugs.gnu.org; 3 Sep 2023 05:51:41 +0000 Original-Received: from localhost ([127.0.0.1]:39076 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qcg1J-0007D1-Vo for submit@debbugs.gnu.org; Sun, 03 Sep 2023 01:51:41 -0400 Original-Received: from mail-ed1-x52a.google.com ([2a00:1450:4864:20::52a]:61839) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qcg1F-0007Cl-8M for 65344@debbugs.gnu.org; Sun, 03 Sep 2023 01:51:37 -0400 Original-Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-52683da3f5cso444207a12.3 for <65344@debbugs.gnu.org>; Sat, 02 Sep 2023 22:51:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693720277; x=1694325077; darn=debbugs.gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=Q+++hwy/80kxrDve9FAIaGLyAecUtAjyK9VJhcWzDKA=; b=acvLuXac7p4MRCR+Y+gl7nRvQj/hyNuUDO9V3q/8Aw0tJ5OCy7exXtfNqgkPaCWo/N SwBJFGBa6HBGzGb9y7K9NfvelolC8Q3Fu+Ms98X04RVB+xPpS029C8yoEUFtamH+vpPA qr27Vy47CpNATK72uJLooCy7xcC1CM+/QtTxlr9i0P8I1ch8K4hCl5sMyTq9aw68D0xw ul2ORB3Yt+YcgL6LoNXGCxl7mvdYHbtTP7RQ/bIV4clCR2sZnDh1zGNvxb1OCMQ0GNnl W0rIi5/5YI6Ymos2UI9cCntzPJUQlu/yevnNcP7H8WN7b2NUAxovaXrYPUgsGxxdhQK6 3XDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693720277; x=1694325077; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Q+++hwy/80kxrDve9FAIaGLyAecUtAjyK9VJhcWzDKA=; b=S5XaJ0YHctqxKZoprlKQy4/kDtzB2lkIo6/pAP0J4R3ry0g2Ch6KZGJXI9dqKVV+LK zMySiNQAkXBtYf4wHN6LLf0DV0IQHJu2fQyJM/BkXM544Ny66I7Ku6zmEpzAqvavcRbG Eb+ZpvswNBVAfQf+ocl/WzVtCCkg1N0a2WCnzjpFwBuxzHOkHtE3YX1Op+WX3Tw2+Nc+ mkKA+MCnzGq49+/aEMA7TXymQAo3KOFsNzpy45e2hM9SBPoxuPfiF7rrgn84pLSVctXI 0HYUpMgHGQ3DKQAqf3pGYE8bSHFBZKgz3JYbqRp9xFGnmNIfCPWthjRKCOB3+Ib2DVMQ W0TQ== X-Gm-Message-State: AOJu0YwtD63RikxhObgHn4jrfWtMeLR5Or/5gLNmISaSkB5D8+SX9J93 mqyUgr/fdYMkys9c6rP4LcVn7jzYwgyF2OSH X-Google-Smtp-Source: AGHT+IGMlJGKk6NWnr4C3gx82W4FKFM7MBvLK0NngXB0MFh96raJi/G/nx7n6nA/uvLSVxcBpT+QLw== X-Received: by 2002:a05:6402:b6d:b0:52c:b469:bafd with SMTP id cb13-20020a0564020b6d00b0052cb469bafdmr768593edb.41.1693720276492; Sat, 02 Sep 2023 22:51:16 -0700 (PDT) Original-Received: from Pro.fritz.box (pd9e3628c.dip0.t-ipconnect.de. [217.227.98.140]) by smtp.gmail.com with ESMTPSA id b4-20020aa7c6c4000000b00523653295f9sm4142578eds.94.2023.09.02.22.51.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 02 Sep 2023 22:51:16 -0700 (PDT) In-Reply-To: (Stefan Monnier's message of "Sat, 02 Sep 2023 15:27:51 -0400") 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:269074 Archived-At: Stefan Monnier writes: >>> In this case, the code for F will be run in the body of the >>> flet. Doesn't that qualify as being run later, as you describe above, >>> ignoring the "non-instrumented" part, maybe? >> >> No, in the above case the `def-form` is >> >> (lambda () (list 1 2)) >> >> which will be "run" right when we enter the `cl-flet` ("run" is an >> exaggeration here since this lambda is a constant so it'll just >> self-evaluate) and not when `f` is called. Thanks. I've skimmed through the docs and Edebug code a bit this today, and I think I understand you a bit better now. > > More specifically, the annotated code of > > (defun sm-foo (x) > (cl-flet ((f (prog1 (lambda (y) (+ x y)) 0))) > (f 5))) > > stored into (symbol-function 'sm-foo) now looks like: > For posterity, if somone reads this in a few years, including myself, maybe... If I understand correctly, the edebug-before and -after instrumentation forms lead, via edebug-behavior, to calls to edebug-slow-{before,after}, when test coverage is demanded by edebug-test-coverage being non-nil. Otherwise, when e-t-c is nil, another pair of functions with 'fast' in their names is used. The slow functions update edebug-freq-count. E-f-q seems to be a special variable that edebug-default-enter binds to a vector that is obtained from the symbol-plist of the function name, which is an argument of e-d-e. I haven't checked what exactly e-default-e is. I'm just assuming from its name it gets called when encountering edebug-enter. > (closure (t) (x) > (edebug-enter 'sm-foo (list x) So, in the line above, we obtain the frequency vector from the name 'sm-foo. > #'(lambda nil :closure-dont-trim-context > (edebug-after (edebug-before 0) 3 And the line above accesses that vector found in edebug-frequency-count. > (let* ((--cl-f-- > (edebug-enter 'f@cl-flet@4 nil > #'(lambda nil :closure-dont-trim-context > (edebug-after (edebug-before 0) 1 Here the same mechanism for the local-function > (prog1 > #'(lambda (y) > (edebug-enter 'edebug-anon5 (list y) > #'(lambda nil :closure-dont-trim-context > (edebug-after (edebug-before 0) 3 And here again the same mechanism, but with a bogus name. That's what you are referring to, right? > (+ (edebug-after 0 1 x) > (edebug-after 0 2 y)))))) > 0)))))) > (progn > (edebug-after (edebug-before 1) 2 > (funcall --cl-f-- 5)))))))) > > As you can see for `sm-foo` itself, the > > (edebug-enter 'sm-foo (list x) > #'(lambda nil :closure-dont-trim-context > > is (correctly) placed at the very beginning of the body of the function, > so that code coverage can track whether `sm-foo` was called or not. Understood (I think). The lambda will land in edebug-default-enter, which funcalls it. That lands in the "(edebug-enter 'f@cl-flet@4 ...", and so on. > > In contrast the > > (edebug-enter 'f@cl-flet@4 nil > #'(lambda nil :closure-dont-trim-context > > is placed around the code which will compute&return the `f@cl-flet@4` > function, but not inside its body, which instead gets > > (edebug-enter 'edebug-anon5 (list y) > #'(lambda nil :closure-dont-trim-context Right. I think I found that, too. > It's actually difficult (and in general impossible) to associate the > name `f@cl-flet@4` with the corresponding `lambda`, so the use of > `edebug-anon5` is largely unavoidable here. But making the code-coverage > say that `f@cl-flet@4` is called just because we computed that function > (regardless if it's been called) is a problem. Ok, understood. I hope, or did I get lost somewhere? Do you perhaps an idea how to solve that?