Re: scratch/accurate-warning-pos: Solid progress: the branch now bootstraps.

[Paul Eggert]

Alan Mackenzie wrote:

> Because of macros.  These macros are typically already compiled.

Even a compiled macro operates via the interpreter. So we could have a separate 
interpreter used only by the byte compiler. The byte-compiler interpreter would 
operate more slowly than the normal interpreter, but that's OK. The main and the 
byte-compiler interpreter could mostly be written with shared code, without 
slowing down the main interpreter. Admittedly this would not be a project for 
the fainthearted.

> If you could come up with a solid proposal which would fix the bug
> without slowing down Emacs at all, we'd all be most appreciative.

I'm afraid I don't understand the bug well enough yet to know whether any 
proposal I can come up with would be "solid". For one thing, any method of 
outputting source-code locations will founder in the presence of macros. Even 
GCC, which tries to do a reasonably good job of this and isn't limited by the 
Lisp reader, doesn't do well with the sort of C macros I tend to write. My 
admittedly uninformed guess is that there is no such thing as a "solid" solution 
here, only solutions that work better and/or worse on various example sets.

That being said, here's another possibility: don't bother attaching source-code 
positions to symbols, since duplicate symbols can be appear in the input and the 
source-code positions can't be retrieved reliably. Instead, attach positions to 
input objects that are guaranteed to be unique so that retrieval is trivial. Do 
the attachment via a hash table so that the input objects are unchanged and we 
don't need to change much of anything except the byte-compiler's diagnostic code 
(plus a read function that fills in the hash table as it reads). When the byte 
compiler needs the source code location corresponding to a symbol, it looks for 
the closest unique object nearby and uses its location.

For example, the source expression for the bug#22288 test case:

  (defun test () (let (a)) a)

has five conses in its top level list, two conses at the top of its second level 
list (let (a)), and one cons in its third level list (a). Each cons corresponds 
to a source code position (or if you prefer more accuracy, multiple positions 
for the start and end of the corresponding source-code and/or for the starts and 
ends of the source code corresponding to the cons's car and cdr). This will let 
the byte compiler narrow down where every subexpression lies, with significantly 
more accuracy than what we have now. In the bug#22288 example, the last cons in 
the top-level list should be attached to the precise source code location for 
the 'a' that we want to issue a diagnostic about.