bug#59213: Emacs 29: Edebug fails to instrument a parameter whose name begins with _

[Alan Mackenzie]

Hello, Stefan.

On Sun, Nov 13, 2022 at 22:53:12 -0500, Stefan Monnier wrote:
> > In Emacs 29 (not started with -Q, but...),

> > I instrumented for edebug a function which looked like:

> >     (defun c-trim-found-types (beg end _old-len) ....)

> > , the compilation being with lexical-binding: t.

> > During the edebug session, I attempted

> >     e _old-len RET.

> The behavior depends on where you are in the *Backtrace* buffer, because
> each line in the backtrace can be in a different lexical scope.
> So please clarify on which line you were when you did the above.

I wasn't in the backtrace.  I was stepping through the code in edebug.

More precisely, with this defun:

    (defun add (a b _c)
      (+ a b))

, instrument it for edebug.  Call M-: (add 1 2 6).

The source code with active edebug now looks like:

    (defun add (a b _c)
    =>(+ a b))

..  e a now returns 1.  e b returns 2.  e _c gives the error message:

    Error: Symbol's value as variable is void: _c

..  I repeat, this is a bug.  It should have returned 6.

> > Instead of giving me the value of _old-len (which was 3) it gave the
> > error message

> >     Error: Symbol's value as variable is void: _old-len

> > ..  This is a bug.

> Could be.  Or could be that you were trying to use `_old-len` in
> a lexical context where there is no such variable.

_c is in the same lexical context as a and b, surely?

> > Just because a function doesn't use a particular argument (here

> I think the leading underscore is purely incidental and you'd get the
> same behavior with `beg` and `end`.

No, beg and end returned their values.  I admit I'm speculating about the
leading underscore, but I still say there's a bug, somewhere here.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).