GNU bug report logs - #65344
28.2; Unable to Edebug cl-flet form which uses argument destructuring

Previous Next

Full log

View this message in rfc822 format

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, brandon.irizarry <at> gmail.com, Michael Albinus <michael.albinus <at> gmx.de>, 65344 <at> debbugs.gnu.org
Subject: bug#65344: 28.2; Unable to Edebug cl-flet form which uses argument destructuring
Date: Wed, 23 Aug 2023 16:08:24 +0200

Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:

> Mattias Engdegård <mattias.engdegard <at> gmail.com> writes:
>
>>> Gerd, edebug-tests fail on master after your changes (cc0f546825). Would you do something about that?
>>
>> And cl-macs-tests.
>
> Strange stuff, I guess I'll need some time to understand what is going
> on.  As a temporary measure I've reverted my last commit, the reversing
> of the &defines.

Maybe it's not so temporary after all.

The problem seems to be the attempt to first match the spec

  (&define [&name symbolp "@cl-flet@"]
           [&name [] gensym] ;Make it unique!
           def-form)])

with (for example)

  (fn ((x y)) ...) or
  (fn (&rest x) ...)

Edebug then matches def-form with ((x y)) or (&rest x), and it finds it
doesn't match.  I would have expected that this leads to backtracking
and trying the second alternative of the &or, but that's not happening.

So, at the moment we're kinda stuck with the situation that local
functions that look like local-functions with empty body, like

  (cl-flet ((fn (...)))
    ...)

are not instrumented like the cl-flet extension case.  That's not a
catastrphy, I guess.

Previous Next

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