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

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

[Mattias Engdegård]

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

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

[Glenn Morris]

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"

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

[Mattias Engdegård]

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.

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

[Glenn Morris]

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

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

[Glenn Morris]

Version: 24.4

Fixed in trunk.