Re: [PATCH v3 03/12] rust: xarray: add `contains_index` method

[Andreas Hindborg <a.hindborg@kernel.org>]

Alice Ryhl <aliceryhl@google.com> writes:

> On Thu, Feb 12, 2026 at 01:39:48PM +0100, Andreas Hindborg wrote:
>> "Alice Ryhl" <aliceryhl@google.com> writes:
>> 
>> > On Thu, Feb 12, 2026 at 11:52 AM Andreas Hindborg <a.hindborg@kernel.org> wrote:
>> >>
>> >> Andreas Hindborg <a.hindborg@kernel.org> writes:
>> >>
>> >> > As far as I understand, this is a borrow checker limitation. It is easy
>> >> > for us to look at this code and decide that the borrow on line 51 will
>> >> > never alias with the borrow on line 49.
>> >>
>> >> I did a bit of googling, and this seems to be a well known issue with
>> >> the current implementation of lifetime analysis in the rust compiler.
>> >> Apparently this kind of code used to be OK [1] but the Rust devs decided
>> >> to remove the code that allowed this, because it was causing excessive
>> >> compilation times [2]. The upside is that this is solved by the new
>> >> lifetime analysis implementation called "Polonius" and it is the
>> >> intention to replace the existing implementation with Polonius at some
>> >> point [3].
>> >
>> > I believe the standard fix for this issue is to provide an entry api
>> > similar to HashMap::entry(). See the rbtree for an example, as it
>> > already provides such API.
>> 
>> The example above [1] is using the BTreeMap entry API to produce the
>> issue. Are the BTreeMap and HashMap entry APIs significantly different,
>> or is there something else I missed?
>> 
>> Best regards,
>> Andreas Hindborg
>> 
>> [1] https://lore.kernel.org/r/87y0kytggx.fsf@kernel.org
>
> Hrm, tricky. I think it would work if the entry type had an into_map() that
> consumes the entry and returns a &mut to the original map.
>
>   fn transaction_impl1<'a>(maps: &'a mut Maps, key: u32) -> &'a mut u32 {
>       match maps.a.entry(key) {
>           Entry::Occupied(o) => o.into_mut()
>           Entry::Vacant(v) => {
>               let map_a = v.into_map();
>               let value = map_a.first_entry().expect("Not empty").remove();
>               maps.b.entry(key).or_insert(value)
>           }
>       }
>   }

I see. In my use case, this line

  map_a.first_entry().expect("Not empty").remove();

is not open coded. Rather, it is in a function on `Maps`:

  impl<'a> Maps<'a> {
      fn foo(&mut self) -> u32 {
          self.a.first_entry().expect("Not empty").remove()
      }
  }

  fn transaction_impl1<'a>(maps: &'a mut Maps, key: u32) -> &'a mut u32 {
      match maps.a.entry(key) {
          Entry::Occupied(o) => o.into_mut(),
          Entry::Vacant(v) => {
              let value = maps.foo();
              maps.foo();
              maps.b.entry(key).or_insert(value)
          }
      }
  }

In the actual code, `Maps::foo` is not a small short function, which is
why I extracted it into a function.

I think I could make this work if I just put everything in one big
function, but that does not seem like the right solution.

Am I holding it wrong here, or is this just the way it is?

My `transaction_imp1` is `get_or_alloc_cache_page` [1] and my `foo` is
`extract_cache_page` [2] if you want to have a look.


Best regards,
Andreas Hindborg


[1] https://git.kernel.org/pub/scm/linux/kernel/git/a.hindborg/linux.git/tree/drivers/block/rnull/disk_storage.rs?h=rnull-v6.19-rc5#n209
[2] https://git.kernel.org/pub/scm/linux/kernel/git/a.hindborg/linux.git/tree/drivers/block/rnull/disk_storage.rs?h=rnull-v6.19-rc5#n148