This affects `runtime.Arena` and `virtual.Arena`, but not currently
`mem.Arena`. These changes allow the last allocation that has been
made to be resized to a larger size by just extending their
allocation in-place, when there's sufficient room in the memory block to
do so.
Shrinking in place and re-using the rest of the allocation can be
supported using almost the same logic, but would require the memory to
be zeroed. Since this would add a additional cost that isn't currently
present, shrinking has not been changed.
`map_desired_position` does not return the actual position, probing must
be done afterwards to figure out the real position. `map_entry` did not
do this for the returned key pointer so it could point to the wrong key
if probing was done.
This provides an equivalent to `assert` and `assert_contextless` that
are always evaluated, ignoring `ODIN_DISABLE_ASSERT`, which is useful
for enforcing API contracts or "asserting" on conditionals with
side-effects.
`make(map[K]V)` was resolving to `make_map_cap()` which allocates initial capacity when it wasn't intended to.
It now calls `make_map()` which doesn't allocate any capacity.
Both `make(map[K]V)` and `make(map[K]V, allocator)` will NOT allocate initial capacity now.
No idea why the floattidf procs are bodged to return 0, does somebody
know? I have just enabled the original codepath, if nobody knows I
suggest just enabling it and see if we get complaints, it works on all
wasm stuff I tried.
The linkage being set to "internal" instead of "strong" is actually
causing problems in my projects which is what prompted looking at this
in the first place, some of these functions were actually needed but not
added/used because they had internal linkage. This only happens on
bigger projects (or just when using f16?).
Unfortunately `git blame` gave me this generic commit: 94bad4d786 (diff-fb9f42022cb95efa59d16813546b8cb310234428c85edfabf09b1425c9dc46af)
