all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Ergus via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: "Mattias Engdegård" <mattias.engdegard@gmail.com>
Cc: 70794@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
Subject: bug#70794: 30.0.50; Add Rust compilation regex
Date: Mon, 3 Jun 2024 16:41:42 +0200	[thread overview]
Message-ID: <ra7twcezodyvtrskr6egrfreurphcmprra2ci3nqgncwqmeiql@i5ila5dzhdqx> (raw)
In-Reply-To: <16667D6C-F897-4A85-8C7A-0FA2E803FAA6@gmail.com>

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:]]+\\)"








  reply	other threads:[~2024-06-03 14:41 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <87y18nsp84.fsf.ref@aol.com>
2024-05-06  1:28 ` bug#70794: 30.0.50; Add Rust compilation regex Ergus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-05-11  8:51   ` Eli Zaretskii
2024-05-15 13:10     ` Ergus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-05-18 10:52       ` Eli Zaretskii
2024-05-31 17:15   ` Mattias Engdegård
2024-06-03 14:41     ` Ergus via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2024-06-03 15:35       ` Mattias Engdegård
2024-06-03 14:54     ` Mattias Engdegård
2024-06-03 15:28       ` Eli Zaretskii
2024-06-03 16:22         ` Mattias Engdegård
2024-06-03 16:33           ` Eli Zaretskii
2024-06-03 16:59             ` Mattias Engdegård
2024-06-04 22:06               ` Stefan Kangas
2024-06-05 22:56                 ` Ergus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-06-06  7:34               ` Stefan Kangas
2024-06-03 22:36           ` Ergus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-06-04 14:33             ` Eli Zaretskii
2024-06-03 15:30       ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ra7twcezodyvtrskr6egrfreurphcmprra2ci3nqgncwqmeiql@i5ila5dzhdqx \
    --to=bug-gnu-emacs@gnu.org \
    --cc=70794@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=mattias.engdegard@gmail.com \
    --cc=spacibba@aol.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.