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

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Sat, Nov 17, 2018 at 15:13:51 +0200, Eli Zaretskii wrote:
> > Date: Sat, 17 Nov 2018 12:45:34 +0000
> > Cc: Michael Heerdegen <michael_heerdegen@web.de>,
> >   Clément Pit-Claudel <cpitclaudel@gmail.com>,
> >   emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > Eli, in bug #24128, you complained that in compiling progmodes/gud-mi.el
> > and progmodes/gud.el, you got warning message positions which were
> > clearly wrong.  Would it be possible to reconstruct the versions of those
> > files which gave these errors?  It would be great to be able to try them
> > out on this new software.

> The current version of gdb-mi.el still emits the warning.

I didn't see this, but never mind.

The branch scratch/accurate-warning-pos now bootstraps.  (It also now
runs on optimised builds. ;-)

Its bootstrap is a mere 7.1% slower than master's.

Currently, warning messages contain two source positions, that of the
traditional scheme, and of the new one.  A typical message currently
looks like this:

    cedet/srecode/find.el:248:57:247:35:Warning: Unknown slot `:application'

.  The old position was line 248 column 57, the new L247 C35.

The question arises, how different are the new positions from the old?
I saved the stderr from bootstrap to a file, and fed it through the
following AWK filter:

#########################################################################
#! /usr/bin/gawk -f
BEGIN { FS = ":" }

NF >= 6 {
    if (($2 == $4) && ($3 == $5))
        same++
    else {
        different++
        printf("%d: ", NR)
        print $0
    }
}

END {
    print
    printf("same: %d\n", same)
    printf("different: %d\n", different)
}
#########################################################################

.  There were 81 positions the same (old and new), there were 254
different.  A large part of these 254 different were "Warning: Unknown
slot".  In these warnings, the new position is correct, the old one is
incorrect.  In fact, of all the differences I've looked at, the new one
is always the correct one.

Thus, this branch works, and the idea behind it is sound.

There are one or two nastinesses in it: principally, I had to duplicate
the function byte-compile-strip-symbol-positions as
cl-macs-strip-symbol-positions to get the thing to bootstrap.  There is
surely a straightforward solution to this, but it escapes me at the
moment.

Although the branch works, it has been tested solely on 64-bit
GNU/Linux, the only system I have.  This despite some fairly hefty
changes in lisp.h.

So, where do we go from here?

-- 
Alan Mackenzie (Nuremberg, Germany).