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

[Alan Mackenzie <acm@muc.de>]

Hello, Paul.

On Fri, Nov 30, 2018 at 12:14:59 -0800, Paul Eggert wrote:
> 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.

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.

> That is a significant slowdown, .... 

No it isn't.  We could sit you down in front of each version of Emacs,
get you to play with them, and you would be unable to distinguish them
without using a machine to do timings.

> .... and it's too much of a price to pay for such a small benefit.

You think having compiler messages whose locations simulate a random
number generator is acceptable?  Remember, in a bootstrap, only 25% of
these locations are correct.  People notice, and it makes us maintainers
look incompetent and stupid.

> 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.

What you're saying is that being fast is more important than working
properly.  Taking that attitude to extremes, Emacs could be considerably
speeded up by removing some safety and sanity checks.

> Sometimes ideas just don't work out.

You're not willing to work on an alternative, though.  You weren't even
in on the conversation when we were discussing alternatives (or, more
precisely, the lack of alternatives).

> > 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.

That wouldn't work.  Macro expansion is done at an early stage of
compilation.  You can't remove arbitrary position information and still
expect to get accurate (or indeed any) positions in compiler messages.

> It could also be fixed by a read variant that returns
> conses-with-positions.

Only by rewriting the compiler such that that information is somehow
preserved as compilation progresses.  As long as you don't have any
macros which massage the code, that is.

> Neither fix would slow down ordinary code.

These were all considered earlier on, and dismissed as impractical or
non-working.

> 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.

If by "subpar" you mean no location at all (beyond, perhaps, the name of
the top-level function), then subpar describes it well.  And you're
talking about most code, typical code, here.  What proportion of defuns
doesn't contain a `when'?  Even `defun' itself is a macro.  ;-(

> This is why I have been thinking about other code errors that involve
> macros, errors that you say are out of scope.

They are out of scope, yes.  Expanding the scope into vague abstract
territory is an excellent way of postponing a solution for ever.

> 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.

Eli, Stefan and I had a wide ranging discussion about the possibilities.
If there had been alternatives, likely we would have stumbled across
them.  Maybe we missed something.  Feel free to take up that other
thread again if you've got anything to add.

But at the moment, 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.

-- 
Alan Mackenzie (Nuremberg, Germany).