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

[Paul Eggert]

On 11/30/18 2:02 PM, Alan Mackenzie wrote:
> > 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.
> Please stop being so disparaging.  There's nothing "mere" about accurate
> compiler messages, and the current bug fix delivers CORRECT locations,
> not "more-accurate" ones.

I value performance and the error message location issues don't bother 
me much in practice, perhaps partly because I tend to break Lisp code 
into smaller pieces so the exact location of the error doesn't matter 
that much. Evidently your preferences differ: the location issues bother 
you, and your machine is faster and/or you don't mind the performance 
hit. That doesn't make you right and me wrong, or vice versa. It's a 
matter of balancing priorities.


> Remember, in a bootstrap, only 25% of
> these locations are correct.  People notice, and it makes us maintainers
> look incompetent and stupid.

My impression is more that it's the presence of the diagnostics, not the 
line numbers in the diagnostics, that are makes us developers look 
"incompetent and stupid" (I would say "spread too thin" but maybe that's 
just me :-).

And even if this were a public-relations issue that could be fixed by 
proper line numbers (an assertion I'm skeptical of), I proposed a 
solution that will work for this particular issue and won't involve 
slowing down Emacs significantly in ordinary use, namely, use a separate 
Emacs binary for batch byte compiling when bootstrapping.

> > 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.
> No doubt, you found some alternative.

Sure, and my alternative then was to live with Emacs as it is. That's 
preferable to making Emacs significantly slower for a relatively minor 
benefit.


> > 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.
> That wouldn't work.

It would work for the test case in Bug#9101. It no doubt would not work 
for some other examples. The point is that it's not clear (to me, at 
least) what the scope of the problem is, and we don't seem to be making 
progress on delineating the scope, and without knowing the scope it's 
hard to suggest or evaluate alternative solutions.


> scratch/accurate-warning-pos is looking like the only
> pracaticable solution to these many bugs.  It is a bad solution, yes,
> but there are no good ones, and it is the least bad from what's
> available.
All in all the status quo is preferable to scratch/accurate-warning-pos. 
Although I don't expect you to agree with me on this, I don't think I'm 
alone in having concerns about the significant performance issues here.