bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects

[Andrea Corallo <acorallo@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: 71934-done@debbugs.gnu.org, Alan Mackenzie <acm@muc.de>
>> Date: Fri, 05 Jul 2024 07:06:44 +0200
>> From:  Michael Heerdegen via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>> 
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> 
>> > I already did.
>> 
>> What about `which-key--get-keymap-bindings-1'?
>> 
>> 
>> For this one I CC Alan M.:
>> 
>> > There's one case on `comp.el` which may require some update
>> 
>> Yes, that's more or less the only other one I found:
>> `comp--spill-lap-function'.  Alan, we are discussing how relevant the
>> code in that function is that checks for lambda and closure cars, and if
>> it must be updated to handle the new interpreted function objects.
>> 
>> > but I don't understand the code enough to know what it intends to
>> > do.  It seems to match both `lambda` and `closure`, hence function
>> > *values*, but somehow it doesn't try and handle byte-code functions
>> > which are far more common function values, so maybe the `closure` is
>> > just irrelevant and the code is expected to match source code
>> > expressions (whose evaluation will return functions)?
>> 
>> Dunno.  `comp-trampoline-compile' constructs a lambda form to compile.
>> But never a "closure form".  So maybe irrelevant to check for 'closure'
>> indeed.
>> 
>> Alan had added the 'closure' symbol in
>> 
>> 06e4ebc81a4 "With `native-compile', compile lambdas in a defun or lambda too"
>> 
>> which seems had been a fix for bug#64646 "Master: Native compiler
>> doesn't always compile lambda".  Guess this bug report is also an answer
>> to Stefan's question.
>
> Andrea, can you take a look at this, please?

Yep, I believe that code does not require to be changed, the input of
comp--spill-lap-function is a form not an interpred function.

  Andrea