unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Order of associations in compilation-error-regexp-alist-alist
@ 2012-09-24  6:28 Eli Zaretskii
  2012-09-24  7:00 ` Chong Yidong
  0 siblings, 1 reply; 5+ messages in thread
From: Eli Zaretskii @ 2012-09-24  6:28 UTC (permalink / raw)
  To: emacs-devel

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?



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Order of associations in compilation-error-regexp-alist-alist
  2012-09-24  6:28 Order of associations in compilation-error-regexp-alist-alist Eli Zaretskii
@ 2012-09-24  7:00 ` Chong Yidong
  2012-09-24  7:06   ` Eli Zaretskii
  0 siblings, 1 reply; 5+ messages in thread
From: Chong Yidong @ 2012-09-24  7:00 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

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.



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Order of associations in compilation-error-regexp-alist-alist
  2012-09-24  7:00 ` Chong Yidong
@ 2012-09-24  7:06   ` Eli Zaretskii
  2012-09-24  7:13     ` Chong Yidong
  0 siblings, 1 reply; 5+ messages in thread
From: Eli Zaretskii @ 2012-09-24  7:06 UTC (permalink / raw)
  To: Chong Yidong; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Order of associations in compilation-error-regexp-alist-alist
  2012-09-24  7:06   ` Eli Zaretskii
@ 2012-09-24  7:13     ` Chong Yidong
  2012-10-14  7:42       ` Eli Zaretskii
  0 siblings, 1 reply; 5+ messages in thread
From: Chong Yidong @ 2012-09-24  7:13 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

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.



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Order of associations in compilation-error-regexp-alist-alist
  2012-09-24  7:13     ` Chong Yidong
@ 2012-10-14  7:42       ` Eli Zaretskii
  0 siblings, 0 replies; 5+ messages in thread
From: Eli Zaretskii @ 2012-10-14  7:42 UTC (permalink / raw)
  To: Chong Yidong; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2012-10-14  7:42 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-09-24  6:28 Order of associations in compilation-error-regexp-alist-alist Eli Zaretskii
2012-09-24  7:00 ` Chong Yidong
2012-09-24  7:06   ` Eli Zaretskii
2012-09-24  7:13     ` Chong Yidong
2012-10-14  7:42       ` Eli Zaretskii

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).