Subject: Re: bug#65344: 28.2; Unable to Edebug cl-flet form which uses argument destructuring

From: Gerd Möllmann <[email-masked]>
Date: Sat, 02 Sep 2023 07:10:15 +0200

Stefan Monnier <[email-masked]> 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.