🚀 go-pugleaf

In GNU Emacs 18.56.13 of Mon May 13 1991 on dblues (silicon-graphics-unix)

compile.el is: Copyright (C) 1985, 1986 Free Software Foundation, Inc.

The function compilation-parse-errors, in compile.el, gets really
confused if it parses an error line that isn't actually in the file:
subsequent messages, even when they are in the file, are "fingered" at
the wrong place.

Arguably, I suppose, it's entitled to be confused, since the compiler
(or whatever) said such a dumb thing.  But a little robustness seems
to be cheap, and real examples exist in what I take to be common
circulation.  The example I encountered is YACC (don't know about
Bison): given the proper flags, it will cause the compiler to produce
error messages that refer to the YACC input, rather than to the
intermediate C file.  Yet, the intermediate file contains several
warnings in code not provided by me, and (at least with my compiler),
some of these warnings, at bogus lines, come out before some of the
other warnings at real lines.  For example:

"layout.y++", line 720: warning:  statement after goto not reached
"layout.y++", line 116: error: bad operand types
	ListableString * ListableString  for +=
"layout.y++", line 705: warning: label yynewstate  not used
"layout.y++", line 705: warning: label yyerrlab  not used

The error is real, and it's mine, and it really is on line 116 of my
yacc input file.  The three warnings are real enough, but they're not
mine and they're not even in the .y++ file (input to yacc), they're in
the intermediate C (actually, c++) file.  When the first bogoid one is
parsed, it confuses everything, and the real one "appears" to be at
the top of the file.

A patch is simple.  Where the present code has:

		      ;; Go to that buffer and find the erring line.
		      ...
		(forward-line (- linenum last-linenum))
		(setq last-linenum linenum)

make it read:

		      ;; Go to that buffer and find the erring line.
		      ...
		(setq last-linenum (- linenum ; In case hit eob
				      (forward-line (- linenum last-linenum))))

I believe this covers both the case of "reported line number off the
tail of the file" and "reported line number off the head," although it
would take a truely brain-dead processor to report negative line
numbers!



Jack Repenning			9U-530	     jackr@wpd.sgi.com
Silicon Graphics, Inc.		            Off:(415) 335-7477
Systems Software Technology Center	    Fax:(415) 969-2314