Re: [PATCH v4] scripts: checkpatch: warn on Rust panicking methods
From: Onur Özkan
Date: Tue Feb 03 2026 - 11:42:26 EST
On Tue, 03 Feb 2026 16:02:02 +0000
"Gary Guo" <gary@xxxxxxxxxxx> 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@xxxxxxxxx> 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.
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.
Thanks,
Onur
>
> Best,
> Gary
>
> >
> > Regards,
> > Onur
> >
> >>
> >> We could just not do this. Right now we are trying to
> >> get a warning if someone uses rust code that can cause a
> >> panic. Software Engineers are smart people. What if they
> >> just don't use rust code that causes panics inside core
> >> files. Problem solved.
> >>
> >>
>