* bug#49624: compilation message end-column function off-by-one bug
@ 2021-07-18 19:00 Mattias Engdegård
2021-07-18 19:10 ` Eli Zaretskii
0 siblings, 1 reply; 8+ messages in thread
From: Mattias Engdegård @ 2021-07-18 19:00 UTC (permalink / raw)
To: 49624; +Cc: Stefan Monnier, Juri Linkov
[-- Attachment #1: Type: text/plain, Size: 738 bytes --]
Compilation message patterns (in compilation-regexp-alist and -alist) can indicate starting and ending line and column numbers, either by supplying regexp match numbers or functions that return the respective line/column numbers when called. In other words, the integer N can be understood as a shorthand for the function
(lambda () (and (match-beginning N) (string-to-number (match-string N))))
except that isn't true for the ending column where there is a difference of 1; an END-COL function returning 13 means that the error's last column is 12.
There does not seem to be a good justification for this nor is it documented so it's probably just a bug; proposed patch attached below. Does it warrant a mention in etc/NEWS?
[-- Attachment #2: 0001-Fix-off-by-one-error-in-compilation-rule-end-column-.patch --]
[-- Type: application/octet-stream, Size: 3418 bytes --]
From a2303f4651e225115207bad778024f913dc6dacb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Mattias=20Engdeg=C3=A5rd?= <mattiase@acm.org>
Date: Sun, 18 Jul 2021 20:32:49 +0200
Subject: [PATCH] Fix off-by-one error in compilation rule end-column function
* lisp/progmodes/compile.el (compilation-error-properties):
When the end-column parameter of a compilation message rule is
a function, treat its return value the same way as textually
supplied values by adjusting both values in the same way.
---
lisp/progmodes/compile.el | 13 ++++++++-----
test/lisp/progmodes/compile-tests.el | 27 +++++++++++++++++++++++++++
2 files changed, 35 insertions(+), 5 deletions(-)
diff --git a/lisp/progmodes/compile.el b/lisp/progmodes/compile.el
index e4363e11b8..02d1c58858 100644
--- a/lisp/progmodes/compile.el
+++ b/lisp/progmodes/compile.el
@@ -1248,11 +1248,14 @@ compilation-error-properties
(setq col (match-string-no-properties col))
(string-to-number col))))
(setq end-col
- (or (if (functionp end-col) (funcall end-col)
- (and end-col
- (setq end-col (match-string-no-properties end-col))
- (- (string-to-number end-col) -1)))
- (and end-line -1)))
+ (let ((ec (if (functionp end-col)
+ (funcall end-col)
+ (and end-col (match-beginning end-col)
+ (string-to-number
+ (match-string-no-properties end-col))))))
+ (if ec
+ (1+ ec) ; Add one to get an exclusive upper bound.
+ (and end-line -1))))
(if (consp type) ; not a static type, check what it is.
(setq type (or (and (car type) (match-end (car type)) 1)
(and (cdr type) (match-end (cdr type)) 0)
diff --git a/test/lisp/progmodes/compile-tests.el b/test/lisp/progmodes/compile-tests.el
index 0623cec528..2a3bb3dafa 100644
--- a/test/lisp/progmodes/compile-tests.el
+++ b/test/lisp/progmodes/compile-tests.el
@@ -515,4 +515,31 @@ compile-test-grep-regexps
(compile--test-error-line testcase))
(should (eq compilation-num-errors-found 8))))
+(ert-deftest compile-test-functions ()
+ "Test rules using functions instead of regexp group numbers."
+ (let* ((file-fun (lambda () '("my-file")))
+ (line-start-fun (lambda () 123))
+ (line-end-fun (lambda () 134))
+ (col-start-fun (lambda () 39))
+ (col-end-fun (lambda () 24))
+ (compilation-error-regexp-alist-alist
+ `((my-rule
+ ,(rx bol "My error message")
+ ,file-fun
+ (,line-start-fun . ,line-end-fun)
+ (,col-start-fun . ,col-end-fun))))
+ (compilation-error-regexp-alist '(my-rule)))
+ (with-temp-buffer
+ (font-lock-mode -1)
+ (let ((compilation-num-errors-found 0)
+ (compilation-num-warnings-found 0)
+ (compilation-num-infos-found 0))
+ (compile--test-error-line
+ '(my-rule
+ "My error message"
+ 1 (39 . 24) (123 . 134) "my-file" 2))
+ (should (eq compilation-num-errors-found 1))
+ (should (eq compilation-num-warnings-found 0))
+ (should (eq compilation-num-infos-found 0))))))
+
;;; compile-tests.el ends here
--
2.21.1 (Apple Git-122.3)
^ permalink raw reply related [flat|nested] 8+ messages in thread
* bug#49624: compilation message end-column function off-by-one bug
2021-07-18 19:00 bug#49624: compilation message end-column function off-by-one bug Mattias Engdegård
@ 2021-07-18 19:10 ` Eli Zaretskii
2021-07-18 19:13 ` Mattias Engdegård
0 siblings, 1 reply; 8+ messages in thread
From: Eli Zaretskii @ 2021-07-18 19:10 UTC (permalink / raw)
To: Mattias Engdegård; +Cc: 49624, monnier, juri
> From: Mattias Engdegård <mattiase@acm.org>
> Date: Sun, 18 Jul 2021 21:00:41 +0200
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, Juri Linkov <juri@linkov.net>
>
> Compilation message patterns (in compilation-regexp-alist and -alist) can indicate starting and ending line and column numbers, either by supplying regexp match numbers or functions that return the respective line/column numbers when called. In other words, the integer N can be understood as a shorthand for the function
>
> (lambda () (and (match-beginning N) (string-to-number (match-string N))))
>
> except that isn't true for the ending column where there is a difference of 1; an END-COL function returning 13 means that the error's last column is 12.
Isn't that because END-COL is the first column _beyond_ the last
column?
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#49624: compilation message end-column function off-by-one bug
2021-07-18 19:10 ` Eli Zaretskii
@ 2021-07-18 19:13 ` Mattias Engdegård
2021-07-18 19:30 ` Eli Zaretskii
0 siblings, 1 reply; 8+ messages in thread
From: Mattias Engdegård @ 2021-07-18 19:13 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 49624, monnier, juri
18 juli 2021 kl. 21.10 skrev Eli Zaretskii <eliz@gnu.org>:
> Isn't that because END-COL is the first column _beyond_ the last
> column?
Yes, that is probably the origin of the bug. However as that is just the internal representation (column range as a half-open interval) it should not be visible to the user.
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#49624: compilation message end-column function off-by-one bug
2021-07-18 19:13 ` Mattias Engdegård
@ 2021-07-18 19:30 ` Eli Zaretskii
2021-07-19 10:39 ` Mattias Engdegård
0 siblings, 1 reply; 8+ messages in thread
From: Eli Zaretskii @ 2021-07-18 19:30 UTC (permalink / raw)
To: Mattias Engdegård; +Cc: 49624, monnier, juri
> Feedback-ID:mattiase@acm.or
> From: Mattias Engdegård <mattiase@acm.org>
> Date: Sun, 18 Jul 2021 21:13:36 +0200
> Cc: 49624@debbugs.gnu.org, monnier@iro.umontreal.ca, juri@linkov.net
>
> 18 juli 2021 kl. 21.10 skrev Eli Zaretskii <eliz@gnu.org>:
>
> > Isn't that because END-COL is the first column _beyond_ the last
> > column?
>
> Yes, that is probably the origin of the bug. However as that is just the internal representation (column range as a half-open interval) it should not be visible to the user.
??? Why not?
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#49624: compilation message end-column function off-by-one bug
2021-07-18 19:30 ` Eli Zaretskii
@ 2021-07-19 10:39 ` Mattias Engdegård
[not found] ` <875yx6qtwg.fsf@mail.linkov.net>
0 siblings, 1 reply; 8+ messages in thread
From: Mattias Engdegård @ 2021-07-19 10:39 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 49624, monnier, juri
18 juli 2021 kl. 21.30 skrev Eli Zaretskii <eliz@gnu.org>:
> ??? Why not?
Not sure what you mean (and I don't really think it's something we disagree about) but in any case it's beside the point. Emacs should behave as expected by the user, as documented, and in a consistent way. Currently it does neither.
The more I think about it, the clearer it becomes that it's a plain bug which I'm making too much fuss about and should just go ahead and fix the stupid thing. It was mainly reported on the unlikely chance that Juri and/or Stefan would remember something interesting about the code, but that's secondary.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2021-07-26 19:30 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-07-18 19:00 bug#49624: compilation message end-column function off-by-one bug Mattias Engdegård
2021-07-18 19:10 ` Eli Zaretskii
2021-07-18 19:13 ` Mattias Engdegård
2021-07-18 19:30 ` Eli Zaretskii
2021-07-19 10:39 ` Mattias Engdegård
[not found] ` <875yx6qtwg.fsf@mail.linkov.net>
[not found] ` <5BAAD7D4-A578-4DB5-925E-ECE02B4F4B56@acm.org>
[not found] ` <87pmvevv28.fsf@mail.linkov.net>
2021-07-23 13:24 ` Mattias Engdegård
2021-07-26 17:06 ` Juri Linkov
2021-07-26 19:30 ` Mattias Engdegård
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).