From: "Gary Guo" <gary@garyguo.net>
To: "Onur Özkan" <work@onurozkan.dev>, "Gary Guo" <gary@garyguo.net>
Cc: "Jkhall81" <jason.kei.hall@gmail.com>, <dirk.behme@de.bosch.com>,
<joe@perches.com>, <ojeda@kernel.org>,
<rust-for-linux@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4] scripts: checkpatch: warn on Rust panicking methods
Date: Tue, 03 Feb 2026 16:54:35 +0000 [thread overview]
Message-ID: <DG5HFQ1JHRA1.QTLZFE4GDZT8@garyguo.net> (raw)
In-Reply-To: <20260203193240.68bb136e@nimda>
On Tue Feb 3, 2026 at 4:32 PM GMT, Onur Özkan wrote:
> On Tue, 03 Feb 2026 16:02:02 +0000
> "Gary Guo" <gary@garyguo.net> wrote:
>
>> On Tue Feb 3, 2026 at 3:49 PM GMT, Onur Özkan wrote:
>> > On Tue, 3 Feb 2026 08:25:41 -0700
>> > Jkhall81 <jason.kei.hall@gmail.com> wrote:
>> >
>> >> Nice, emails sent from gmail get automatically rejected.
>> >>
>> >> So, Dirk. To satisfy your concerns the current 10ish line
>> >> code update is going to slowly, after many more emails
>> >> written in nano, mutate into a franken-regex-perl beast.
>> >> checkpatch.pl is already huge. I'm not a fan of this
>> >> approach.
>> >
>> > Me neither. I wonder why we are doing this instead of using the
>> > unwrap_used and expect_used linting rules from clippy. This would
>> > catch the problem much earlier than checkpath since many of us build
>> > the kernel with CLIPPY=1 flag.
>>
>> Because it's okay to `panic` or use `expect`. checkpatch will just
>> warn you once when the code is introduced, not continuously in each
>> build.
>
> That's interesting because it implies that it's okay for people to use
> them without "// PANIC..." comments. That sounds problematic since it
> means some instances will have that comment while others may not.
My personal view has always been it's okay to not have it. It's a burden to
developers to always have to write these. In many cases, `panic()` or `expect()`
calls are needed because you have something of `Option<>` and you know it's not
going to be `None`. The C equivalent would just be a pointer and you use it
without checking for NULL; we never ask people to justify why they feel it's
okay to dereference a pointer.
Sure, if people would like to justify why they think it won't panic, brilliant,
keeping doing it. But I don't want to make it harder for people to write Rust
code compared to C.
>
> In my opinion, adding a clippy rule and using "#[allow(...)]" in the
> places where it's acceptable to use them makes more sense. This is at
> least more consistent and doesn't bloat the checkpatch file.
`#[allow()]` looks quite verbose, and also you cannot apply it everywhere (just
blocks or items).
Best,
Gary
next prev parent reply other threads:[~2026-02-03 16:54 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-01 15:57 [PATCH] " Jason Hall
2026-02-01 17:19 ` Charalampos Mitrodimas
2026-02-01 18:30 ` [PATCH v2] " Jason Hall
2026-02-01 19:37 ` Joe Perches
2026-02-01 19:57 ` [PATCH v3] " Jason Hall
2026-02-02 5:38 ` Dirk Behme
2026-02-02 13:56 ` [PATCH v4] " Jason Hall
2026-02-03 6:21 ` Dirk Behme
2026-02-03 15:25 ` Jkhall81
2026-02-03 15:49 ` Onur Özkan
2026-02-03 16:02 ` Gary Guo
2026-02-03 16:32 ` Onur Özkan
2026-02-03 16:54 ` Gary Guo [this message]
2026-02-04 15:56 ` Dirk Behme
2026-02-04 18:10 ` Miguel Ojeda
2026-02-04 19:08 ` Joe Perches
2026-02-05 1:42 ` [PATCH v5] scripts: checkpatch: move Rust-specific lints to separate file Jason Hall
2026-02-05 20:55 ` Miguel Ojeda
2026-02-06 8:31 ` Dirk Behme
2026-02-06 17:41 ` Miguel Ojeda
2026-02-07 15:56 ` [PATCH v6] " Jason Hall
2026-02-07 16:07 ` Miguel Ojeda
2026-02-07 16:53 ` [PATCH v7] " Jason Hall
2026-02-07 18:46 ` Miguel Ojeda
2026-02-07 21:07 ` [PATCH v8 0/2] modularize Rust lints and add RUST_UNWRAP check Jason Hall
2026-02-07 21:07 ` [PATCH v8 1/2] scripts: checkpatch: move Rust-specific lints to separate file Jason Hall
2026-02-07 21:53 ` Miguel Ojeda
2026-02-07 22:49 ` [PATCH v9 0/2] modularize Rust lints and add RUST_UNWRAP check Jason Hall
2026-02-07 22:49 ` [PATCH v9 1/2] scripts: checkpatch: move Rust-specific lints to separate file Jason Hall
2026-02-07 22:49 ` [PATCH v9 2/2] scripts: checkpatch: add RUST_UNWRAP lint Jason Hall
2026-02-08 7:55 ` Dirk Behme
2026-02-08 14:01 ` Jason Hall
2026-02-09 8:52 ` Dirk Behme
2026-02-08 6:43 ` [PATCH v9 0/2] modularize Rust lints and add RUST_UNWRAP check Greg KH
2026-02-14 6:11 ` Dirk Behme
2026-02-14 23:30 ` Miguel Ojeda
2026-02-14 23:32 ` Miguel Ojeda
2026-02-07 21:07 ` [PATCH v8 2/2] scripts: checkpatch: add RUST_UNWRAP lint Jason Hall
2026-02-05 13:23 ` [PATCH v4] scripts: checkpatch: warn on Rust panicking methods Dirk Behme
2026-02-05 21:00 ` Miguel Ojeda
2026-02-04 18:11 ` Miguel Ojeda
2026-02-01 19:51 ` [PATCH] " Gary Guo
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=DG5HFQ1JHRA1.QTLZFE4GDZT8@garyguo.net \
--to=gary@garyguo.net \
--cc=dirk.behme@de.bosch.com \
--cc=jason.kei.hall@gmail.com \
--cc=joe@perches.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=work@onurozkan.dev \
/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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®