GNU bug report logs - #41988
28.0.50; Edebug unconditionally instruments definitions with &define specs

Previous Next

Full log

View this message in rfc822 format

From: Philipp <p.stephani2 <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 41988 <at> debbugs.gnu.org
Subject: bug#41988: 28.0.50; Edebug unconditionally instruments definitions with &define specs
Date: Sun, 21 Mar 2021 14:34:08 +0100

> Am 18.03.2021 um 15:01 schrieb Stefan Monnier <monnier <at> iro.umontreal.ca>:
> 
>>> No.  And I'd hope the problem can be avoided in all cases.
>>> I guess we could try and make it more "official" by imposing some kind of "cut"
>>> such that after passing a `&define` we can't backtrack.
>> From looking at the code, would it be possible to achieve this by setting
>> edebug-gate to non-nil in the right places?
>> If so, then this seems to be only a matter of finding the right places ;-)
> 
> It's possible, but:
> - I don't understand enough the way backtracking works in Edebug to know
>  what `edebug-gate` does, really.

It looks like you can set edebug-gate to t in edebug--match-&-spec-op (the &define branch).  That should have the same effect as a [gate ...] construct around each &define form.

> - The old spec of `cl-flet` would be broken by such a change, so if we
>  want to make such a change, we'd probably want to arrange so that it
>  emits a clear warning.

Where?  When setting the debug specification (byte-run--set-debug), or in some other place?

> 
> I'm not sure it's worth the trouble: the pain seems higher than the gain.
> 

This bug is rather nasty when it's hit (it took me quite a while to debug/hunt down), so I think it would be reasonable to prevent.  We already disable backtracking for literal symbols, and I think forms that require multiple &define forms with backtracking should be exceedingly rare and can be rewritten as you did with cl-flet.

Previous Next

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