bug#65620: void function edebug-after

[Alan Mackenzie]

Hello, Gerd.

On Thu, Aug 31, 2023 at 09:55:18 +0200, Gerd Möllmann wrote:
> Michael Heerdegen <michael_heerdegen@web.de> writes:

> > Alan Mackenzie <acm@muc.de> writes:

> >> (defmacro hash-if (condition then-form &rest else-forms)
> >>   "A conditional compilation macro analogous to C's #if.
> >> Evaluate CONDITION at macro-expansion time.  If it is non-nil,
> >> expand the macro to THEN-FORM.  Otherwise expand it to ELSE-FORMS
> >> enclosed in a `progn' form.  ELSE-FORMS may be empty."
> >>   (declare (indent 2)
> >>            (debug (form sexp &rest sexp)))
> >>   (if (eval condition lexical-binding)
> >>       then-form
> >>     (cons 'progn else-forms)))

> > Dunno if someone is able to fix this (I'm not).  Until then using
> > `def-form` `or `sexp` instead of `form` works in a better way (the
> > former edebugs CONDITION when instrumenting, the latter would omit
> > edebugging the CONDITION entirely).

> > Anyway, the key point in the above example is that macroexpanding (while
> > instrumenting) combined with the `eval' call seems to lead to the
> > evaluation of instrumented code outside of an Edebug session when
> > CONDITION is instrumented using `form`.  `eval-when-compile' uses
> > `def-form` for example - I guess using `form` in this case doesn't work
> > as one might expect.

> I think what's happening here is like this:

> By using 'form' for condition, we're telling edebug to instruments it.
> That is, the argument eval sees when foo is instrumented is whatever
> edebug wraps around the condition (< ...), and that contains the
> eval-after.  Using sexp for the condition doesn't instrument the condition.

Or, put a different way, edebug has instrumented CONDITION, then tries to
evaluate this.  This fails because there is no call to
edebug-make-enter-wrapper around the thing, which would defalias
edebug-after and edebug-before, and set up several lists that edebug
needs.

> One can follow that in the backtrace.

> So, I guess there's nothing to fix here.

I don't think I agree.  eval (and probably apply and funcall and its
variants) should somehow generate an "optional" edebug-make-enter-wrapper
around them.  This is currently not done.

-- 
Alan Mackenzie (Nuremberg, Germany).