bug#70794: 30.0.50; Add Rust compilation regex

[Ergus via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@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@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.
>