[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paul Eggert
Subject: Re: scratch/accurate-warning-pos: Solid progress: the branch now bootstraps.
Date: Sun, 25 Nov 2018 17:41:39 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]