[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <DFK801ZCI1GD.34GWJ10JZBBBF@garyguo.net>
Date: Fri, 09 Jan 2026 17:04:58 +0000
From: "Gary Guo" <gary@...yguo.net>
To: "Tamir Duberstein" <tamird@...il.com>, "Andreas Hindborg"
<a.hindborg@...nel.org>
Cc: "Miguel Ojeda" <ojeda@...nel.org>, "Alex Gaynor"
<alex.gaynor@...il.com>, "Boqun Feng" <boqun.feng@...il.com>, "Gary Guo"
<gary@...yguo.net>, Björn Roy Baron
<bjorn3_gh@...tonmail.com>, "Benno Lossin" <lossin@...nel.org>, "Alice
Ryhl" <aliceryhl@...gle.com>, "Trevor Gross" <tmgross@...ch.edu>, "Danilo
Krummrich" <dakr@...nel.org>, "Daniel Gomez" <da.gomez@...nel.org>,
<rust-for-linux@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 03/10] rust: xarray: add `contains_index` method
On Fri Jan 9, 2026 at 3:59 PM GMT, Tamir Duberstein wrote:
> On Fri, Jan 9, 2026 at 5:38 AM Andreas Hindborg <a.hindborg@...nel.org> wrote:
>>
>> "Tamir Duberstein" <tamird@...il.com> writes:
>>
>> > On Thu, Jan 8, 2026 at 4:38 AM Andreas Hindborg <a.hindborg@...nel.org> wrote:
>> >>
>> >> Tamir Duberstein <tamird@...il.com> writes:
>> >>
>> >> > On Wed, Jan 7, 2026 at 1:34 PM Andreas Hindborg <a.hindborg@...nel.org> wrote:
>> >> >>
>> >> >> Tamir Duberstein <tamird@...il.com> writes:
>> >> >>
>> >> >> > On Wed, Dec 3, 2025 at 5:27 PM Andreas Hindborg <a.hindborg@...nel.org> wrote:
>> >> >> >>
>> >> >> >> Add a convenience method `contains_index` to check whether an element
>> >> >> >> exists at a given index in the XArray. This method provides a more
>> >> >> >> ergonomic API compared to calling `get` and checking for `Some`.
>> >> >> >
>> >> >> > It isn't clear when you'd want this API, and neither this nor the
>> >> >> > example are particularly motivating.
>> >> >>
>> >> >> I added this when I had a line reading `if xa.get(index).is_none()
>> >> >> {...}`. I think it reads better as `if !xa.contains_index(index) {...}`.
>> >> >
>> >> > What was the code surrounding it?
>> >> >
>> >> >> Do you have an idea of how to improve the motivational factor of the
>> >> >> example? Writing motivating examples is not my top skill.
>> >> >
>> >> > IMO writing a better example is not the issue; rather it would be good
>> >> > to understand why you need it. In my experience `Option::is_none` is a
>> >> > smell, but hard to say without seeing the surrounding code.
>> >>
>> >> fn get_cache_page(&mut self, sector: u64) -> Result<&mut NullBlockPage> {
>> >> let index = Self::to_index(sector);
>> >>
>> >> if self.cache_guard.contains_index(index) {
>> >> Ok(self.cache_guard.get_mut(index).expect("Index is present"))
>> >> } else {
>> >> let page = if self.disk_storage.cache_size_used.load(ordering::Relaxed)
>> >> < self.disk_storage.cache_size
>> >> {
>> >> self.hw_data_guard
>> >> .page
>> >> .take()
>> >> .expect("Expected to have a page available")
>> >> } else {
>> >> self.extract_cache_page()?
>> >> };
>> >> Ok(self
>> >> .cache_guard
>> >> .insert_entry(index, page, Some(&mut self.hw_data_guard.preload))
>> >> .expect("Should be able to insert")
>> >> .into_mut())
>> >> }
>> >> }
>> >>
>> >> For lifetime reasons, I cannot borrow `self` in the taken arm.
>> >
>> > That's surprising. Couldn't you destructure Self so that all the
>> > references derive from the single mutable reference &mut self?
>>
>> I don't think so, because I still need `&mut self` around to do the call
>> to `extract_cache_page`.
>
> Hmm, I must have missed it before, but can't this all be fixed with an
> early return?
>
> if let Some(page) = self.cache_guard.get_mut(index) {
> return Ok(page);
> }
The returned lifetime needs to be same as the lifetime of `&mut self` (let's
call it `'self`). This would mean that `get_mut` would also need to borrow it
for `'self` (mutably), so it cannot be borrowed again, mutably or otherwise,
later in the function. This is a classical category of borrowck false positives
that only Polonoius can address, not the current generation of borrow checker.
Best,
Gary
Powered by blists - more mailing lists