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

From: Alice Ryhl

Date: Fri Feb 13 2026 - 03:18:09 EST


On Thu, Feb 12, 2026 at 01:39:48PM +0100, Andreas Hindborg wrote:
> "Alice Ryhl" <aliceryhl@xxxxxxxxxx> writes:
>
> > On Thu, Feb 12, 2026 at 11:52 AM Andreas Hindborg <a.hindborg@xxxxxxxxxx> wrote:
> >>
> >> Andreas Hindborg <a.hindborg@xxxxxxxxxx> 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@xxxxxxxxxx

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)
}
}
}

The HashMap and BTreeMap apis are not particularly different.

Alice