GNU bug report logs - #13335
24.1; compilation misparses GNU-style message locations

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 13335 in the body.
You can then email your comments to 13335 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> bredband.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.1; compilation misparses GNU-style message locations
Date: Wed, 2 Jan 2013 15:53:19 +0100

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

Message #8 received at 13335 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Mattias Engdegård <mattiase <at> bredband.net>
Cc: 13335 <at> debbugs.gnu.org
Subject: Re: bug#13335: 24.1; compilation misparses GNU-style message locations
Date: Thu, 10 Jan 2013 02:53:52 -0500

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"

Message #11 received at 13335 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> bredband.net>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 13335 <at> debbugs.gnu.org
Subject: Re: bug#13335: 24.1; compilation misparses GNU-style message locations
Date: Thu, 10 Jan 2013 19:52:31 +0100

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.

Message #14 received at 13335 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Mattias Engdegård <mattiase <at> bredband.net>
Cc: 13335 <at> debbugs.gnu.org
Subject: Re: bug#13335: 24.1; compilation misparses GNU-style message locations
Date: Thu, 10 Jan 2013 15:32:18 -0500

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.)

Message #19 received at 13335-done <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: 13335-done <at> debbugs.gnu.org
Subject: Re: bug#13335: 24.1; compilation misparses GNU-style message locations
Date: Sun, 13 Jan 2013 20:08:35 -0500

Version: 24.4

Fixed in trunk.

Previous Next

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