GNU bug report logs - #70794
30.0.50; Add Rust compilation regex

Previous Next

To reply to this bug, email your comments to 70794 AT debbugs.gnu.org.
There is no need to reopen the bug first.

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

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ergus <spacibba <at> aol.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; Add Rust compilation regex
Date: Mon, 06 May 2024 03:28:43 +0200

Hi:

Recently working with rust I have noticed that emacs does not recognizes
the rust/cargo error patterns.

Considering that emacs has now the rust-ts-mode, it may worth adding
the rust/cargo error patterns to compile when using that mode

In my system so far I have this:

```
(with-eval-after-load 'rust-ts-mode
  (with-eval-after-load 'compile
    (add-to-list
     'compilation-error-regexp-alist-alist
     `(cargo
       "\\(?:\\(?4:error\\)\\|\\(?5:warning\\)\\):[^\0]+?--> \\(?1:[^:]+\\):\\(?2:[[:digit:]]+\\):\\(?3:[[:digit:]]+\\)"
       1 2 3 (5)
       nil
       (5 compilation-warning-face)
       (4 compilation-error-face)))

    (add-to-list 'compilation-error-regexp-alist 'cargo)))

```

Maybe a more frequent rust user has a more general regex to
recommend. But this one works for me.

WDYT?

Message #8 received at 70794 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ergus <spacibba <at> aol.com>
Cc: 70794 <at> debbugs.gnu.org
Subject: Re: bug#70794: 30.0.50; Add Rust compilation regex
Date: Sat, 11 May 2024 11:51:04 +0300

> Date: Mon, 06 May 2024 03:28:43 +0200
> From:  Ergus via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> Recently working with rust I have noticed that emacs does not recognizes
> the rust/cargo error patterns.
> 
> Considering that emacs has now the rust-ts-mode, it may worth adding
> the rust/cargo error patterns to compile when using that mode
> 
> In my system so far I have this:
> 
> ```
> (with-eval-after-load 'rust-ts-mode
>   (with-eval-after-load 'compile
>     (add-to-list
>      'compilation-error-regexp-alist-alist
>      `(cargo
>        "\\(?:\\(?4:error\\)\\|\\(?5:warning\\)\\):[^\0]+?--> \\(?1:[^:]+\\):\\(?2:[[:digit:]]+\\):\\(?3:[[:digit:]]+\\)"
>        1 2 3 (5)
>        nil
>        (5 compilation-warning-face)
>        (4 compilation-error-face)))
> 
>     (add-to-list 'compilation-error-regexp-alist 'cargo)))
> 
> ```
> 
> Maybe a more frequent rust user has a more general regex to
> recommend. But this one works for me.
> 
> WDYT?

Thanks, but could you please also send the examples of Rust messages,
because we need to add them to etc/compilation.txt?

Message #11 received at 70794 <at> debbugs.gnu.org (full text, mbox):

From: Ergus <spacibba <at> aol.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 70794 <at> debbugs.gnu.org
Subject: Re: bug#70794: 30.0.50; Add Rust compilation regex
Date: Wed, 15 May 2024 15:10:02 +0200

On Sat, May 11, 2024 at 11:51:04AM GMT, Eli Zaretskii wrote:
>> Date: Mon, 06 May 2024 03:28:43 +0200
>> From:  Ergus via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>>
>> Recently working with rust I have noticed that emacs does not recognizes
>> the rust/cargo error patterns.
>>
>> Considering that emacs has now the rust-ts-mode, it may worth adding
>> the rust/cargo error patterns to compile when using that mode
>>
>> In my system so far I have this:
>>
>> ```
>> (with-eval-after-load 'rust-ts-mode
>>   (with-eval-after-load 'compile
>>     (add-to-list
>>      'compilation-error-regexp-alist-alist
>>      `(cargo
>>        "\\(?:\\(?4:error\\)\\|\\(?5:warning\\)\\):[^\0]+?--> \\(?1:[^:]+\\):\\(?2:[[:digit:]]+\\):\\(?3:[[:digit:]]+\\)"
>>        1 2 3 (5)
>>        nil
>>        (5 compilation-warning-face)
>>        (4 compilation-error-face)))
>>
>>     (add-to-list 'compilation-error-regexp-alist 'cargo)))
>>
>> ```
>>
>> Maybe a more frequent rust user has a more general regex to
>> recommend. But this one works for me.
>>
>> WDYT?
>
>Thanks, but could you please also send the examples of Rust messages,
>because we need to add them to etc/compilation.txt?

Hi Eli:

Typically they look like this:

```
error[E0425]: cannot find function `ruun` in module `broot::cli`
  --> src/main.rs:6:23
   |
