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:]]+\\)"
next prev parent 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.