unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Incorrect byte compiler error/warning message positions. A possible fix.
@ 2021-11-14 19:13 Alan Mackenzie
  2021-11-15  5:22 ` Lars Ingebrigtsen
  0 siblings, 1 reply; 8+ messages in thread
From: Alan Mackenzie @ 2021-11-14 19:13 UTC (permalink / raw)
  To: emacs-devel

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).



^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2021-11-16 17:05 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-11-14 19:13 Incorrect byte compiler error/warning message positions. A possible fix Alan Mackenzie
2021-11-15  5:22 ` Lars Ingebrigtsen
2021-11-15  5:29   ` Po Lu
2021-11-15 11:52     ` Alan Mackenzie
2021-11-15 11:49   ` Alan Mackenzie
2021-11-15 21:19     ` Stefan Monnier
2021-11-16  7:32       ` Lars Ingebrigtsen
2021-11-16 17:05       ` Alan Mackenzie

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).