[Techcable]

Allows accessing the mi_heap_t* that owns the mi_theap_t*.

The internal function has been renamed to _mi_theap_heap, and all existing usages have been updated to use that. This means the internal usages are still eligible for inlining.

Possible Issues

The signature of mi_theap_heap currently accepts a *const mi_theap_heap to match the internal function and the fact that the function is read-only. However, this is inconsistent with the sister function mi_heap_theap that accepts a non-const *mi_heap_heap.

I placed the accessor mi_theap_heap under the /* Heap new */ section of the src/heap/theap.c file, which doesn't perfectly fit. Maybe there should be a new /* Accessors */ section in the file.

[Daan (daanx)]

Thank you for the PR,... but this is not a good idea I think; the theap interface is really just exposed for runtime systems in case one wants to avoid the thread local lookup. However, a theap can only be accessed from the owner thread and the theap interface is unsafe in that respect. Furthermore, the only way to get a theap is using mi_heap_theap so one already knows the heap. (btw. that is not quite const as calling mi_heap_theap might create a dynamic thread local for the theap if you have never allocated on that heap from that thread before).

[Techcable]

It seems somewhat silly to store both a mi_heap_t* and mi_theap_t*, considering how easily a theap can be converted into a heap.

I originally planned to use this function as a workaround for the missing functionality added in PR #1477.
There still is a fair deal of other functionality missing on theaps, like mi_heap_realpath and mi_heap_contains.
Some of these functions are niche or only called in cold paths, so it doesn't make sense to define them twice.