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

[Alan Mackenzie]

Hello, Stefan.

On Sun, Mar 10, 2024 at 20:50:05 -0400, Stefan Monnier wrote:
> >> No matter how many extra tests you add to reduce the frequency, you're
> >> fundamentally adding a bug :-(

> > Well, macroexp--expand-all has treated (function (lambda ...)) as a
> > function long before I started on this project in November.

> Of course it does, and that's correct, because by definition the
> argument to `macroexp--expand-all` must be source code expression.

> > Would trusting the same thing in backquote-process be any
> > more dangerous?

> Yup, because backquote has no guarantee that the code it must produce is
> one that will build a source code expression.

> > How about adding (an) extra arm(s) to the large pcase in
> > macroexp--expand-all which would recognise backquote's output for
> > "evaluated" lambdas.

> > What we get back from backquote looks like:

> > (cons 'lambda (cons plain-args body)) or
> > (list 'lambda args)) or maybe one or two other forms.

> Same problem:

>     (cons 'lambda (cons plain-args body))

> constructs something that may look like a function but that may not be
> intended to be used as a function.  All we know is that it should build
> a list with a `lambda` symbol in it.

> It's only when the result of the execution of this code is passed to
> `macroexp--expand-all` that we discover that it was meant to build
> a list that represents the source code of a function; and only at *that*
> point are we allowed to modify that list by macro-expanding expressions
> in its body, modifying its docstring, byte-compiling, etc...

OK, so it seems like I'll need a new pcase arm in macroexp--expand-all,
and this new code will need to handle (function (cons 'lambda ...)), and
the like.

I'll not actually be able to do too much in the next few days, though.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).