Re: [PATCH v4] scripts: checkpatch: warn on Rust panicking methods
From: Joe Perches
Date: Wed Feb 04 2026 - 14:08:43 EST
On Wed, 2026-02-04 at 19:10 +0100, Miguel Ojeda wrote:
> On Wed, Feb 4, 2026 at 4:56 PM Dirk Behme <dirk.behme@xxxxxxxxx> wrote:
> >
> > The question is if we could find a way to make it *consistent*?
> >
> > I mean how should a developer know if the warning (he gets once, or
> > even if he checks an existing file with -f always) is relevant or not?
> > We introduce the warning because we want to discourage the use of
> > `unwrap()`. At the same time there are places where its usage is
> > allowed or even needed. How to know what is valid? The warning or the
> > usage?
>
> I think usually developers use `checkpatch.pl` mostly on patches, not
> existing files; plus it doesn't make the build fail. Thus I see
> `checkpatch.pl` as a tool that can have way more false positives than
> a linter that we need to keep strictly clean.
>
> The idea with the `checkpatch.pl` warning was to have something we
> could land easily before we got the new Clippy lints, and perhaps to
> apply it in more cases than the eventual Clippy lint (since false
> positives are not as concerning).
>
> I have some context in
> https://github.com/rust-lang/rust-clippy/issues/15895 -> "Additional
> context", and a few other issues linked in
> https://github.com/Rust-for-Linux/linux/issues/349 for the new lints.
Maybe adding something like this to checkpatch so rust
specific checks and possibly other execs could be added
relatively easily in checkpatch's process()
process_rust() if ($realfile =~ /\.rs$/);
---
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index e56374662ff79..bd9daa77470a5 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -20,6 +20,8 @@ my $D = dirname(abs_path($P));
my $V = '0.32';
+require "$D/rust_checkpatch.pl";
+
use Getopt::Long qw(:config no_auto_abbrev);
my $quiet = 0;