Add std.internal.mmm and reap benefits in @safe-ty and OOM checking

[JakobOvrum]

This patch adds a new internal module std.internal.mmm with the following functions:

// Unsafe as T has pointers
T* checkedMalloc(T)() @system if (hasIndirections!T);

// Ditto
T[] checkedMallocArray(T)(size_t n) @system if (hasIndirections!T);

// Known to be safe because T has no pointers
T* checkedMalloc(T)() @trusted if (!hasIndirections!T);

// Ditto
T[] checkedMallocArray(T)(size_t n) @trusted if (!hasIndirections!T);

// Attributes depend on emplaceRef
T* checkedMalloc(T, Args...)(auto ref Args args);

// Attributes depend on the range primitives of `Range` as well as
// the construction and destruction of `ElementType!Range`
T[] checkedMallocArray(T, Range)(Range range)
if (isInputRange!Range && hasLength!Range && is(ElementType!Range : T));

// Ditto; same as above but with inferred element type
ElementType!Range[] checkedMallocArray(Range)(Range range)
if (isInputRange!Range && hasLength!Range);

// Always safe as calloc zero-initializes memory
T* checkedCalloc(T)() @trusted;

// Ditto
T[] checkedCallocArray(T)(size_t n) @trusted;

// Destroy all elements in the given array
void[] destroyArray(T)(ref T[] array);

Additionally, inferred purity can be supported if malloc and calloc are marked pure in core.stdc.stdlib in the spirit of memory allocation being practically pure.

Included are a few commits demonstrating how to reap benefits from this module. They can be moved to a different PR if desirable - the point is that they demonstrate the module's usefulness (hopefully).

It might be best to review this PR commit-wise.

edit:

These functions also handle OOM correctly; in Phobos, there are more examples of incorrect handling of OOM, like trying to dynamically allocate an exception, either directly or through enforce, rather than use onOutOfMemoryError.

[JakobOvrum]

I'm aware of the test failures and I'll fix them as soon as I can.

[JakobOvrum]

Test success depends on #3032.

[WalterBright]

How does test coverage look?

dmd std/internal/mmm -unittest -main -cov

[JakobOvrum]

How does test coverage look?

I used DMD's coverage analysis when writing the tests. IIRC all paths are tested except the OOM paths. I'll confirm when all the dependencies are figured out.

[JakobOvrum]

This passes now, finally. Review would be appreciated.

I want to patch unique and RefCounted to use this, but I don't know if I should put the commits in this PR or a new one that depends on this...

[MartinNowak]

You should have a utility function for this, destroyArrayReverse or so.

[DmitryOlshansky]

+1

[MartinNowak]

Looks great

[DmitryOlshansky]

Would be awesome to address minor comments and move this in

[schveiguy]

I have no skin in this game, but is there a better name we can use instead of mmm? That just doesn't seem right :)

[JakobOvrum]

Updated:

• tabs -> spaces
• Added destroyArray utility function and changed schwartzSort to use it
• Added some more tests
• Added documentation (but the module is still internal)

Passes the autotester again now.

[DmitryOlshansky]

Maybe we should make destroy array deallocate the array itself, keeping in mind the use cases in schwartzSort.

[JakobOvrum]

Maybe we should make destroy array deallocate the array itself, keeping in mind the use cases in schwartzSort.

Destruction and deallocation need to be separate so that the caller can manually vet the memory safety of the deallocation with @trusted, while leaving the memory safety of destruction to attribute inference.

[andralex]

I usually try to stay away from trivial matters, but mmm is quite out there. Where does it even come from?

[JakobOvrum]

For posterity, it was meant to be "Manual Memory Management". It's an internal module so I didn't put much thought into it

[andralex]

I think this needs to be redone as a layer working with std.experimental.allocator. Then the functionality in these functions is immediate to achieve by using Mallocator.

[JakobOvrum]

If I'm not mistaken, the two interesting/useful functions in this are essentially the same as make and makeArray from std.alloactor, except hardcoded to use malloc. So we should definitely make this work with std.allocator instead.

[JakobOvrum]

I see that make returns null on failure. In the example use cases from this PR, there is nothing that can be done on OOM except throw OutOfMemoryError, and you'd think this is fairly common in both libraries and applications when used with something like malloc. So maybe this use case should be reflected in std.allocator.package; a kind of makeOrFail wrapper function. It's orthogonal to memory safety but I mention it since it was part of this PR.