bug#59213: Emacs 29: Edebug fails to instrument a parameter whose name begins with _

[Stefan Monnier]

>> BTW, what did you mean by "This function is evaluated both at compile
>> time and run time"?
>
> It was my state of gradually diminishing confusion (which started at a
> high level) as I worked through the bug.  It took me some while before it
> occurred to me that the creation of closures was happening at run time,
> not compile time.  Of course, it's got to, because the lexical
> environment only exists at run time.  But I would have got through all
> this faster if there had been a comment saying
> cconv-make-interpreted-closure is called at run time.  So I put such a
> comment in for the next highly confused hacker.

Thanks.  I found that part more confusing, so I reworked it in
a way that I hope doesn't make it too much worse.

> As for the "at compile time", I saw this happening whilst I was running
> things in gdb.  I'm not actually sure about this anymore, since these
> calls to c-m-i-closure might well have been run time for bits of the
> compiler, not compile time.

That'd be my guess, yes.  Tho it can also be due to execution of (not
yet byte-compiled) macros.

> Thanks.  I'm not sure what advantages this approach has, but it certainly
> gets rid of the ugly cconv-dont-trim-unused-variables.

Getting rid of the dynamically scoped `cconv-dont-trim-unused-variables`
is the whole point.

In theory it's also "more correct" since it marks the actual lambdas for
which we care to preserve the full environment, regardless of *when*
we'll manipulate it.  E.g. if we ever get to byte-compile the
Edebug-instrumented code, the compiler will get to see this marker so it
can do the right thing, whereas it wouldn't see the
`cconv-dont-trim-unused-variables` because that war was only active when
the code was actually executed [ Of course, this is moot in practice
since the byte-compiler currently doesn't know what to do with this
marker.  ]


        Stefan