nix_api_expr: ensure destructors are called for builder/state

[corngood]

I found this because of a test failure on cygwin in nix_api_expr_test.nix_eval_state_lookup_path:

'std::filesystem::__cxx11::filesystem_error'
what(): filesystem error: cannot remove all: Device or resource busy
[...]
[.../my_state/db/db.sqlite]

LocalState was never getting destroyed due to a reference leak. These _free functions use an 'operator delete' which doesn't call the destructor for the type.

Fixes: 309d558

[xokdvium]

Sucks that we are using the operator new/delete that just allocate raw bytes. I have no clue why it's done in this incredibly janky way.

[corngood]

Sucks that we are using the operator new/delete that just allocate raw bytes. I have no clue why it's done in this incredibly janky way.

As far as I can tell it's to make it easier to init self-references in structs, like:

        return unsafe_new_with_self<nix_eval_state_builder>([&](auto * self) {
            return nix_eval_state_builder{
                .store = nix::ref<nix::Store>(store->ptr),
                .settings = nix::EvalSettings{/* &bool */ self->readOnlyMode},
                .fetchSettings = nix::fetchers::Settings{},
                .readOnlyMode = true,
            };
        });

template<typename T, typename F>
static T * unsafe_new_with_self(F && init)
{
    // Allocate
    void * p = ::operator new(sizeof(T), static_cast<std::align_val_t>(alignof(T)));
    // Initialize with placement new
    return new (p) T(init(static_cast<T *>(p)));
}

It's clever, but it's only used in two places. And obviously it's pretty easy to get wrong, because it was originally mixing different new/delete operators which lead to the fix that caused the leak...