bug#73725: Master: Wrong position for byte compiler warning message.

[Alan Mackenzie <acm@muc.de>]

Hello, Stefan.

On Tue, Oct 22, 2024 at 09:33:02 -0400, Stefan Monnier wrote:

[ .... ]

> >> >  (defun macroexp-macroexpand (form env)
> >> >    "Like `macroexpand' but checking obsolescence."
> >> >    (let* ((macroexpand-all-environment env)
> >> >           new-form)
> >> > +    (macroexp-preserve-posification
> >> > +     form
> >> >      (while (not (eq form (setq new-form (macroexpand-1 form env))))
> >> > +       (setq macroexpanded t)
> >> >        (let ((fun (car-safe form)))
> >> >          (setq form
> >> >                (if (and fun (symbolp fun)

> >> This `(setq macroexpanded t)` looks like some leftover code, at least
> >> I couldn't find this var declared or used elsewhere.

> > I remember removing it, but can't remember exactly why.  When I byte
> > compile the code, I don't get an undeclared variable warning for it, for
> > some reason.

> [ Interesting.  I'll try to remember to track down this sucker later.  ]

I think I understand this, now.  It's a "use-mention" confusion.  ;-).

When macroexp-macroexpand is getting compiled, the compiler calls (the
loaded or compiled version of) that function.  Running the function
`setq's macroexpanded, hence binds it.

Later, the compiler calls byte-compile-free-vars-warn.  This fails to do
anything because of the clause (boundp var) in the enclosing `unless'
form.  VAR aka macroexpanded is indeed now bound, see previous
paragraph.

I'm not sure there's much that can be done about this "bug".  I'm even
less sure that it's worth the trouble.  Maybe there could be a more
rigorous check of the variable's existence than (boundp var).  But, as I
say, it's likely not worth the trouble.  Maybe there are other free
variables hiding in the compiler, though.

What do you think?

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).