Structure finalisers are broken

[Praetonus]

struct Foo
  fun _final() =>
    None

actor Main
  new create(env: Env) =>
    Foo

This code results in an invalid access to memory at runtime. This is caused by the mechanism that runs finalisers (final_small, final_small_freed and final_large in mem/heap.c), as it assumes that every object has a type descriptor and tries to access the object's finaliser through it. Since structs don't have type descriptors, this can't work with them.

We either need to revert to the old finaliser algorithm (using the GC object map) for structs or to come up with a way to store struct finalisers alongside the finaliser bitmap.

[dipinhora]

@Praetonus Stupid question: what would be a use case for a struct having a finaliser? I'm sure there are many but I'm not creative enough to think of one.

[Praetonus]

@dipinhora Any struct representing a C data type with a finaliser function. For example, something like that:

struct data_t
{
  // Some members
};

void data_create(data_t* d);
void data_final(data_t* d);

struct Data
  // Fields equivalent to the C members

  new create() =>
    @data_create[None](this)

  fun _final() =>
    @data_final[None](this)

[dipinhora]

Makes sense. Thanks.

[sylvanc]

General consensus on the sync call is that _final on a struct should be a compile-time error, both because keeping an out-of-band data structure for struct finalisers would be an unnecessary runtime expense, and because finalisers on C allocated memory tend to play havoc with expected orders of free calls under the hood.

This of course is subject to anyone coming up with a good use case for making _final work on a struct, in which case we would need to keep an out-of-band data structure of structs in need of finalisation.