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?