From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com [209.85.128.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4144822E3F0 for ; Wed, 4 Feb 2026 15:56:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770220569; cv=none; b=ZR3trWKEpabm8qUtJlkFzW+GFj6da/UxIpLG2hjLyXDDtDIrKwqJa9x4OaAkHtk/tLvDOsUN/1+3WbEyey5JzBwhTLLVy0szt37Wbv4zrW8J7GbxfLIXtn/16H4PlVneZnE+oK3O2ltu0qPKI+49Ac/HrrhsB5WIdVWqepsz2es= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770220569; c=relaxed/simple; bh=44tE68fxbMUytve8JLfI7Un3Psmjsb0xs8E7ratrBbQ=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=GndefNrC+MMmFHd0LLOAs3ZZgCQA5i4fefoJanFCC6qZFL9JkzuWb9NgDO+184aLRXMzDwuj97qlMr9SIDNJ98MHskAE5ejLDogG0Fjr+utna0gwOyg+lDq/xvo9lDIgYGLcNSFC2brRZqoef3O9Xg7znmo7c8MdnhV8dU8ZeqA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=F2lYUsUa; arc=none smtp.client-ip=209.85.128.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="F2lYUsUa" Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-4806f9e61f9so37208375e9.1 for ; Wed, 04 Feb 2026 07:56:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770220567; x=1770825367; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=N68/duQnJWtvLCCDp1UvZPR0PP1FmT4LAcpWWINYqtI=; b=F2lYUsUaIfJQczqfmlAnBtzwdEtDW2gCXNfxMJgEFEp1GdjFvqCTHGXKMrTNoUwvH1 HlacoAFRx/U6JI3eeXUwJcu01Q9R58Ah0WiHjd/S0B7JFiYUP4QPYoKlGuX20ubYZL1Q id/r0eGGJO+yfqUVOjTrqCt+uEx2h/3P/jlHQRD2L8Jimh6Iwyc9Lgmw7y/1hdcCEX/K FG+3zaB9VFlF/u0N6UAXV6s5qr+ogBpwEOdkMsWJ3z9kJwPWylz3aM1lXv+Fj+r/C5RD klZIMRKSFpwr1kwwV19sbn2AtEABAr7hyvoAPkIIAI7AYsNBOcBRLyHON/tTFeFSOVjN 9OKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770220567; x=1770825367; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=N68/duQnJWtvLCCDp1UvZPR0PP1FmT4LAcpWWINYqtI=; b=LqT9m9JQHtAvhE1HwzpqSZiX2tIkasdlFJ0ifceZc1eer1kK2aDU0ej77nCBNlV7qA mXbOxDik4rlHLD+5MSGITgpfignw+08eMltejboPntnMXZlrynamX/3jdqdYSC3f3Z5T l+ig+acIIrQLsI9UI5nAJMFDHNQyPlZVA1WOie+rMQ7rl76cuwV5VDVaVw2PNGidDmTt e4qpGfi6KmvPB9XY7mOjT92eogRUX9ohtC+iOnSGNZGA8AL3EwAvlt0l6Cp9oltIB2Z6 wXBIBK9fv8tSb9GDNpPHs2U6F30qyPNDHL0piFiqOcZ8d6GEN6wyQfLVczSlu7f9HbLM n84Q== X-Forwarded-Encrypted: i=1; AJvYcCVwns8ZBg8OsbaTsTGEIOkWj/S2Gaj5+9I83VegiCAOH4GiPC6QJTIjF6Jq2eme5eaQ5kE9OEztxrZ2iXM=@vger.kernel.org X-Gm-Message-State: AOJu0YzGk4Vrdf9mGwh5MBGVcKUWGTrZsvz11u7oYABzN1Y78Foqjxvw dxTSw9NBbRx8QQwdhhbJ4bY7O5h8aRjtFcfznGzrHgm4J9U3+jrsAU9K X-Gm-Gg: AZuq6aLp09apv3SonsjxWI8tvo6n2Sbcm9VNjngKJeoU/wa8RSazE8WwjEa1+8pGsOi 186u7YstRaog/DfxlE3iJqz05G7qJI8yBa3aETk/e7aqXjuoTML5dJ4usWgOVQ++RjiOkgISmjf MoQXXFuRrDqUex0OTz03sE6e2fv+IIrvr3PniLBxDgKShjUigt+av29Fw3b+qB+U2TO6/hGkCAX uzxFmPT33ZF0x04gJBJtyi0tQ7RO1uEzlkf32w3k41pP74G+rvcrV1kuj6yX/zNzaV7hazyGtAh cJL4XhQzRCRSWb83fyg9KaKi2W59mR15eln1noiaYrghRm3XrrZrhjnUbAxCmkhJm9ObB7OmMeb XAxMVU2H/ZqZvdxyz4DolQYQwXMqGU+5+nzqZtXldZ6eowHqFD1XoJAtqLGjIMycuAJxq8SXFy1 HB7BKrg8pioso8xPnqPpxMiE8qhBsSrObWwov3HEP/p9L52ob3+dP9qASGtAwZzERHZKzwj/p+O wXZGC0/QB/NNmch11PO2aO8mXo29lFaiAKlrT6/ccNiOg== X-Received: by 2002:a05:600c:5304:b0:477:9a28:b0a4 with SMTP id 5b1f17b1804b1-4830e8ceeeamr43535075e9.0.1770220567323; Wed, 04 Feb 2026 07:56:07 -0800 (PST) Received: from ?IPV6:2003:df:bf2d:e300:ec97:869b:e20f:5396? (p200300dfbf2de300ec97869be20f5396.dip0.t-ipconnect.de. [2003:df:bf2d:e300:ec97:869b:e20f:5396]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-483108e3ed5sm41244885e9.5.2026.02.04.07.56.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Feb 2026 07:56:06 -0800 (PST) Message-ID: Date: Wed, 4 Feb 2026 16:56:05 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4] scripts: checkpatch: warn on Rust panicking methods To: Gary Guo , =?UTF-8?Q?Onur_=C3=96zkan?= Cc: Jkhall81 , dirk.behme@de.bosch.com, joe@perches.com, ojeda@kernel.org, rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org References: <288d4aeb-af0d-4d50-bb0d-7a046abaaf10@de.bosch.com> <20260203152542.45017-1-jason.kei.hall@gmail.com> <20260203184933.23c92f8f@nimda> <20260203193240.68bb136e@nimda> Content-Language: de-AT-frami, en-US From: Dirk Behme In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 03.02.26 17:54, Gary Guo wrote: > On Tue Feb 3, 2026 at 4:32 PM GMT, Onur Özkan wrote: >> On Tue, 03 Feb 2026 16:02:02 +0000 >> "Gary Guo" wrote: >> >>> On Tue Feb 3, 2026 at 3:49 PM GMT, Onur Özkan wrote: >>>> On Tue, 3 Feb 2026 08:25:41 -0700 >>>> Jkhall81 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. 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? So do we find an acceptable way to mark the allowed ones? Or do we drop this patch entirely and hope to catch the "forbidden" ones by review? Or? Best regards Dirk >> 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 > >