bug#53526: 29.0.50; macroexp-warn-and-return API change

[Alan Mackenzie <acm@muc.de>]

Hello, Stefan.

On Tue, Jan 25, 2022 at 11:56:22 -0500, Stefan Monnier wrote:
> Package: Emacs
> Version: 29.0.50


> The following change in `macroexp.el` on `master` is not backward
> compatible with the Emacs-28 API:

> -(defun macroexp-warn-and-return (msg form &optional category compile-only)
> +(defun macroexp-warn-and-return (arg msg form &optional category compile-only)

No, it isn't.  All the uses of the function are in lisp/emacs-lisp, and
I understood the function to be an internal one.

> I suspect that the `arg` should be added at the end instead.

The other functions (like byte-compile-warn-x) which have acquired this
extra argument need to have it at the start, since there are an
indeterminate number of &rest args going into a `format'.  So it seemed
better just to do the same with this function, to preserve a sort of
compatibility.

> While I'm here I also noticed that `byte-compile-form-stack` is a poor
> name for a variable declared in `macroexp.el`.

It's an integral part of bytecomp.el.  It got moved to macroexp.el
because it is used (twice) there, and that file is loaded into bootstrap
emacs before bytecomp.el.

There is precedent for this "mis"naming, namely
byte-compile-bound-variables.

> It should either be renamed to use the `macroexp-` prefix, or moved to
> `bytecomp.el` (and it probably should have a double-hyphen, since I
> think it's not meant to be used by anyone but us).

It started off life with a double hyphen in bytecomp.el.  But when it
started getting used in macroexp.el (during the expansion of a macro) it
lost the extra hyphen and got moved there.  It's no big deal, I think,
just that there's no completely neat way of doing this, so the
compromise actually used is pretty arbitrary.  If the variable were in
bytecomp.el, we'd probably need a boundp call in the two places we use
it in macroexp.el.

Whilst on the topic of macroexp-warn-and-return (and
macroexp--wrap-warn), I have to admit having difficulty understanding
these functions, both how they work and what they're for.

My impression up till a couple of days ago was that they were ways of
coping with the old warning position mechanism, and were intended to
compensate for its deficiencies.

Now, I'm much less sure.  Was I indeed mistaken?  If I was, what then is
the purpose of these functions, which defer warning messages in some
fashion?  If I was right, it would be a good thing to dismantle them,
since they are complicated and difficult, and no longer needed.  As I
said, I don't really understand them.

Thanks!

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).