From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) (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 2C9F83009E1 for ; Sat, 14 Feb 2026 06:11:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771049518; cv=none; b=UcJhk+Ug5/0W+SpLCJXMzO3S1UPoIYPVQAU/zDZSf7lGRhxB6gMTLZxjZSXgDXc5qTVJ/zp+whvT54Sz/WYaPbeizsH1cU9P7rv/FvHHvcwGDgGCQJorTY4z7mDQaU0C7058Q29GsREGYg0qR1dibr45Y6gZLLXPWs6SF0o2V8g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771049518; c=relaxed/simple; bh=BY0d32+ZzDAZ64umGmXB44D6PovXFeZOF9FQxmubx2c=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=qiZieQ5EOpi005euy5+RKIpmiFYuD2P7wh5Bnn9wamtveDpBqYiaEQWtYG+4DFcDaNDnJj0lBKEy3YRMTOAXg1iyLLWaQ47S3q57bu6aPyTZn+gq48UBrdrnMt7Lbe8d6v7+ODfrC633kFNFhILX/OlEhsLOmnSasXGB78pihqA= 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=hhhIVbqV; arc=none smtp.client-ip=209.85.128.45 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="hhhIVbqV" Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-481188b7760so13464255e9.0 for ; Fri, 13 Feb 2026 22:11:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771049510; x=1771654310; 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=VgGBcvHQoegFD18ugg7yJkEg1tzSzql8ilNB2jpbr3c=; b=hhhIVbqVAFRnS0aiZjmxPobjXu76E8ItdJre2eOOJa68OYt/eGzZ5JQRyY5Q7GZoWH 9rsBHih6Tuqe+15mjKDQaP+XDIWH4reUfXIhTWdLf/X4H46t3gvtKHuIvD0ypD4kYpF5 0UJbKYwKxYnTIDry5P8RwUTaVjTqT6AllyGE0ch+2DIv3KpqQbnXCQslVYyUE6twQIxk ZuZ4SXcTV01J6He0HR4et+1pISKV9ukqJIsGkoCfOYKwjYhF6b9CnrksKhagv9LLFGQX KHD+LlSDZRjjLTXnEhCZR5f30anSM/e0UP3H6E9+6v7WyMq8hP/JuHj9LPOl3Zto/kK0 83ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771049510; x=1771654310; 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=VgGBcvHQoegFD18ugg7yJkEg1tzSzql8ilNB2jpbr3c=; b=VC8LtImvup91aWRIYqM3vpTAyhC59kgHepqtJJuhfWvJKZ8OBliw2J18t9wwZOMjXl hHh2wqelk71D/KhoMyDmnMp0Bdnq9nR2teYj+0x8hZ6nhnDo1eRw07Q+XJ27GTClJzto r1xE+jH42Nw5fnwPDficnIasIGS5JH8xoXT7xd7L8zPBNt+wr+fk705D0QnsGOtXwpLk XegLcKffYDAJa1fA0uxJ3wRqH7VGOkBX97TPi24BcD1FrglCW9rhBGNe9ZyTf7xI1MEG RFtLGf3VCac8oCWyAcY2dr3UUw663nGBhFcnZIFdlImifmbL5t7Loq2Q1sVq+4tVTiB3 4vQw== X-Forwarded-Encrypted: i=1; AJvYcCVhJdLpNBO0Kar9JiYOAuV0Ci1GKBU/nV+k6mcS/GTl5WJBeSttM1khjHQZUldNzx7vMo7lZUsKyQ1Mvqw=@vger.kernel.org X-Gm-Message-State: AOJu0YwQBChF2ef7Eoi0t9GWTddRDhrQ9qMbWz0N6QIvxbNmi3P+TgIp 1XoffzGoVnHCRliinV5tVvDIdCeFxUvDISH5Xyjdlc8hkGVlGwixqdO7 X-Gm-Gg: AZuq6aIOmtui6DQy/N9e3o6yTLsBJxDJOZ7/wV52zWnfh70tpEMkPcDGtcBlJaczbKs e5u2/KOEvpZhXAU1HF08D16ezAKHqsm7hd5Bw07Qc0zrwAn9Ic9fg41o4yGA/Z4hUS6/jay/qBP i/cUhhTwSdQK+03jbQsOaoOVajcWpancAVq7hqfjKBq6Eg8/30XmvOLC662yrSMJX61Zwd8Xkgv F52BC+QrikkelFpIYdCPWqekyqAzyKsLFOL0KGxCPFQVQUZlAewLFJI87lVTAm+XZOranPu90mu XjGvvKA109umL3wfkIZtj+WMP0WrdwYQu3DE2yq+uvytxawaOCxDMwdN0UPAUvdhteglds6M8kO DV8pKvZBtNUaGlBQDH7B64O6Jjm2I56AZh9EZNwoJ+RBRhiEBUMyxHwG46YB3PkV3ERR7126VBo q/oHrnaPKTitlC1KnUfcmBuTkCZDekbAtSc9dXftDlAqV2ZvJlusxEHjqdS8AuV1onnNvwhrSNX aAtyzlZkRTtJklder0BjTK1N0HTrKXtVXNKilz4gmkI48nYUZoiyI8AgA== X-Received: by 2002:a05:600c:5306:b0:480:4d39:84b3 with SMTP id 5b1f17b1804b1-483739fc667mr60964125e9.6.1771049510162; Fri, 13 Feb 2026 22:11:50 -0800 (PST) Received: from ?IPV6:2003:df:bf29:9000:b585:cc2d:57dc:3085? (p200300dfbf299000b585cc2d57dc3085.dip0.t-ipconnect.de. [2003:df:bf29:9000:b585:cc2d:57dc:3085]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4837e565f5esm7439175e9.10.2026.02.13.22.11.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 13 Feb 2026 22:11:49 -0800 (PST) Message-ID: Date: Sat, 14 Feb 2026 07:11:48 +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 v9 0/2] modularize Rust lints and add RUST_UNWRAP check To: Jason Hall , Miguel Ojeda Cc: rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org, Joe Perches , Boqun Feng , =?UTF-8?Q?Bj=C3=B6rn_Roy_Baron?= , Benno Lossin , Andreas Hindborg , Alice Ryhl , Trevor Gross , Danilo Krummrich , Dirk Behme , Andy Whitcroft , Dwaipayan Ray , Lukas Bulwahn References: <20260207224907.234815-1-jason.kei.hall@gmail.com> Content-Language: de-AT-frami, en-US From: Dirk Behme In-Reply-To: <20260207224907.234815-1-jason.kei.hall@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Jason and Miguel, On 07.02.26 23:49, Jason Hall wrote: ... > The second patch introduces the RUST_UNWRAP lint, which warns against > the use of .unwrap() and .expect() unless they are accompanied by a > '// PANIC:' justification comment. While some further thinking about the discussion in this thread I'm under the impression that going this way somehow leaves us unhappy. Either it becomes complicated (again, many thanks to Jason for working on this!) or we will end up with several limitations and (confusing?) false positives. I wonder if it would be an option to change the strategy here? In the last time we have introduced several rules by "convention". Without checkpatch or lint support. Like "please use vertical style for imports", "please use `__rust_helper` for helpers" or "please drop `as_ref` from dev_* prints". Would it be an (easier?) option to go the same way here? Instead of enforcing it with checkpatch? I'm thinking about the same approach like we did with the examples above: We identify the "wrong" `unwrap()` usages in the existing code and "fix" them with patches. What would result in a clean code base. At the same time it will give developers an indication that the remaining ones are "allowed" ones which are ok. And for new code in the review we ask for corrections if we spot a "wrong" usage. Best regards Dirk