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

[Eli Zaretskii]

> 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?