From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0EEAF21B8E7; Fri, 22 Aug 2025 11:44:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1755863078; cv=none; b=C9dygw10pVI40VKwsJp56ppYbUKINqIxhrueRx8zFy2oZpCu/g5fAXl50jBspe3ThLSYgawp7GqUJxv7VSqycan3IrPLGnosOsIbl5KGWnNqDMvwHlegZ0grcak3P/jUR7verc403/Sc57jTyvZ/x1pbdoD8U68T6bdZSxU/vG8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1755863078; c=relaxed/simple; bh=Ehes+TywfQ8xDxHjBhYwV5+QsAnE1nz2pIE2gJ1LGto=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:To:From:Subject: References:In-Reply-To; b=Us4+CZ65LjTuwFojLjJSTzCOR5Blp/7R1MRzNTa2pN51bfNgt2ZVGH9qPDvPNnQknxMQ9DplBFWL8N8yBLxN3l+xAZ/LBCOqWChUcsiV0nmJc/j5bJk7FwccFhoDR2sxbU4VDlbRcSNcP32jzyP6xyrH95+8G0i2iPJ0tMaiwxg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=F1W11D/J; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="F1W11D/J" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 72C73C4CEED; Fri, 22 Aug 2025 11:44:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1755863077; bh=Ehes+TywfQ8xDxHjBhYwV5+QsAnE1nz2pIE2gJ1LGto=; h=Date:Cc:To:From:Subject:References:In-Reply-To:From; b=F1W11D/JM+EVtZrd92D8APNnrRop1qUdCnOCAAI9gsr6pFiXkKFWqTBytD/QTtUyd iBoNrJwEsu1fXNzWoKiBt1n1lVURchROVLD1cmjvzUhwTGQo40OjJtpfs8Fn81qRCX YrxCtcPh8l7cCgzF11ttjKLP7uQtXBH7CbMUhV832gEqDJekFDAwxYLfCLviOwEN08 jvy73WQG+l5k04vvDHgGb9Qsslni5m/A7j39xE2gAnfBaez53gEEFFLYyvI/jSnG20 aj5o8tCaNHsYYggUwZC9CDcmvPC5wkstUB2bh9p5HFiKLhkC3J7R4ouC1v5AaScFSH 9OPNIZrlm0weg== Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Fri, 22 Aug 2025 13:44:32 +0200 Message-Id: Cc: "Alice Ryhl" , "Andrew Morton" , "Liam R. Howlett" , "Lorenzo Stoakes" , "Miguel Ojeda" , "Andrew Ballance" , "Boqun Feng" , "Gary Guo" , =?utf-8?q?Bj=C3=B6rn_Roy_Baron?= , "Benno Lossin" , "Andreas Hindborg" , "Trevor Gross" , , , , To: "Miguel Ojeda" From: "Danilo Krummrich" Subject: Re: [PATCH v2 2/5] rust: maple_tree: add MapleTree References: <20250819-maple-tree-v2-0-229b48657bab@google.com> <20250819-maple-tree-v2-2-229b48657bab@google.com> In-Reply-To: On Fri Aug 22, 2025 at 1:26 PM CEST, Miguel Ojeda wrote: > On Fri, Aug 22, 2025 at 1:05=E2=80=AFPM Danilo Krummrich wrote: >> >> We should probably check if we can get a clippy warning in place for thi= s. > > There is https://rust-lang.github.io/rust-clippy/master/index.html#unwrap= _used, > which covers all cases. Great! I think there's a lot of value in getting this enabled. >> we could also write >> >> assert!(tree >> .insert(100, the_answer, GFP_KERNEL) >> .is_err_and(|e| e.cause =3D=3D InsertErrorKind::Occupied)); > > If we want to use the Clippy lint, i.e. go hard on avoiding all kinds > of `unwrap()`s, then that is fine. > > But I wouldn't do it just for the sake of avoiding a few > `unwrap_err()`s within `assert!`s Why not? I mean, the above is cleaner and more idiomatic with or without th= e lint enabled. As mentioned, it's even the showcase that has been picked for= the documentation of Result::is_err_and(). > I don't think there is going to > be a problem of having a lot of people concluding it is OK to panic > the kernel in general just because they see an `unwrap_err()` within > an `assert!` -- the `assert!` itself could be also understood as > panicking, after all, and we really don't want to ban `assert!`s on > examples. I didn't mean to say that people conclude it's OK to panic the kernel. But especially people new to the kernel starting to write Rust drivers may = not even be aware of this fact. If they see some unwrap_err() calls in examples= they might not even thing about it a lot before starting to use them, e.g. becau= se they're used to it from userspace projects anyways. > Now, if we do get something else out of it, like enforcing no > `unwrap()`s (still bypassable with `allow` etc. if needed) and thus > removing a class of errors, then that sounds worthier to me. I think we should do this; I really think otherwise we gonna see a lot of t= hem once we get more drivers. It's just too convinient. :)