GNU bug report logs - #24449
Emacs 25.1 RC2: Byte compiler reports error in wrong place.

Previous Next

Package: emacs;

Reported by: Alan Mackenzie <acm <at> muc.de>

Date: Fri, 16 Sep 2016 11:33:01 UTC

Severity: minor

Found in versions 23.0.91, 23.3.1, 24.0.50, 24.3.1, 25.0.50, 25.1

Done: Alan Mackenzie <acm <at> muc.de>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24449 <at> debbugs.gnu.org
Subject: bug#24449: Emacs 25.1 RC2: Byte compiler reports error in wrong place.
Date: Fri, 16 Sep 2016 18:34:51 +0000
On Fri, Sep 16, 2016 at 06:09:38PM +0300, Eli Zaretskii wrote:
> > Date: Fri, 16 Sep 2016 13:33:52 +0000
> > Cc: 24449 <at> debbugs.gnu.org
> > From: Alan Mackenzie <acm <at> muc.de>
> > 
> > > If you didn't, you should, because after you do, you will never again
> > > wonder why an incorrect line number is reported.  In fact, now that I
> > > did look there, I'm surprised it reports a correct line number at all,
> > > let alone as often as it does.  It's sheer luck.
> > 
> > This is not a Good Thing.  Even its own comment describes itself as a
> > "gross hack".  Surely we can do better?

> I certainly hope we can.  But, unless I misunderstood something, the
> way it's designed makes that really hard.

After studying `byte-compile-set-symbol-position' for several hours, I
can now see what it's meant to do, and the bug that prevents it doing
it.

The variable `last' was intended to record the previous value of
byte-compile-last-position to ensure that its next value would be higher
than the previous one.  Part of the comment was intended to express
this.  But in some sort of coding error, `last' ended up being set at
each iteration of the loop, making it purposeless.

By binding `last' to its intended value at the start of
`b-c-set-symbol-position', and amending the loop condition to avoid an
infinite loop, the warning message for the faulty cc-engine.el now comes
out at the right place.  I'm not sure my new version provides any
guarantee of correctness either, but I think it's more likely.

Here is my patch.  I still think I should amend the comment preceding
it.



diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el
index b6bb1d6..2502323 100644
--- a/lisp/emacs-lisp/bytecomp.el
+++ b/lisp/emacs-lisp/bytecomp.el
@@ -1042,19 +1042,20 @@ byte-compile-delete-first
 ;; gross hack?  And the answer, of course, would be yes.
 (defun byte-compile-set-symbol-position (sym &optional allow-previous)
   (when byte-compile-read-position
-    (let (last entry)
+    (let ((last byte-compile-last-position)
+          entry)
       (while (progn
-	       (setq last byte-compile-last-position
-		     entry (assq sym read-symbol-positions-list))
+	       (setq entry (assq sym read-symbol-positions-list))
 	       (when entry
 		 (setq byte-compile-last-position
 		       (+ byte-compile-read-position (cdr entry))
 		       read-symbol-positions-list
 		       (byte-compile-delete-first
 			entry read-symbol-positions-list)))
-	       (or (and allow-previous
-                        (not (= last byte-compile-last-position)))
-		   (> last byte-compile-last-position)))))))
+	       (and entry
+                    (or (and allow-previous
+                             (not (= last byte-compile-last-position)))
+                        (> last byte-compile-last-position))))))))
 
 (defvar byte-compile-last-warned-form nil)
 (defvar byte-compile-last-logged-file nil)


Comments?

-- 
Alan Mackenzie (Nuremberg, Germany).




This bug report was last modified 8 years and 308 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.