* bug#13335: 24.1; compilation misparses GNU-style message locations
@ 2013-01-02 14:53 Mattias Engdegård
2013-01-10 7:53 ` Glenn Morris
0 siblings, 1 reply; 5+ messages in thread
From: Mattias Engdegård @ 2013-01-02 14:53 UTC (permalink / raw)
To: 13335
According to the GNU standards, a valid error message format is
FILE:LINE.COL1-COL2: MESSAGE
but this is not parsed correctly by the "gnu" regexp in compile.el;
it is interpreted as the line range LINE-COL2 starting at column COL1.
The consequence is that Emacs does not highlight the correct part of the
buffer when entering the file at that location.
This was disovered when writing a tool whose diagnostics would work
nicely with Emacs. Using the longer form
FILE:LINE.COL1-LINE.COL2: TEXT
worked correctly. According to etc/compilation.txt, it looks like the
intention is to allow either format.
The "gnu" regexp is quite complex and it is not immediately obvious
what is wrong. There is also what appears to be a superfluous backslash
on the last line:
*[Ee]rror\\|\[0-9]?\\(?:[^0-9\n]\\|$\\)\\|[0-9][0-9][0-9]\\)"
^
Since "\[" just means "[", this does not affect the actual regexp.
In GNU Emacs 24.1.1 (x86_64-unknown-linux-gnu, X toolkit, Xaw3d scroll
bars)
of 2012-07-30 on bach.e.vtech
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#13335: 24.1; compilation misparses GNU-style message locations
2013-01-02 14:53 bug#13335: 24.1; compilation misparses GNU-style message locations Mattias Engdegård
@ 2013-01-10 7:53 ` Glenn Morris
2013-01-10 18:52 ` Mattias Engdegård
2013-01-14 1:08 ` Glenn Morris
0 siblings, 2 replies; 5+ messages in thread
From: Glenn Morris @ 2013-01-10 7:53 UTC (permalink / raw)
To: Mattias Engdegård; +Cc: 13335
Mattias Engdegård wrote:
> According to the GNU standards, a valid error message format is
>
> FILE:LINE.COL1-COL2: MESSAGE
>
> but this is not parsed correctly by the "gnu" regexp in compile.el;
> it is interpreted as the line range LINE-COL2 starting at column COL1.
Thanks. It seems there was a misunderstanding of what this format meant,
because in the Emacs test-suite it is also interpreted as LINE1.COL1-LINE2.
> The "gnu" regexp is quite complex and it is not immediately obvious
> what is wrong. There is also what appears to be a superfluous backslash
> on the last line:
>
> *[Ee]rror\\|\[0-9]?\\(?:[^0-9\n]\\|$\\)\\|[0-9][0-9][0-9]\\)"
> ^
> Since "\[" just means "[", this does not affect the actual regexp.
That does \[ look wrong, but I don't think it is related.
It seems difficult to do all the following with a single regexp and
still get the subexpressions to have the same numbers in each case:
LINE1
LINE1[.:]COL1
LINE1.COL1-COL2
LINE1.COL1-LINE2.COL2
LINE1-LINE2
LINE1-LINE2.COL2 # this seems to be something Emacs made up AFAICS
This is the best I can come up with:
*** lisp/progmodes/compile.el 2013-01-07 01:23:26 +0000
--- lisp/progmodes/compile.el 2013-01-10 07:42:50 +0000
***************
*** 134,139 ****
--- 134,140 ----
;; If you make any changes to `compilation-error-regexp-alist-alist',
;; be sure to run the ERT test in test/automated/compile-tests.el.
+ ;; emacs -batch -l compile-tests.el -f ert-run-tests-batch-and-exit
(defvar compilation-error-regexp-alist-alist
'((absoft
***************
*** 261,268 ****
;; The "in \\|from " exception was added to handle messages from Ruby.
"^\\(?:[[:alpha:]][-[:alnum:].]+: ?\\|[ \t]+\\(?:in \\|from \\)\\)?\
\\([0-9]*[^0-9\n]\\(?:[^\n :]\\| [^-/\n]\\|:[^ \n]\\)*?\\): ?\
! \\([0-9]+\\)\\(?:[.:]\\([0-9]+\\)\\)?\
! \\(?:-\\([0-9]+\\)?\\(?:\\.\\([0-9]+\\)\\)?\\)?:\
\\(?: *\\(\\(?:Future\\|Runtime\\)?[Ww]arning\\|W:\\)\\|\
*\\([Ii]nfo\\(?:\\>\\|rmationa?l?\\)\\|I:\\|instantiated from\\|[Nn]ote\\)\\|\
*[Ee]rror\\|\[0-9]?\\(?:[^0-9\n]\\|$\\)\\|[0-9][0-9][0-9]\\)"
--- 262,269 ----
;; The "in \\|from " exception was added to handle messages from Ruby.
"^\\(?:[[:alpha:]][-[:alnum:].]+: ?\\|[ \t]+\\(?:in \\|from \\)\\)?\
\\([0-9]*[^0-9\n]\\(?:[^\n :]\\| [^-/\n]\\|:[^ \n]\\)*?\\): ?\
! \\([0-9]+\\)\\(?:-\\(?4:[0-9]+\\)\\(?:\\.\\(?5:[0-9]+\\)\\)?\
! \\|[.:]\\(?3:[0-9]+\\)\\(?:-\\(?:\\(?4:[0-9]+\\)\\.\\)?\\(?5:[0-9]+\\)\\)?\\)?:\
\\(?: *\\(\\(?:Future\\|Runtime\\)?[Ww]arning\\|W:\\)\\|\
*\\([Ii]nfo\\(?:\\>\\|rmationa?l?\\)\\|I:\\|instantiated from\\|[Nn]ote\\)\\|\
*[Ee]rror\\|\[0-9]?\\(?:[^0-9\n]\\|$\\)\\|[0-9][0-9][0-9]\\)"
=== modified file 'test/automated/compile-tests.el'
*** test/automated/compile-tests.el 2013-01-01 09:11:05 +0000
--- test/automated/compile-tests.el 2013-01-10 07:39:23 +0000
***************
*** 176,183 ****
("foo.c:8.23: note: message" 1 23 8 "foo.c")
("foo.c:8.23: info: message" 1 23 8 "foo.c")
("foo.c:8:23:information: message" 1 23 8 "foo.c")
! ("foo.c:8.23-45: Informational: message" 1 (23 . nil) (8 . 45) "foo.c")
("foo.c:8-23: message" 1 nil (8 . 23) "foo.c")
("foo.c:8-45.3: message" 1 (nil . 4) (8 . 45) "foo.c")
("foo.c:8.23-9.1: message" 1 (23 . 2) (8 . 9) "foo.c")
("jade:dbcommon.dsl:133:17:E: missing argument for function call"
--- 176,185 ----
("foo.c:8.23: note: message" 1 23 8 "foo.c")
("foo.c:8.23: info: message" 1 23 8 "foo.c")
("foo.c:8:23:information: message" 1 23 8 "foo.c")
! ("foo.c:8.23-45: Informational: message" 1 (23 . 46) (8 . nil) "foo.c")
("foo.c:8-23: message" 1 nil (8 . 23) "foo.c")
+ ;; The next one is not in the GNU standards AFAICS.
+ ;; Here we seem to interpret it as LINE1-LINE2.COL2.
("foo.c:8-45.3: message" 1 (nil . 4) (8 . 45) "foo.c")
("foo.c:8.23-9.1: message" 1 (23 . 2) (8 . 9) "foo.c")
("jade:dbcommon.dsl:133:17:E: missing argument for function call"
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#13335: 24.1; compilation misparses GNU-style message locations
2013-01-10 7:53 ` Glenn Morris
@ 2013-01-10 18:52 ` Mattias Engdegård
2013-01-10 20:32 ` Glenn Morris
2013-01-14 1:08 ` Glenn Morris
1 sibling, 1 reply; 5+ messages in thread
From: Mattias Engdegård @ 2013-01-10 18:52 UTC (permalink / raw)
To: Glenn Morris; +Cc: 13335
10 jan 2013 kl. 08.53 skrev Glenn Morris:
> LINE1-LINE2.COL2 # this seems to be something Emacs made up AFAICS
Is that something we need to keep, or do you consider it a "regression"
to remove it? It does not look very useful to me (a range of lines but
the same column?).
Anyway, I can confirm that your patch works for a very small variety
of tools (including the bug subject). Thanks for taking care of this.
What about transforming that regexp into rx form, by the way?
Besides being a more readable form (and fewer backslashes),
it would also permit explanatory comments to be put at their natural
places inside.
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#13335: 24.1; compilation misparses GNU-style message locations
2013-01-10 18:52 ` Mattias Engdegård
@ 2013-01-10 20:32 ` Glenn Morris
0 siblings, 0 replies; 5+ messages in thread
From: Glenn Morris @ 2013-01-10 20:32 UTC (permalink / raw)
To: Mattias Engdegård; +Cc: 13335
Mattias Engdegård wrote:
>> LINE1-LINE2.COL2 # this seems to be something Emacs made up AFAICS
>
> Is that something we need to keep, or do you consider it a "regression"
> to remove it? It does not look very useful to me (a range of lines but
> the same column?).
It does look fairly nonsensical...
> What about transforming that regexp into rx form, by the way?
> Besides being a more readable form (and fewer backslashes),
> it would also permit explanatory comments to be put at their natural
> places inside.
More comments would be good, but could be inserted just as easily by
breaking the regexp up using concat, so personally I don't see any need
to switch to rx. (I don't always find rx more readable.)
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#13335: 24.1; compilation misparses GNU-style message locations
2013-01-10 7:53 ` Glenn Morris
2013-01-10 18:52 ` Mattias Engdegård
@ 2013-01-14 1:08 ` Glenn Morris
1 sibling, 0 replies; 5+ messages in thread
From: Glenn Morris @ 2013-01-14 1:08 UTC (permalink / raw)
To: 13335-done
Version: 24.4
Fixed in trunk.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2013-01-14 1:08 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-01-02 14:53 bug#13335: 24.1; compilation misparses GNU-style message locations Mattias Engdegård
2013-01-10 7:53 ` Glenn Morris
2013-01-10 18:52 ` Mattias Engdegård
2013-01-10 20:32 ` Glenn Morris
2013-01-14 1:08 ` Glenn Morris
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.