GNU bug report logs - #3965
23.1.50; compilation-mode gnu error regexp mismatching ant, irix, gcc-include

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 3965 in the body.
You can then email your comments to 3965 AT debbugs.gnu.org in the normal way.

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

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Kevin Ryde <user42 <at> zip.com.au>
To: emacs-pretest-bug <at> gnu.org
Subject: 23.1.50; compilation-mode gnu error regexp mismatching ant, irix, gcc-include
Date: Thu, 30 Jul 2009 09:13:29 +1000

Doing

    (setq compilation-error-regexp-alist '(gnu))

and visiting etc/compilation.txt shows some mismatched parts.

Under "ant"

        [jikes]  foo.java:3:5:7:9: blah blah

Under "irix"

    cfe: Warning 600: xfe.c: 170: Not in a conditional directive while ...
    /usr/lib/cmplrs/cc/cfe: Error: foo.c: 1: blah blah
    /usr/lib/cmplrs/cc/cfe: warning: foo.c: 1: blah blah

And under "gcc-include"

                     from test_clt.cc:1:

In each the match has the wrong part as the filename.  For example the
"ant" one matches "[jikes] foo.java".  With all patterns enabled
`next-error' offers those wrong matches instead of what the specific
patterns for those parts get -- I suppose because the gnu match is
earlier in the line.

Maybe the "ant" and "gcc-include" cases could be attacked by not
allowing leading whitespace.  The "omake" indentation hack might get in
the way there; but is its indentation arbitrary, or a fixed-ish amount?

My best idea for the irix ones would be to disallow ": " in the gnu
pattern filename part.  Other colons could be allowed for dos drive
letters or the occasional filename with a colon, but rate colon+space as
more likely to be a separator than a part of a name.  Mind you the gnu
pattern is already far too complicated for me to want to do anything to
it :-)



In GNU Emacs 23.1.50.4 (i586-pc-linux-gnu, GTK+ Version 2.16.4)
 of 2009-07-24 on blah.blah
configured using `configure  'CFLAGS=-O -g' '--prefix=/down/emacs/b/inst' '--with-x-toolkit=gtk''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_AU
  value of $XMODIFIERS: nil
  locale-coding-system: iso-latin-1-unix
  default-enable-multibyte-characters: t

Message #10 received at 3965 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Kevin Ryde <user42 <at> zip.com.au>
Cc: 3965 <at> debbugs.gnu.org
Subject: Re: 23.1.50; compilation-mode gnu error regexp mismatching ant, irix, gcc-include
Date: Sun, 02 Aug 2009 18:46:59 -0400

> Doing
>
>     (setq compilation-error-regexp-alist '(gnu))
>
> and visiting etc/compilation.txt shows some mismatched parts.
>
> Under "ant" ...
> Under "irix"...
> And under "gcc-include"...
>
> With all patterns enabled `next-error' offers those wrong matches
> instead of what the specific patterns for those parts get -- I suppose
> because the gnu match is earlier in the line.

Correct.  That's the intended behavior.

> My best idea for the irix ones would be to disallow ": " in the gnu
> pattern filename part.  Other colons could be allowed for dos drive
> letters or the occasional filename with a colon, but rate colon+space as
> more likely to be a separator than a part of a name.  Mind you the gnu
> pattern is already far too complicated for me to want to do anything to
> it :-)

There's no point changing the gnu pattern just to handle these
additional patterns, which already have their own dedicated entries in
compilation-error-regexp-alist.

Message #19 received at 3965 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Kevin Ryde <user42 <at> zip.com.au>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 3965 <at> debbugs.gnu.org
Subject: Re: 23.1.50; compilation-mode gnu error regexp mismatching ant, irix, gcc-include
Date: Tue, 04 Aug 2009 11:52:05 +1000

Chong Yidong <cyd <at> stupidchicken.com> writes:
>
> There's no point changing the gnu pattern just to handle these
> additional patterns, which already have their own dedicated entries in
> compilation-error-regexp-alist.

Can't you have gcc-include and gnu at the same time?

I see in fact that mismatch is a regression.  In emacs 22 the gnu
pattern successfully keeps out of gcc-include's hair.

(If it is the "omake" hack then that bit may have a bit to answer for --
stopping the perl pattern working, making the gnu pattern work too much
... :-)

Message #24 received at 3965 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Kevin Ryde <user42 <at> zip.com.au>
To: control <at> debbugs.gnu.org
Cc: 3965 <at> debbugs.gnu.org
Subject: Re: bug#3965 acknowledged by developer (close 3965)
Date: Thu, 06 Aug 2009 08:57:57 +1000

reopen 3965
thanks

When working with gcc it will be usual to have both gnu and gcc-include
patterns active.  The way the gnu pattern mismatches the gcc-include
prevents following to the origin of an include error.

Previous Next

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