[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: Tue, 27 Nov 2018 13:37:29 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1

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.

reply via email to

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