Re: Incorrect byte compiler error/warning message positions. A possible fix.

[Alan Mackenzie]

Hello, Stefan.

On Mon, Nov 15, 2021 at 16:19:47 -0500, Stefan Monnier wrote:
> >> In my experience, the vast majority of the warning messages point to the
> >> correct position.  But, yes, it does sometimes give the wrong position.
> > On 2018-11-22 (before you destroyed my test dataset by fixing all the
> > warnings in Emacs ;-) there were 335 warnings.  81 gave the correct
> > location, 254 a wrong one.

> FWIW, I think the current code gives (statistically) slightly less bad
> positions, because of changes I've made to `cconv` and `bytecomp`.
> That may explain Lars's impression.

> Our positions are still too often poor.  Some of us have just grown used
> to missing or poor location info and don't notice them any more :-(

I'm now fundamentally opposed to the use of terms like "poor" and
"inaccurate" here.  I prefer "wrong".  ;-)

> > They should be fairly easy (if, perhaps, tedious) to solve, because
> > everything is under our control.

> Agreed.

> > It's macros where people outside of our control do wierd and wonderful
> > things.  I think I know how to compile macros so that they both work,
> > yet preserve the symbols with position on the code they generate.
> > These compiled macros won't work on earlier versions of Emacs, but
> > that's a bridge to cross when we come to it.

> I'm curious know how you intend to make it work,

While a macro is being compiled it will use a dynamically bound variable
called, say, byte-comp-use.  When non-nil, it indicates the macro
may/should return executable code (i.e. without symbols with position).
When nil, byte-comp-use instructs the macro to return "code" containing
symbols with position, enabling the calling byte compiler to output
these positions in warning messages.

As macros call other macros, special forms in a macro will be enhanced
to bind byte-comp-use appropriately.  For example, in a progn (whose
last form is the result code), byte-comp-use will be t for all subforms
except the last.  In an `if' whose two arms are alternative result
codes, the condition form would have b-c-use t, each of the arms would
have nil.

Or something like that.

An alternative/additional idea is to have things like the evaluator
handle a symbol with position natively.  This would not slow Emacs down
the way amending EQ did three years ago; it would merely slow down the
generation of code from macros, probably not by very much.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).