all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 24449@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	[thread overview]
Message-ID: <20160916183451.GE3630@acm.fritz.box> (raw)
In-Reply-To: <83twdf51al.fsf@gnu.org>

On Fri, Sep 16, 2016 at 06:09:38PM +0300, Eli Zaretskii wrote:
> > Date: Fri, 16 Sep 2016 13:33:52 +0000
> > Cc: 24449@debbugs.gnu.org
> > From: Alan Mackenzie <acm@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).





  parent reply	other threads:[~2016-09-16 18:34 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-16 11:31 bug#24449: Emacs 25.1 RC2: Byte compiler reports error in wrong place Alan Mackenzie
2016-09-16 13:22 ` Eli Zaretskii
2016-09-16 13:33   ` Alan Mackenzie
2016-09-16 15:09     ` Eli Zaretskii
2016-09-16 16:08       ` Alan Mackenzie
2016-09-16 18:34       ` Alan Mackenzie [this message]
2016-09-16 19:03         ` Eli Zaretskii
2016-09-17  8:29           ` Alan Mackenzie
2016-09-17  9:35             ` Eli Zaretskii
2016-09-17 10:06               ` Andreas Schwab
2016-09-17 12:58               ` Alan Mackenzie
2016-09-17 19:56                 ` Michael Heerdegen
2016-09-17 20:46                   ` Alan Mackenzie
2016-09-17 20:51                     ` Michael Heerdegen
2016-09-17 20:59                       ` Alan Mackenzie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160916183451.GE3630@acm.fritz.box \
    --to=acm@muc.de \
    --cc=24449@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.