AK+Tests: Don't double-destroy NoAllocationGuard in TestFixedArray

[Hendiadyoin1]

This caused the m_allocation_enabled_previously member to be technically uninitialized when the compiler emits the implicit destructor call for stack allocated classes. This was pointed out by gcc on lagom builds, no clue how this was flying under the radar for so long and is not triggering CI.

---

CC @alimpfard @kleinesfilmroellchen

[awesomekling]

Can this be accomplished in a much less hairy way by adding { and } to make a narrower scope for the NoAllocationGuard?

Basically exactly what the "Swap" test already does below.

[Hendiadyoin1]

Can this be accomplished in a much less hairy way by adding { and } to make a narrower scope for the NoAllocationGuard?

Basically exactly what the "Swap" test already does below.

So this is sadly not possible

{
    NoAllocationGuard guard;
    FixedArray<int> moved_to_array(move(moved_from_array));
}

would destroy moved_to_array, and therefore freeing its underlying storage, before the guard re-enables that Move Assignment is deleted, because that would have to free a potentially already existing storage, which is considered a breach of the no-allocation contract.

it works for swap, because both objects exist before the guard is created.

(Assuming all objects are destroyed in reverse-construction/reverse-declaration order)

[alimpfard]

You could do this:

Optional<FixedArray<int>> moved_to_array;
{
    NoAllocationGuard guard;
    moved_to_array.emplace(move(moved_from_array));
}

Also, remind me why the FixedArray destructor needs to allocate...?

[Hendiadyoin1]

You could do this:

Optional<FixedArray<int>> moved_to_array;
{
    NoAllocationGuard guard;
    moved_to_array.emplace(move(moved_from_array));
}

that could work lets see what @kleinesfilmroellchen thinks, its his test/data-structure after all

Also, remind me why the FixedArray destructor needs to allocate...? It frees which might be also blocked by the guard, atl east that's what was stated by the previous comments

[alimpfard]

It frees which might be also blocked by the guard

it's a NoAllocationGuard, doesn't sounds like something that would be blocking free :thinking: