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

[Paul Eggert <eggert@cs.ucla.edu>]

On 11/30/18 10:55 AM, Alan Mackenzie wrote:
> There are no performance "issues".  Emacs with this bug fix is minutely
> slower than without it, not enough to matter.

I'm afraid we'll have to disagree about that. It's not worth slowing all 
Emacs computations by 3.5% - 10% or whatever, merely to get 
more-accurate locations in byte-compiler diagnostics. That is a 
significant slowdown, and it's too much of a price to pay for such a 
small benefit.

I too have played with the idea to redefine eq, for a different purpose 
(so that bignums behave more like fixnums), and I gave it up because of 
similar slowdowns. It wasn't worth the cost there either. Sometimes 
ideas just don't work out.

> The point of the exercise is specific, not vague as you have
> misformulated it.  It is to print the correct source locations in
> compiler warnings which are currently being output as wrong locations.
> For example, read bug #9109.
Bug #9109 could be fixed by a read variant that returns 
symbols-with-positions, by changing the byte-compiler to understand the 
output of this read variant, and by having the byte compiler remove 
position information before passing a subexpression to a macro. It could 
also be fixed by a read variant that returns conses-with-positions. 
Neither fix would slow down ordinary code. However, as I understand it, 
we don't want either fix because these fixes would still generate subpar 
locations in diagnostics when byte-compiling other code that calls 
macros. This is why I have been thinking about other code errors that 
involve macros, errors that you say are out of scope.

When trying to consider alternatives to scratch/accurate-warning-pos, I 
was trying to get an understanding of problem scope that is independent 
of the proposed solution. Unfortunately I failed to do that, and this 
makes it difficult to consider alternatives.