Make the allocators' unittests and allocate, owns and resolveInternal…

[edi33416]

…Pointer methods safe

Allocating memory should be a safe operation and so should functions like owns and resolveInternalPointer.

[JackStouffer]

There's no guarantee that parent.goodAllocSize is @safe. Best leave this to be inferred.

[edi33416]

Imho I think that this function should be safe and thus I thought we should enforce it upon the parent.

[JackStouffer]

same problem here

[edi33416]

same for this

[JackStouffer]

Under no circumstances should @trusted be applied to an entire function.

[aG0aep6G]

I've protested the change to ubyte[] with code that looks innocuous but actually causes memory corruption (see here). You're now making that code @safe.

import core.memory: GC;
import std.stdio: writeln;
import std.experimental.allocator: make;
import std.experimental.allocator.building_blocks: NullAllocator, Region;

struct S { int* p; }

void main() @safe /* !! */
{
    auto buf = new ubyte[](S.sizeof);
    auto r = Region!(NullAllocator, 1)(buf);
    S* s = r.make!S(new int);
    *(*s).p = 42;
    writeln(*(*s).p); /* prints "42" as expected */
    
    version (none) GC.collect(); /* not @safe */
    else new int[](1_000); /* trigger a GC collection in an @safe manner */
    
    *(new int) = 13;
    writeln(*(*s).p); /* prints "13" - whoopsie */
}

This is exactly what must not happen in @safe code.

[andralex]

OK @edi33416 and I just talked about this and we'll go with the following idea - define this struct:

struct OpaquePointer
{
    private void* pointer;
    @disable this(void*);
}

Now, new OpaquePointer[100] will mark the memory for scanning by the GC.

Allocators that manage a raw buffer of memory will accept OpaquePointer[] safely. The responsbility of allocating the buffer properly falls on the caller.

@edi33416 you may want to shorten this PR to only include the other, simpler primitives.

[andralex]

this is being sold as parts :)