refactor(shada): A shada entry is a shada entry

problem: most shada entries use weird `PossiblyFreedShadaEntry` type
solution: delet it

Shada entries can either be allocated by shada.c when reading,
or be constructed to represent the state of the current instance,
with direct references to live instance data to avoid extra allocations.
shada.c needs to carefully only free memory allocated by the first case,
and not free memory owned by other subsystems.

In some part of the code, this is inferred by the context but in others
we are mixing entries from different sources and need to indicate
the provenance by a `can_free_entry` flag. However constantly
frontloading this distinction  in the name of the type and with
extra nesting levels, cause extra cognitive overhead when trying
to understand the code in any other aspects than the specific detail
of avoiding leaks/double frees.

As we always know if the memory is owned or not for any entry, we
can just put `can_free_entry` directly on the ShadaEntry struct.
That only one state is possible in a given context, is indicated
by this neat little syntactical construct called a constant field
initializer.

0 files changed, 0 insertions, 0 deletions