Order of associations in compilation-error-regexp-alist-alist

Order of associations in compilation-error-regexp-alist-alist

[Eli Zaretskii]

What's the deal with the significance of the order of associations in
compilation-error-regexp-alist-alist?  I don't see that mentioned
anywhere, and yet matching by next-error clearly follows that order,
by virtue of mapcar in compilation-error-regexp-alist.  This means
that if an error message matches more than one regexp there, the first
one wins.

Am I missing something?  Are users expected to modify the order by
customizing compilation-error-regexp-alist, or is it supposed to work
correctly out of the box for all the compilers already in the list?
If the latter, how do we make sure only the correct regexp matches?

A colleague came up to me complaining that Emacs no longer gleans the
file name from the error messages emitted by the Microsoft compiler
that comes with Visual Studio 2010.  It turned out that the cause was
that the blank marked below with "^=====" no longer exists in the
newer compiler's messages:

     (msft
      ;; The message may be a "warning", "error", or "fatal error" with
      ;; an error code, or "see declaration of" without an error code.
      "^ *\\([0-9]+>\\)?\\(\\(?:[a-zA-Z]:\\)?[^:(\t\n]+\\)(\\([0-9]+\\)) \
 : \\(?:see declaration\\|\\(?:warnin\\(g\\)\\|[a-z ]+\\) C[0-9]+:\\)"  ^=====
      2 3 nil (4))

I promptly made that blank optional, but the problem surprisingly
didn't go away.  It turned out that an earlier regexp, for EDG C/C++:

     (edg-1
      "^\\([^ \n]+\\)(\\([0-9]+\\)): \\(?:error\\|warnin\\(g\\)\\|remar\\(k\\)\\)"
      1 2 nil (3 . 4))

also matched the output.  However, in the MSVC message, the file name
was preceded by a "1>", which is supported by msft, but not by edg-1.
So the file name Emacs picked up was "1>foo.cpp", which ain't gonna
work.

What is the right fix for this?

Re: Order of associations in compilation-error-regexp-alist-alist

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

> This means that if an error message matches more than one regexp
> there, the first one wins.

Yep, and that's the way it's worked for ages.

> If the latter, how do we make sure only the correct regexp matches?

By cunning choice of ordering in compilation-error-regexp-alist.

See also test/automated/compile-tests.el, which is a regression test for
precisely this issue, and etc/compilation.txt for a non-ERT version.

Re: Order of associations in compilation-error-regexp-alist-alist

[Eli Zaretskii]

> From: Chong Yidong <cyd@gnu.org>
> Date: Mon, 24 Sep 2012 15:00:58 +0800
> Cc: emacs-devel@gnu.org
> 
> > If the latter, how do we make sure only the correct regexp matches?
> 
> By cunning choice of ordering in compilation-error-regexp-alist.

So moving msft before edg-1 would be an OK solution?

> See also test/automated/compile-tests.el, which is a regression test for
> precisely this issue, and etc/compilation.txt for a non-ERT version.

OK, thanks.  I knew about the latter, but it needs to be updated for
these new "features" of MSVC.

Re: Order of associations in compilation-error-regexp-alist-alist

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

> So moving msft before edg-1 would be an OK solution?

Yes, so long as the regression test tells you that this doesn't break
anything else.  You should also update compile-tests--test-regexps-data
and the corresponding line in etc/compilation.txt for the new MSVC
message format.

Re: Order of associations in compilation-error-regexp-alist-alist

[Eli Zaretskii]

> From: Chong Yidong <cyd@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Mon, 24 Sep 2012 15:13:44 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > So moving msft before edg-1 would be an OK solution?
> 
> Yes, so long as the regression test tells you that this doesn't break
> anything else.  You should also update compile-tests--test-regexps-data
> and the corresponding line in etc/compilation.txt for the new MSVC
> message format.

Done.