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: Sat, 02 Sep 2023 07:10:15 +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="37586"; mail-complaints-to="usenet@ciao.gmane.io" 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 Sat Sep 02 07:11:32 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 1qcIux-0009bs-V8 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 02 Sep 2023 07:11:31 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qcIud-0003Jv-0I; Sat, 02 Sep 2023 01:11:16 -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 1qcIuN-00034p-Q0 for bug-gnu-emacs@gnu.org; Sat, 02 Sep 2023 01:10:57 -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 1qcIuL-0005ES-42 for bug-gnu-emacs@gnu.org; Sat, 02 Sep 2023 01:10:55 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qcIuU-00037b-Cg for bug-gnu-emacs@gnu.org; Sat, 02 Sep 2023 01:11:02 -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: Sat, 02 Sep 2023 05:11:02 +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.169363143611955 (code B ref 65344); Sat, 02 Sep 2023 05:11:02 +0000 Original-Received: (at 65344) by debbugs.gnu.org; 2 Sep 2023 05:10:36 +0000 Original-Received: from localhost ([127.0.0.1]:34868 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qcIu4-00036l-3Z for submit@debbugs.gnu.org; Sat, 02 Sep 2023 01:10:36 -0400 Original-Received: from mail-ej1-x630.google.com ([2a00:1450:4864:20::630]:58856) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qcIu1-00036Y-CG for 65344@debbugs.gnu.org; Sat, 02 Sep 2023 01:10:34 -0400 Original-Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-99c3c8adb27so328442766b.1 for <65344@debbugs.gnu.org>; Fri, 01 Sep 2023 22:10:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693631417; x=1694236217; darn=debbugs.gnu.org; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:from:to:cc:subject:date:message-id:reply-to; bh=2RWi3kzqxtkLT9pOm6xs6c6pkwDqqN0wETPYZ8MCb9E=; b=NNDSOcQDn8MmA+sdSG9R+aOLZ/mU0A71k8AoUWt5mR/wut9teRzsY2jvG4tnDoHb0q 7CxdAph6XZzxC0Fma+HrnT4J4r2ZFlmgkk/Y72Kd2RXp3LcjX+DLlPGNL2Zn1wIYxUx1 uFGxxVTrVptR+QXav1NFDmpNrnQKELg98TwHyQmzsx7P9letcDuNNRkBykmjkjDdy6Vw TIOulR9lvEjmwq5HUZaSsv4/jPBsXdSm5aRbRhSqvv5Riq1iTHNfVUyKRj94Vr59TCQN XWNsW9cINpvKFJqJn1jd/oJIqfyAxspi02/fTftWbBFq7NPmMlgTV51+KswVlAGQ74o7 GN1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693631417; x=1694236217; h=mime-version: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=2RWi3kzqxtkLT9pOm6xs6c6pkwDqqN0wETPYZ8MCb9E=; b=covUJ4pw13L8iLn7ek0DJUrOZImelJWVut2MJxGIvAtHWSsCF1yKqMLhj6wjHx9Zg3 9q1qqB2P3Qp5BHvh4xLdcpgggVbh8j6qtMm1tukF3SJfOgYQ0FifIQ5hLxEVdhE7MTrQ Uyr8NwR+zSBRGGpYvpCDnZ2UnE5hYflJ/AqiGUJDaAwc1Ayf5tRGdgSWjUCec3oM1yBG jNWkGQV7xq8Hv7cPMQ6LdSrjF0aPmHLC1jDLiXzt2WibKKVsoVop9LLiuB/e9wI2qyQp HdRnL5Kq1/m+B0+OFSvLC1RNN3sin43G5MqIzsTAGlnEOhN0USTFJ4oCV3EGGtlLSWi8 7Nrw== X-Gm-Message-State: AOJu0Yw6/J+bwamYeeQYETPC0LazClkMNQnJo+M1ErrGlx6CU2sWxGoC 45bxuAy+0Y0v/1XIn2lGaA+fVQC2nhX1RmsV X-Google-Smtp-Source: AGHT+IFFRl5BxhPc07oLPKMSmImQaLNTpu73cAMs08Pbq0pfbDyg7pqZj8iUv3P01npj0Ie0KIxmuw== X-Received: by 2002:a17:907:b0b:b0:9a1:d29c:6aaa with SMTP id h11-20020a1709070b0b00b009a1d29c6aaamr3098709ejl.39.1693631417487; Fri, 01 Sep 2023 22:10:17 -0700 (PDT) Original-Received: from Mini.fritz.box (pd9e362c0.dip0.t-ipconnect.de. [217.227.98.192]) by smtp.gmail.com with ESMTPSA id a25-20020a1709064a5900b009a2202bfce5sm2907309ejv.118.2023.09.01.22.10.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Sep 2023 22:10:16 -0700 (PDT) In-Reply-To: (Stefan Monnier's message of "Fri, 01 Sep 2023 19:24:56 -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:268952 Archived-At: Stefan Monnier writes: >> The problem seems to be the attempt to first match the spec >> >> (&define [&name symbolp "@cl-flet@"] >> [&name [] gensym] ;Make it unique! >> def-form)]) > > I think this is not right: > > - `def-form` is for use by forms which will be run "later", meaning that > we can start executing those instrumented form while running > non-instrumented code (like the inside of a lambda), so it should not > be needed here: we should use just `form`. I don't think I get that yet. Let's say we have (cl-flet ((f (lambda () (list 1 2)))) (f)) 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? (Just from the perspective of behaviour, C-u C-M-x on the flet above does seem to do what I'd expect: the call to F let's me step into the body of the lambda.) > > - The &define+&name isn't quite right here. In `(cl-flet ((F EXP)) ...)` > it tells Edebug that EXP should be given the name F whereas the `cl-flet` > actually gives the name F to the value returned by EXP. > [ In terms of code coverage, F will then always be considered as > covered just because we have to execute EXP in order to discover the > function to bind to F. ] > > I think that's why the old code had just `(symbolp form)`: > it's difficult with `(cl-flet ((F EXP)) ...)` to give a name to the > right thing :-( I'm afraid I know nothing about coverage, so I can't say something halfways intelligent to that.