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

[Paul Eggert]

On 11/27/18 1:15 PM, Alan Mackenzie wrote:
> Anyhow, as far as creating a better solution than
> scratch/accurate-warning-pos goes, have you had any further thoughts?

Hash tables for cons locations would work well enough, if someone had 
the time to put into it. The main objection seems to be that the 
byte-compiler would lose track of location information. But we can fix 
the byte-compiler so that it doesn't lose track of the location 
information. That's purely a byte-compiler issue, which is a good thing 
for software engineering reasons as well as for performance reasons.

> I've thought about the double interpreter idea, and must confess I've no
> idea how one might go about implementing it in any reasonable time.

There's a simpler way to do a double interpreter. Use a compile-time 
test to decide whether eq operates slowly. Build two copies of Emacs, 
the slow one and the fast one, by compiling the slow one with -DSLOW_EQ 
(or whatever). Use the slow Emacs to byte-compile Emacs (and any other 
program that wants to be byte-compiled); this will output nicer 
diagnostics. Use the fast Emacs for everything else.

I'm not saying I *like* this solution (I don't). But it would address 
the problem of poor diagnostic locations when building Emacs, and it 
shouldn't slow Emacs down one bit in ordinary use.