moonbitlang / core / 6513

89%

push

github

fix(deque): stop nulling vacated slots so views cannot read invalid memory

`Deque::as_views` hands out `ArrayView`s that share the deque's buffer, and
every shrinking operation cleared the slots it vacated with
`%fixedarray.set_null`. A view created before such a mutation then read a null
slot: SIGSEGV on native for reference element types, `null` on wasm-gc,
`undefined` on JS. `Deque::as_views` is plain `pub`, so this was undefined
behaviour reachable from entirely safe code.

Vacated slots are now left alone, so a view can only ever observe valid values
of `A`. Mutating a deque while a view of it is alive stays a program error,
but what the view yields is merely unspecified rather than invalid.

The cost is that a removal retains what it removes, and that applies uniformly:
`clear` empties a deque the same way `pop_back` shortens it, and neither writes
to the slots it gives up. No existing signature changes. The removed elements
are released once a later push reuses the slot, once the buffer grows, or once
the deque is dropped, so clear-and-refill self-heals -- each push releases one
old occupant, and repeated fill/drain cycles on one deque hold flat.

Reclaiming on demand is explicit. The new `Deque::release_unused(placeholder~)`
overwrites every slot not currently holding an element with the placeholder --
the complement of the occupied run, which may wrap around the end of the
buffer -- and that is exactly the region any removal leaves behind: one pass,
no allocation, capacity kept.
`shrink_to_fit` was already releasing those elements by letting the old buffer
go, at the cost of an allocation plus a copy of every survivor; that is now
documented rather than incidental.

Writing into that region needs no high-water mark, because it is always either
NULL or a live reference, never garbage: `UninitializedArray::make`
(`%fixedarray.make_uninit`) NULL-fills for reference element types, growing
blits into a fresh NULL-filled buffer, and the pushes alr... (continued)

9 of 9 new or added lines in 1 file covered. (100.0%)

16827 of 18500 relevant lines covered (90.96%)

284071.28 hits per line