bug#67455: (Record source position, etc., in doc strings, and use this in *Help* and backtraces.)

[Alan Mackenzie <acm@muc.de>]

Hello, Stefan.

On Sun, Apr 07, 2024 at 22:19:28 -0400, Stefan Monnier wrote:
> > The definition starts when the reader reads (defun foo ...).  It ends
> > when that Fdefalias has been evaluated.  Between those two events,
> > defining-symbol is bound to foo.

> When the code is compiled, years can pass between those two events.

Really?  Then defining-symbol would stay bound over these years, too.
Where's the problem?

> > The critical thing here is the variable defining-symbol.  I think you're
> > suggesting that its value could accidentally find its way into other
> > symbols' position structures.  When are those other symbols getting
> > defined?  Surely if a secondary defun, defmacro, defvar, ... happens
> > during the main defun, its defining symbol is that of the main defun?

> That secondary symbol might be defined by the macro for its own use,
> rather than for the use of the returned code.

> > Well, m-a-e is defined too late.

> According to your self-imposed rule 🙂

> > Even if it weren't, how would it solve any of these problems you see?
> > It's just swapping one dynamically bound variable for another.

> Indeed, m-a-e has to fight the same issues, in theory, but in practice,
> those issues have already been addressed over the years.  It's rebound
> to nil "all the time" to try and make sure its effect doesn't leak.

defining-symbol isn't bound like this, in order for its value to be
available when needed.

> BTW, it would be nice to separate your patches into some that add
> position info to lambda's docstring, and then others that add
> "defining symbol" to the available position info.

All this could be moot.  Byte compiling is appreciably slower on this
branch than on master.  make bootstrap is taking me nearly 7 minutes
compared with master's 4min 40sec.  Running make -j17 check is taking
1min 50sec rather than 50sec.  Once compiled, the code runs at the same
speed, though.

I think this issue needs sorting out first.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).