6  |     match broot::cli::ruun() {
   |                       ^^^^ help: a function with a similar name exists: `run`
   |
  ::: /tmp/broot/src/cli/mod.rs:49:1
   |
49 | pub fn run() -> Result<Option<Launchable>, ProgramError> {
   | -------------------------------------------------------- similarly
   named function `run` defined here
```

or

```
error: cannot find macro `deebug` in this scope
   --> src/main.rs:5:5
    |
5   |     deebug!("env::args(): {:#?}", std::env::args().collect::<Vec<String>>());
    |     ^^^^^^ help: a macro with a similar name exists: `debug`
    |
   ::: /home/ergo/.cargo/registry/src/index.crates.io-6f17d22bba15001f/log-0.4.21/src/macros.rs:154:1
    |
154 | macro_rules! debug {
    | ------------------ similarly named macro `debug` defined here
```

```
warning: crate-level attribute should be an inner attribute: add an exclamation mark: `#![foo]`
 --> src/main.rs:3:1
  |
3 | #[feature(proc_macro_diagnostic)]
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(unused_attributes)]` on by default
```

Two details:

1. As you can see the [] is optional
2. The path is always relative to project's root

Message #16 received at 70794-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ergus <spacibba <at> aol.com>
Cc: 70794-done <at> debbugs.gnu.org
Subject: Re: bug#70794: 30.0.50; Add Rust compilation regex
Date: Sat, 18 May 2024 13:52:29 +0300

> Date: Wed, 15 May 2024 15:10:02 +0200
> From: Ergus <spacibba <at> aol.com>
> Cc: 70794 <at> debbugs.gnu.org
> 
> On Sat, May 11, 2024 at 11:51:04AM GMT, Eli Zaretskii wrote:
> >
> >Thanks, but could you please also send the examples of Rust messages,
> >because we need to add them to etc/compilation.txt?
> 
> Hi Eli:
> 
> Typically they look like this:
> 
> ```
> error[E0425]: cannot find function `ruun` in module `broot::cli`
>    --> src/main.rs:6:23
>     |
> 6  |     match broot::cli::ruun() {
>     |                       ^^^^ help: a function with a similar name exists: `run`
>     |
>    ::: /tmp/broot/src/cli/mod.rs:49:1
>     |
> 49 | pub fn run() -> Result<Option<Launchable>, ProgramError> {
>     | -------------------------------------------------------- similarly
>     named function `run` defined here
> ```
> 
> or
> 
> ```
> error: cannot find macro `deebug` in this scope
>     --> src/main.rs:5:5
>      |
> 5   |     deebug!("env::args(): {:#?}", std::env::args().collect::<Vec<String>>());
>      |     ^^^^^^ help: a macro with a similar name exists: `debug`
>      |
>     ::: /home/ergo/.cargo/registry/src/index.crates.io-6f17d22bba15001f/log-0.4.21/src/macros.rs:154:1
>      |
> 154 | macro_rules! debug {
>      | ------------------ similarly named macro `debug` defined here
> ```
> 
> ```
> warning: crate-level attribute should be an inner attribute: add an exclamation mark: `#![foo]`
>   --> src/main.rs:3:1
>    |
> 3 | #[feature(proc_macro_diagnostic)]
>    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    |
>    = note: `#[warn(unused_attributes)]` on by default
> ```
> 
> Two details:
> 
> 1. As you can see the [] is optional
> 2. The path is always relative to project's root

Thanks, installed on master, and closing the bug.

Message #19 received at 70794 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Ergus <spacibba <at> aol.com>
Cc: 70794 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: bug#70794: 30.0.50; Add Rust compilation regex
Date: Fri, 31 May 2024 19:15:52 +0200

Ergus, thank you for your contribution! Some questions, if you don't mind:

* There aren't any tests. If you care anything at all about your pattern working, and keep working, you should add some.

We'll help you out, of course, but it's probably best if you give it a go yourself first so that we know exactly what you want to match. Take a look at compile-tests.el, `compile-tests--test-regexps-data`. You will also need to increase the expected counts at the end of `compile-test-error-regexps`.

* The regexp doesn't match the variant with error code inside square brackets, the

error[E0425]: cannot find function `ruun` in module `broot::cli`

kind of message. Surely you intended it to?

Here is your regexp again, translated to rx and with line numbers for ease of discussion:

1 (rx (| (group-n 4 "error") (group-n 5 "warning"))
2     ":"
3     (+? (not (in "\x00")))
4     "--> "
5     (group-n 1 (+ (not (in ":"))))
6     ":"
7     (group-n 2 (+ digit))
8     ":"
9     (group-n 3 (+ digit)))

* (Line 1): From the examples it appears that the messages start at the beginning of a line. We very much prefer to anchor matches for reasons of performance and to avoid collisions with other patterns. How about we add a line-start anchor at the very beginning?

* (Line 3): This is an open-ended expression which will merrily match just about anything including newlines. This can become very expensive. And where does that NUL come from?

In the examples you supplied, the message is on the first line, and the " --> " on the start of the second. Can we rely on that? If not, what can we rely on?

* (Line 5): This excludes Windows file names which can include colon or do cargo messages have a special notation for those? In any case, it's usually a good idea to exclude newline as well to prevent a runaway repetition.

* Both the rust-mode and rustic packages appear to include regexps that match the same messages. How do they compare to yours?

What is the effect of someone using those modes with your regexp in Emacs?

Message #22 received at 70794 <at> debbugs.gnu.org (full text, mbox):

From: Ergus <spacibba <at> aol.com>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: 70794 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#70794: 30.0.50; Add Rust compilation regex
Date: Mon, 3 Jun 2024 16:41:42 +0200

Hi Mattias:

Thanks for your interest on this. As I said in my first message I just
proposed what I have locally, but I didn't intent to insert the regex
there as it was.

On Fri, May 31, 2024 at 07:15:52PM GMT, Mattias Engdeg�rd wrote:
>Ergus, thank you for your contribution! Some questions, if you don't mind:
>
>* There aren't any tests. If you care anything at all about your pattern working, and keep working, you should add some.
>
>We'll help you out, of course, but it's probably best if you give it a go yourself first so that we know exactly what you want to match. Take a look at compile-tests.el, `compile-tests--test-regexps-data`. You will also need to increase the expected counts at the end of `compile-test-error-regexps`.
>
Actually Eli added this commit with the poor information I provided in
my mails because I don't have time to do it myself these days. Sorry for
not being more specific. I actually expected someone else more "rusty" to
provide more complete information (I actually does not use rust with
emacs very often)

>* The regexp doesn't match the variant with error code inside square brackets, the
>
>error[E0425]: cannot find function `ruun` in module `broot::cli`
>
>kind of message. Surely you intended it to?
>
You are right, Checking my local version I have a \\(\\[.+\\]\\)? before
the : in my pattern, not sure when I added that since my first mail.

>Here is your regexp again, translated to rx and with line numbers for
>ease of discussion:
I don't really understand the rx notatio :/ but I will try

>
>1 (rx (| (group-n 4 "error") (group-n 5 "warning"))
>2     ":"
>3     (+? (not (in "\x00")))
>4     "--> "
>5     (group-n 1 (+ (not (in ":"))))
>6     ":"
>7     (group-n 2 (+ digit))
>8     ":"
>9     (group-n 3 (+ digit)))
>

>* (Line 1): From the examples it appears that the messages start at the
>beginning of a line. We very much prefer to anchor matches for reasons
>of performance and to avoid collisions with other patterns. How about
>we add a line-start anchor at the very beginning?
>
It is ok. Probaly you may want to add also a line-end

>* (Line 3): This is an open-ended expression which will merrily match
>just about anything including newlines. This can become very
>expensive. And where does that NUL come from?
>
The NUL is actually negated to match anything up to the -->

>In the examples you supplied, the message is on the first line, and the " --> " on the start of the second. Can we rely on that? If not, what can we rely on?
>
I think yes; that's at least what I tried to match. If you have a
better/more efficient alternative fell free to change it.

>* (Line 5): This excludes Windows file names which can include colon or do cargo messages have a special notation for those? In any case, it's usually a good idea to exclude newline as well to prevent a runaway repetition.
>
In this case I think not, because the filename is always relative in
cargo and on MSWindows the colon comes after the drive in absolute paths
right? But I could be wrong.

>* Both the rust-mode and rustic packages appear to include regexps that match the same messages. How do they compare to yours?
>
You can take those indeed. I think they must be pretty much equivalent
and probably more complete because they probably match the "note:" case
which I preferred to ignore as emacs does not have an equivalent for
that.

IIRC they just don't use numeric capture groups, which I like a bit more
t avoid weird errors, but at the end the regex is pretty simple, any
alternative is fine.

>What is the effect of someone using those modes with your regexp in Emacs?
>
>
IIUC the packages pushes the entries in front of
compilation-error-regexp-alist-alist, so in principle their regexp will
match first and the loop stops.

So, the main changes you propose are something like:

"^\\(?:\\(?4:error\\)\\|\\(?5:warning\\)\\)\\(?:\\[.+\\]\\)?:[^\0]+?--> \\(?1:[^:]+\\):\\(?2:[[:digit:]]+\\):\\(?3:[[:digit:]]+\\)"

Message #25 received at 70794 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Ergus <spacibba <at> aol.com>
Cc: 70794 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#70794: 30.0.50; Add Rust compilation regex
Date: Mon, 3 Jun 2024 16:54:02 +0200

There is also already a regexp that looks like it is used to match similar messages in `rust-ts-flymake`, but it lacks some of the problems listed above. Maybe they could be consolidated?

There is another problem with the added `cargo` regexp: its placement early in `compilation-error-regexp-alist-alist` causes it to match before other, possibly more frequently occurring patterns.
(That is not your (or Eli's) fault but an undocumented subtlety of that variable; I'll add a remark to the code.)

In fact the added pattern has visibly wrecked the display of etc/compilation.txt so I'm taking the slightly drastic step of reverting it. It seems we'll need to work harder on this one -- sorry.

Message #28 received at 70794 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: 70794 <at> debbugs.gnu.org, spacibba <at> aol.com
Subject: Re: bug#70794: 30.0.50; Add Rust compilation regex
Date: Mon, 03 Jun 2024 18:28:38 +0300

> From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
> Date: Mon, 3 Jun 2024 16:54:02 +0200
> Cc: Eli Zaretskii <eliz <at> gnu.org>,
>  70794 <at> debbugs.gnu.org
> 
> There is another problem with the added `cargo` regexp: its placement early in `compilation-error-regexp-alist-alist` causes it to match before other, possibly more frequently occurring patterns.
> (That is not your (or Eli's) fault but an undocumented subtlety of that variable; I'll add a remark to the code.)

The order of the patterns in the alist is a complete mystery to me.  I
tried to figure it out, but eventually gave up.  A remark won't cut
it, I think: we need a detailed description of the principles,
considerations, and the way of testing the results after adding a new
pattern.

> In fact the added pattern has visibly wrecked the display of etc/compilation.txt so I'm taking the slightly drastic step of reverting it.

That succeeded in my testing, so I wonder why it doesn't work for you.

Message #31 received at 70794 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: 70794 <at> debbugs.gnu.org, spacibba <at> aol.com
Subject: Re: bug#70794: 30.0.50; Add Rust compilation regex
Date: Mon, 03 Jun 2024 18:30:24 +0300

> From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
> Date: Mon, 3 Jun 2024 16:54:02 +0200
> Cc: Eli Zaretskii <eliz <at> gnu.org>,
>  70794 <at> debbugs.gnu.org
> 
> In fact the added pattern has visibly wrecked the display of etc/compilation.txt so I'm taking the slightly drastic step of reverting it. It seems we'll need to work harder on this one -- sorry.

If you revert it, please fix this ASAP and install the results, since
I'd like to have this on the emacs-20 branch, which will be cut
soon-ish.

Thanks.

Message #34 received at 70794 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Ergus <spacibba <at> aol.com>
Cc: 70794 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#70794: 30.0.50; Add Rust compilation regex
Date: Mon, 3 Jun 2024 17:35:35 +0200

3 juni 2024 kl. 16.41 skrev Ergus <spacibba <at> aol.com>:

> I actually expected someone else more "rusty" to
> provide more complete information (I actually does not use rust with
> emacs very often)

Then maybe we should wait for someone with more Rust expertise to help out?
Without anyone actually using the stuff we risk making something that may not be useful or that is already unmaintained from the start with isn't a very good plan.
Or (as in this case) actually having a negative effect on the other patterns.

I really prefer we only add something when we know what we are doing.

Message #37 received at 70794 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: 70794 <at> debbugs.gnu.org, spacibba <at> aol.com
Subject: Re: bug#70794: 30.0.50; Add Rust compilation regex
Date: Mon, 03 Jun 2024 19:33:19 +0300

> From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
> Date: Mon, 3 Jun 2024 18:22:48 +0200
> Cc: spacibba <at> aol.com,
>  70794 <at> debbugs.gnu.org
> 
> > If you revert it, please fix this ASAP and install the results, since
> > I'd like to have this on the emacs-20 branch, which will be cut
> > soon-ish.
> 
> Personally I strongly prefer no rule to a broken one, or even to Mattias's-best-guess-of-what-a-correct-rule-might-look-like.

Fine by me (I don't use Rust), but is the rule really broken?  What
happens if you move it to the end?

Message #40 received at 70794 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 70794 <at> debbugs.gnu.org, spacibba <at> aol.com
Subject: Re: bug#70794: 30.0.50; Add Rust compilation regex
Date: Mon, 3 Jun 2024 18:22:48 +0200

3 juni 2024 kl. 17.28 skrev Eli Zaretskii <eliz <at> gnu.org>:

> The order of the patterns in the alist is a complete mystery to me.  I
> tried to figure it out, but eventually gave up.  A remark won't cut
> it, I think: we need a detailed description of the principles,
> considerations, and the way of testing the results after adding a new
> pattern.

Yes, it's really not ideal. There are lots of legacy entries which are hardly ever used and just shouldn't be there, or at least not enabled by default. And as you say, the order is chaotic, difficult to understand, and probably not the best.

There is also insufficient testing of cross-pattern interference which isn't easy or cheap to do if we are serious about it.

The customisation interface is also not helping very much, and the whole mechanism is not very modular.

>> In fact the added pattern has visibly wrecked the display of etc/compilation.txt so I'm taking the slightly drastic step of reverting it.
> 
> That succeeded in my testing, so I wonder why it doesn't work for you.

My guess it is because of the nondeterministic parsing by compilation-mode; it seems to depend on the order of fontification, and possibly user settings (faces maybe). I can reproduce it reliably here, though.

Anyway, the syndrome was just a consequence of the previous observations about the (far too unrestrained) regexp, so there is no real mystery.

> If you revert it, please fix this ASAP and install the results, since
> I'd like to have this on the emacs-20 branch, which will be cut
> soon-ish.

Personally I strongly prefer no rule to a broken one, or even to Mattias's-best-guess-of-what-a-correct-rule-might-look-like.

Message #43 received at 70794 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 70794 <at> debbugs.gnu.org, spacibba <at> aol.com
Subject: Re: bug#70794: 30.0.50; Add Rust compilation regex
Date: Mon, 3 Jun 2024 18:59:20 +0200

3 juni 2024 kl. 18.33 skrev Eli Zaretskii <eliz <at> gnu.org>:

> Fine by me (I don't use Rust), but is the rule really broken?  What
> happens if you move it to the end?

It is indeed broken as written because it would match anything starting with 'warning:' to something that looks like an arrow further down the log which could be an unrelated message a megabyte away.

I could try to slap together a guess at what a better one would be but then again, I wouldn't use it myself (rarely use Rust and when I do it's one of those external packages which have their own patterns and more importantly active maintainers). Furthermore I don't have the time to go poking around in the rustc (or cargo?) source code to see what the message-emitting parts look like, which is very useful when adding patterns.

Even with the obvious fixes, the pattern would still be incomplete and not even match parts of the examples given. I'm happy to work with Rust users or package maintainers to work out details but I don't want to do a rush job now, nor delay Emacs 30.

Message #46 received at 70794 <at> debbugs.gnu.org (full text, mbox):

From: Ergus <spacibba <at> aol.com>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: 70794 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#70794: 30.0.50; Add Rust compilation regex
Date: Tue, 4 Jun 2024 00:36:17 +0200

On Mon, Jun 03, 2024 at 06:22:48PM GMT, Mattias Engdeg�rd wrote:
>3 juni 2024 kl. 17.28 skrev Eli Zaretskii <eliz <at> gnu.org>:
>
>> The order of the patterns in the alist is a complete mystery to me.  I
>> tried to figure it out, but eventually gave up.  A remark won't cut
>> it, I think: we need a detailed description of the principles,
>> considerations, and the way of testing the results after adding a new
>> pattern.
>
>Yes, it's really not ideal. There are lots of legacy entries which are
>hardly ever used and just shouldn't be there, or at least not enabled
>by default. And as you say, the order is chaotic, difficult to
>understand, and probably not the best.
>
About this, I may say that IMO the best approach is to use lazy insertion
with-eval-after-load.

For example, as I mentioned when I opened the issue: I have this in my
init file:

```
(with-eval-after-load 'rust-ts-mode
  (with-eval-after-load 'compile
    (add-to-list
     'compilation-error-regexp-alist-alist
     `(cargo
       "^\\(?:\\(?4:error\\)\\|\\(?5:warning\\)\\)\\(?:\\[.+\\]\\)?:[^\0]+?--> \\(?1:[^:]+\\):\\(?2:[[:digit:]]+\\):\\(?3:[[:digit:]]+\\)"
       1 2 3 (5)
       nil
       (5 compilation-warning-face)
       (4 compilation-error-face)))

    (add-to-list 'compilation-error-regexp-alist 'cargo)))

```

I use something similar for other build tools (like msbuild or
incredibuild) in order to avoid performance impact.

I also apply some tricks to reduce the compilation-error-regexp-alist
when I know that only one pattern may apply in my cases. It may be
amazing if we could simplify such customizations/optimizations somehow...

>There is also insufficient testing of cross-pattern interference which
>isn't easy or cheap to do if we are serious about it.
>
>The customisation interface is also not helping very much, and the
>whole mechanism is not very modular.
>
>>> In fact the added pattern has visibly wrecked the display of etc/compilation.txt so I'm taking the slightly drastic step of reverting it.
>>
>> That succeeded in my testing, so I wonder why it doesn't work for you.
>
>My guess it is because of the nondeterministic parsing by
>compilation-mode; it seems to depend on the order of fontification, and
>possibly user settings (faces maybe). I can reproduce it reliably here,
>though.
>
>Anyway, the syndrome was just a consequence of the previous
>observations about the (far too unrestrained) regexp, so there is no
>real mystery.
>
>> If you revert it, please fix this ASAP and install the results, since
>> I'd like to have this on the emacs-20 branch, which will be cut
>> soon-ish.
>
>Personally I strongly prefer no rule to a broken one, or even to
>Mattias's-best-guess-of-what-a-correct-rule-might-look-like.
>

Message #49 received at 70794 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ergus <spacibba <at> aol.com>
Cc: 70794 <at> debbugs.gnu.org, mattias.engdegard <at> gmail.com
Subject: Re: bug#70794: 30.0.50; Add Rust compilation regex
Date: Tue, 04 Jun 2024 17:33:19 +0300

> Date: Tue, 4 Jun 2024 00:36:17 +0200
> From: Ergus <spacibba <at> aol.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 70794 <at> debbugs.gnu.org
> 
> On Mon, Jun 03, 2024 at 06:22:48PM GMT, Mattias Engdeg�rd wrote:
> >3 juni 2024 kl. 17.28 skrev Eli Zaretskii <eliz <at> gnu.org>:
> >
> >> The order of the patterns in the alist is a complete mystery to me.  I
> >> tried to figure it out, but eventually gave up.  A remark won't cut
> >> it, I think: we need a detailed description of the principles,
> >> considerations, and the way of testing the results after adding a new
> >> pattern.
> >
> >Yes, it's really not ideal. There are lots of legacy entries which are
> >hardly ever used and just shouldn't be there, or at least not enabled
> >by default. And as you say, the order is chaotic, difficult to
> >understand, and probably not the best.
> >
> About this, I may say that IMO the best approach is to use lazy insertion
> with-eval-after-load.

That's orthogonal, and I'm not sure I agree with you.

In any case, it only lowers the probability of clashes, but doesn't
resolve them.  Moreover, it makes the problems harder to reproduce
(because now they will depend on the order of previous commands).

Message #52 received at 70794 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>, 
 Eli Zaretskii <eliz <at> gnu.org>
Cc: 70794 <at> debbugs.gnu.org, spacibba <at> aol.com
Subject: Re: bug#70794: 30.0.50; Add Rust compilation regex
Date: Tue, 4 Jun 2024 18:06:16 -0400

Mattias Engdegård <mattias.engdegard <at> gmail.com> writes:

> Even with the obvious fixes, the pattern would still be incomplete and not even match parts of the examples given. I'm happy to work with Rust users or package maintainers to work out details but I don't want to do a rush job now, nor delay Emacs 30.

BTW, shouldn't stuff like this be happier if it was in something like
`rust-mode`?

It seems like the maintainers of major modes are in a better position to
add and maintain support for the compilers and tools of their respective
languages than we are.

Message #55 received at 70794 <at> debbugs.gnu.org (full text, mbox):

From: Ergus <spacibba <at> aol.com>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 70794 <at> debbugs.gnu.org,
 Mattias Engdegård <mattias.engdegard <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#70794: 30.0.50; Add Rust compilation regex
Date: Thu, 6 Jun 2024 00:56:38 +0200

On Tue, Jun 04, 2024 at 06:06:16PM GMT, Stefan Kangas wrote:
>Mattias Engdeg�rd <mattias.engdegard <at> gmail.com> writes:
>
>> Even with the obvious fixes, the pattern would still be incomplete and not even match parts of the examples given. I'm happy to work with Rust users or package maintainers to work out details but I don't want to do a rush job now, nor delay Emacs 30.
>
>BTW, shouldn't stuff like this be happier if it was in something like
>`rust-mode`?
>
>It seems like the maintainers of major modes are in a better position to
>add and maintain support for the compilers and tools of their respective
>languages than we are.

Hi Stefan:

Actually I opened the initial issue because there is a rust-ts-mode now
in vanilla and in my opinion it is a bit incoherent to have a native
mode to support rust, but don't support compiling rust.

Specially considering that adding such support seems extremely simple,
it only requires to improve the regex to be a bit more strict. And the
one I provided is buggy mainly due to the "too free" wildcard I used to
match anything including the new line...

Just improving the [^\0]+?--> in the regex; I thing everything will work
properly.

Message #58 received at 70794 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>, 
 Eli Zaretskii <eliz <at> gnu.org>
Cc: 70794 <at> debbugs.gnu.org, Randy Taylor <dev <at> rjt.dev>, spacibba <at> aol.com
Subject: Re: bug#70794: 30.0.50; Add Rust compilation regex
Date: Thu, 6 Jun 2024 03:34:42 -0400

Mattias Engdegård <mattias.engdegard <at> gmail.com> writes:

> 3 juni 2024 kl. 18.33 skrev Eli Zaretskii <eliz <at> gnu.org>:
>
>> Fine by me (I don't use Rust), but is the rule really broken?  What
>> happens if you move it to the end?
>
> It is indeed broken as written because it would match anything
> starting with 'warning:' to something that looks like an arrow further
> down the log which could be an unrelated message a megabyte away.
>
> I could try to slap together a guess at what a better one would be but
> then again, I wouldn't use it myself (rarely use Rust and when I do
> it's one of those external packages which have their own patterns and
> more importantly active maintainers). Furthermore I don't have the
> time to go poking around in the rustc (or cargo?) source code to see
> what the message-emitting parts look like, which is very useful when
> adding patterns.
>
> Even with the obvious fixes, the pattern would still be incomplete and
> not even match parts of the examples given. I'm happy to work with
> Rust users or package maintainers to work out details but I don't want
> to do a rush job now, nor delay Emacs 30.

Randy, would you be interested in working with Mattias to create a good
`compilation-mode` regexp for Rust?

Message #65 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Vincenzo Pupillo <v.pupillo <at> gmail.com>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>, bug-gnu-emacs <at> gnu.org
Cc: 70794 <at> debbugs.gnu.org, Randy Taylor <dev <at> rjt.dev>, spacibba <at> aol.com,
 Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#70794: 30.0.50; Add Rust compilation regex
Date: Mon, 28 Apr 2025 22:22:16 +0200

[Message part 1 (text/plain, inline)]

Ciao,
Would the attached patch be good?

Vincenzo

p.s. the tests come from Rust docs.


In data giovedì 6 giugno 2024 09:34:42 Ora legale dell’Europa centrale, Stefan 
Kangas ha scritto:
> Mattias Engdegård <mattias.engdegard <at> gmail.com> writes:
> > 3 juni 2024 kl. 18.33 skrev Eli Zaretskii <eliz <at> gnu.org>:
> >> Fine by me (I don't use Rust), but is the rule really broken?  What
> >> happens if you move it to the end?
> > 
> > It is indeed broken as written because it would match anything
> > starting with 'warning:' to something that looks like an arrow further
> > down the log which could be an unrelated message a megabyte away.
> > 
> > I could try to slap together a guess at what a better one would be but
> > then again, I wouldn't use it myself (rarely use Rust and when I do
> > it's one of those external packages which have their own patterns and
> > more importantly active maintainers). Furthermore I don't have the
> > time to go poking around in the rustc (or cargo?) source code to see
> > what the message-emitting parts look like, which is very useful when
> > adding patterns.
> > 
> > Even with the obvious fixes, the pattern would still be incomplete and
> > not even match parts of the examples given. I'm happy to work with
> > Rust users or package maintainers to work out details but I don't want
> > to do a rush job now, nor delay Emacs 30.
> 
> Randy, would you be interested in working with Mattias to create a good
> `compilation-mode` regexp for Rust?

[0001-Support-Rust-compiler-error-and-warning-messages-in-.patch (text/x-patch, attachment)]

Message #73 received at 70794 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: mattias.engdegard <at> gmail.com, dev <at> rjt.dev
Cc: 70794 <at> debbugs.gnu.org, spacibba <at> aol.com,
 Vincenzo Pupillo <v.pupillo <at> gmail.com>, stefankangas <at> gmail.com
Subject: Re: bug#70794: 30.0.50; Add Rust compilation regex
Date: Sat, 10 May 2025 12:53:50 +0300

Ping!  Randy and Mattias, would you please respond?

> From: Vincenzo Pupillo <v.pupillo <at> gmail.com>
> Cc: 70794 <at> debbugs.gnu.org, Randy Taylor <dev <at> rjt.dev>, spacibba <at> aol.com,
>  Stefan Kangas <stefankangas <at> gmail.com>
> Date: Mon, 28 Apr 2025 22:22:16 +0200
> 
> Ciao,
> Would the attached patch be good?
> 
> Vincenzo
> 
> p.s. the tests come from Rust docs.
> 
> 
> In data giovedì 6 giugno 2024 09:34:42 Ora legale dell’Europa centrale, Stefan 
> Kangas ha scritto:
> > Mattias Engdegård <mattias.engdegard <at> gmail.com> writes:
> > > 3 juni 2024 kl. 18.33 skrev Eli Zaretskii <eliz <at> gnu.org>:
> > >> Fine by me (I don't use Rust), but is the rule really broken?  What
> > >> happens if you move it to the end?
> > > 
> > > It is indeed broken as written because it would match anything
> > > starting with 'warning:' to something that looks like an arrow further
> > > down the log which could be an unrelated message a megabyte away.
> > > 
> > > I could try to slap together a guess at what a better one would be but
> > > then again, I wouldn't use it myself (rarely use Rust and when I do
> > > it's one of those external packages which have their own patterns and
> > > more importantly active maintainers). Furthermore I don't have the
> > > time to go poking around in the rustc (or cargo?) source code to see
> > > what the message-emitting parts look like, which is very useful when
> > > adding patterns.
> > > 
> > > Even with the obvious fixes, the pattern would still be incomplete and
> > > not even match parts of the examples given. I'm happy to work with
> > > Rust users or package maintainers to work out details but I don't want
> > > to do a rush job now, nor delay Emacs 30.
> > 
> > Randy, would you be interested in working with Mattias to create a good
> > `compilation-mode` regexp for Rust?

Message #76 received at 70794 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Vincenzo Pupillo <v.pupillo <at> gmail.com>
Cc: Randy Taylor <dev <at> rjt.dev>, spacibba <at> aol.com, bug-gnu-emacs <at> gnu.org,
 Stefan Kangas <stefankangas <at> gmail.com>, 70794 <at> debbugs.gnu.org,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#70794: 30.0.50; Add Rust compilation regex
Date: Thu, 15 May 2025 20:42:42 +0200

28 apr. 2025 kl. 22.22 skrev Vincenzo Pupillo <v.pupillo <at> gmail.com>:

> diff --git a/lisp/progmodes/compile.el b/lisp/progmodes/compile.el
> index 1ca58b3ac7d..7a1b5d4fdd1 100644
> --- a/lisp/progmodes/compile.el
> +++ b/lisp/progmodes/compile.el
> @@ -565,6 +565,13 @@ compilation-error-regexp-alist-alist
>       "\\(?:Parse\\|Fatal\\) error: \\(.*\\) in \\(.*\\) on line \\([0-9]+\\)"
>       2 3 nil nil)
>  
> +    (rustc-error

Can't you combine the error and warning patterns into a single rule? It's what we normally try to do, and it doesn't make much sense having one without the other. The rust-mode code seems to indicate that there are info-level messages (using 'note:') so let's include those as well.

> +     "^error[^:]*:[^\n]*\n\s+-->\s\\([^\n]+\\):\\([0-9]+\\):\\([0-9]+\\)"

"[^\n]" is usually written as "." (in rx it's `not-newline` or `nonl`).

As mentioned before, the "[^:]*" matches way too much.

It seems that the number of spaces before the arrow is hard-coded to 2 in the output.

The "[^\n]+" for matching the file name will match all the way to the end, then backtrack several times to the first colon. But maybe you wrote it that way for Windows file names containing a drive letter? In that case we have little choice.

What about the following then:

 (rx bol (or "error" (group-n 1 "warning") (group-n 2 "note"))
     (? "[" (+ (in "A-Z" "0-9")) "]") ":" (* nonl)
     "\n  --> " (group-n 3 (+ nonl))   ; file
     ":" (group-n 4 (+ (in "0-9")))    ; line
     ":" (group-n 5 (+ (in "0-9"))))   ; column

If you like this, then please also include an example for 'note' messages, and add one to the tests.

Message #82 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Vincenzo Pupillo <v.pupillo <at> gmail.com>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: Randy Taylor <dev <at> rjt.dev>, spacibba <at> aol.com, bug-gnu-emacs <at> gnu.org,
 Stefan Kangas <stefankangas <at> gmail.com>, 70794 <at> debbugs.gnu.org,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#70794: 30.0.50; Add Rust compilation regex
Date: Sat, 17 May 2025 22:37:37 +0200

Ciao Mattias,

In data giovedì 15 maggio 2025 20:42:42 Ora legale dell’Europa centrale, 
Mattias Engdegård ha scritto:
> 28 apr. 2025 kl. 22.22 skrev Vincenzo Pupillo <v.pupillo <at> gmail.com>:
> > diff --git a/lisp/progmodes/compile.el b/lisp/progmodes/compile.el
> > index 1ca58b3ac7d..7a1b5d4fdd1 100644
> > --- a/lisp/progmodes/compile.el
> > +++ b/lisp/progmodes/compile.el
> > @@ -565,6 +565,13 @@ compilation-error-regexp-alist-alist
> > 
> >       "\\(?:Parse\\|Fatal\\) error: \\(.*\\) in \\(.*\\) on line
> >       \\([0-9]+\\)"
> >       2 3 nil nil)
> > 
> > +    (rustc-error
> 
> Can't you combine the error and warning patterns into a single rule? It's
> what we normally try to do, and it doesn't make much sense having one
> without the other. The rust-mode code seems to indicate that there are
> info-level messages (using 'note:') so let's include those as well.
> > +     "^error[^:]*:[^\n]*\n\s+-->\s\\([^\n]+\\):\\([0-9]+\\):\\([0-9]+\\)"
> 
> "[^\n]" is usually written as "." (in rx it's `not-newline` or `nonl`).
> 
> As mentioned before, the "[^:]*" matches way too much.
> 
> It seems that the number of spaces before the arrow is hard-coded to 2 in
> the output.
No, the spaces before the arrow vary according to the line number of the 
error. The arrow is aligned with the vertical bar separating the line number 
from the error description.
This is an example (rustc version 1.86):

--8<---------------cut here---------------start------------->8---
warning: unknown lint: `multiple_supertrait_upcastable`
    --> test.rs:1024:9
     |
1024 | #[allow(multiple_supertrait_upcastable)]
     |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     |
     = note: the `multiple_supertrait_upcastable` lint is unstable
     = note: `#[warn(unknown_lints)]` on by default

error[E0152]: found duplicate lang item `sized`
   --> test.rs:148:1
    |
148 | / pub trait Sized {
149 | |     // Empty.
150 | | }
    | |_^
    |
    = note: the lang item is first defined in crate `core` (which `std` 
depends on)
    = note: first definition in `core` loaded from /usr/lib/rustlib/x86_64-
unknown-linux-gnu/lib/libcore-1efaafb24524a678.rlib
    = note: second definition in the local crate (`test`)
--8<---------------cut here---------------end--------------->8---

> 
> The "[^\n]+" for matching the file name will match all the way to the end,
> then backtrack several times to the first colon. But maybe you wrote it
> that way for Windows file names containing a drive letter? In that case we
> have little choice.
> 
> What about the following then:
> 
>  (rx bol (or "error" (group-n 1 "warning") (group-n 2 "note"))
>      (? "[" (+ (in "A-Z" "0-9")) "]") ":" (* nonl)
>      "\n  --> " (group-n 3 (+ nonl))   ; file
>      ":" (group-n 4 (+ (in "0-9")))    ; line
>      ":" (group-n 5 (+ (in "0-9"))))   ; column
> 

Thank you!
I made a small change taking into account what I read in the source code of 
the rust compiler. The number of spaces before the arrow should be between 1 
and 6, so I made a small change:

(rx bol (or "error" (group-n 1 "warning") (group-n 2 "note"))
          (? "[" (+ (in "A-Z" "0-9")) "]") ":" (* nonl)
          "\n" (repeat 1 6 " ") "-->"
          " " (group-n 3 (+ nonl))        ; file
          ":" (group-n 4 (+ (in "0-9")))  ; line
          ":" (group-n 5 (+ (in "0-9"))))

WDYT?

> If you like this, then please also include an example for 'note' messages,
> and add one to the tests.

Ok.

Thanks.

Vincenzo

Message #88 received at 70794 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Vincenzo Pupillo <v.pupillo <at> gmail.com>
Cc: 70794 <at> debbugs.gnu.org, Randy Taylor <dev <at> rjt.dev>,
 Eli Zaretskii <eliz <at> gnu.org>, Ergus <spacibba <at> aol.com>,
 Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#70794: 30.0.50; Add Rust compilation regex
Date: Sun, 18 May 2025 13:09:16 +0200

17 maj 2025 kl. 22.37 skrev Vincenzo Pupillo <v.pupillo <at> gmail.com>:

> No, the spaces before the arrow vary according to the line number of the 
> error. The arrow is aligned with the vertical bar separating the line number 
> from the error description.

Thank you for finding that out. Then I think (repeat 1 6 " ") more complicated than it's worth; just (+ " ") will do (and is actually faster).

Message #91 received at 70794 <at> debbugs.gnu.org (full text, mbox):

From: Vincenzo Pupillo <v.pupillo <at> gmail.com>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: 70794 <at> debbugs.gnu.org, Randy Taylor <dev <at> rjt.dev>,
 Eli Zaretskii <eliz <at> gnu.org>, Ergus <spacibba <at> aol.com>,
 Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#70794: 30.0.50; Add Rust compilation regex
Date: Mon, 19 May 2025 22:58:14 +0200

[Message part 1 (text/plain, inline)]

Ciao Mattias,

In data domenica 18 maggio 2025 13:09:16 Ora legale dell’Europa centrale, 
Mattias Engdegård ha scritto:
> 17 maj 2025 kl. 22.37 skrev Vincenzo Pupillo <v.pupillo <at> gmail.com>:
> > No, the spaces before the arrow vary according to the line number of the
> > error. The arrow is aligned with the vertical bar separating the line
> > number from the error description.
> 
> Thank you for finding that out. Then I think (repeat 1 6 " ") more
> complicated than it's worth; just (+ " ") will do (and is actually faster).

Done.
The patch is attached.

Thanks.
Vincenzo

[0001-Support-Rust-compiler-messages-in-compile-mode-bug-7.patch (text/x-patch, attachment)]

Message #96 received at 70794-done <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Vincenzo Pupillo <v.pupillo <at> gmail.com>
Cc: 70794-done <at> debbugs.gnu.org, Randy Taylor <dev <at> rjt.dev>,
 Eli Zaretskii <eliz <at> gnu.org>, Ergus <spacibba <at> aol.com>,
 Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#70794: 30.0.50; Add Rust compilation regex
Date: Thu, 22 May 2025 15:09:58 +0200

Thank you Vincenzo, that looks fine. Pushed to master.

Message #99 received at 70794-done <at> debbugs.gnu.org (full text, mbox):

From: Vincenzo Pupillo <v.pupillo <at> gmail.com>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: 70794-done <at> debbugs.gnu.org, Randy Taylor <dev <at> rjt.dev>,
 Eli Zaretskii <eliz <at> gnu.org>, Ergus <spacibba <at> aol.com>,
 Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#70794: 30.0.50; Add Rust compilation regex
Date: Thu, 22 May 2025 15:55:20 +0200

Thank you too Mattias!

V.

In data giovedì 22 maggio 2025 15:09:58 Ora legale dell’Europa centrale, 
Mattias Engdegård ha scritto:
> Thank you Vincenzo, that looks fine. Pushed to master.

Previous Next

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