bug#71934: comp--spill-lap-function and closure (wad: bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects)

[Andrea Corallo <acorallo@gnu.org>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> It's apparent that the one that used to work,
>>>
>>>     (cl-defmethod comp--spill-lap-function ((form list))
>>>
>>> , no longer works since function forms were converted to a different
>>> format in March.  It needs modifying to handle the new format.
>>
>> That was the question.
>>
>> So, of what kind can the argument FORM be?  Any form (any lisp
>> expression - any kind of "code") - lambda lists, function values?
>>
>> As far as I understand the above method originally supported lambda
>> lists and you made it handle function values as well.  And because
>> function values are now represented differently the above method does
>> not handle this case any more.
>>
>> Is this correct?
>
> Yeah, I also fail to understand the relationship between
> `comp--spill-lap-function` (which sounds internal to the compilation
> pipeline and thus might apply to all sorts of subexpressions of the
> input code) and `native-compile` (where adding support for function
> values affects only the "toplevel" of the input).

'comp--spill-lap-function' serves 'comp--spill-lap' which is the first
pass of the native compilation pipeline.  So adding a new method there
is the usual way to make native-compile support new kind of inputs.

  Andrea