GNU bug report logs - #71934
31.0.50; edebug--called-interactively-skip vs. new fun objects

Previous Next

Full log

View this message in rfc822 format

From: Andrea Corallo <acorallo <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, Alan Mackenzie <acm <at> muc.de>, Eli Zaretskii <eliz <at> gnu.org>, 71934 <at> debbugs.gnu.org
Subject: bug#71934: comp--spill-lap-function and closure (wad: bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects)
Date: Mon, 08 Jul 2024 04:47:05 -0400

Stefan Monnier <monnier <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.