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

[Alan Mackenzie <acm@muc.de>]

Hello, Emacs.

The byte compiler reports wrong source positions in its error and
warning messages; not every time, but perhaps most of the time.  There
are currently at least six open bugs for this problem, e.g. bug #22288.

I fixed the problem at the end of 2018 by introducing a new Emacs type
"symbol with position".  The position component of these symbols was
the position in the source code, generated by the reader.  Such a
position gave a correct source position for error/warning messages.

Unfortunately, this fix slowed Emacs down a little, and for this reason
it was rejected by the people here.  The bug remains unfixed.

The reason for the slowdown was the need for EQ continually to check a
flag which stated whether or not symbols with position were currently
active, which they weren't apart from when compiling.

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

I've recently returned to the bug and believe the symbols with position
idea can be made to work without the slowdown in EQ.

In the new scheme it is no longer true that (eq #<foo at 20081> 'foo).
The Lisp form for a function being compiled is manipulated as at
present, only its symbols will have positions.  These will get stripped
out of the symbols before final code generation.

The biggest problem is with macros, and I think I can solve this.
Arguments to macros are used in two ways:
(i) They are tested to see what code to generate.  What I call "USE"
(ii) They are returned as generated code, e.g. ",@body".  Call this
  "MENTION".
Clearly (i) won't work if the symbols have positions, (ii) needs the
positions for possible messages.

The answer to this is, whilst compiling the macro, to keep track of
whether a use of an argument is for USE or for MENTION and to generate
code to extract the bare symbol for USE.  This will involve little more
than having two or three dynamically bound variables to be tested
throughout the byte compiler.

There are mild complications, e.g. when a function contributes towards
the MENTION.  But these can be overcome.

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

This proposed fix is going to be more complicated than the one from
three years ago.  It will be able to reuse a lot of code from that
previous fix, though.

I intend to work on this in the coming weeks.

-- 
Alan Mackenzie (Nuremberg, Germany).