breaking changes to std.mem.Allocator interface API

Before, allocator implementations had to provide `allocFn`,
`reallocFn`, and `freeFn`.

Now, they must provide only `reallocFn` and `shrinkFn`.
Reallocating from a zero length slice is allocation, and
shrinking to a zero length slice is freeing.

When the new memory size is less than or equal to the
previous allocation size, `reallocFn` now has the option
to return `error.OutOfMemory` to indicate that the allocator
would not be able to take advantage of the new size.

For more details see #1306. This commit closes #1306.

This commit paves the way to solving #2009.

This commit also introduces a memory leak to all coroutines.
There is an issue where a coroutine calls the function and it
frees its own stack frame, but then the return value of `shrinkFn`
is a slice, which is implemented as an sret struct. Writing to
the return pointer causes invalid memory write. We could work
around it by having a global helper function which has a void
return type and calling that instead. But instead this hack will
suffice until I rework coroutines to be non-allocating. Basically
coroutines are not supported right now until they are reworked as
in #1194.

1 files changed, 1 insertions, 1 deletions

diff --git a/std/debug.zig b/std/debug.zig
index df35a8e773..b666e816af 100644
--- a/std/debug.zig
+++ b/std/debug.zig
@@ -1072,7 +1072,7 @@ fn openSelfDebugInfoMacOs(allocator: *mem.Allocator) !DebugInfo {
         .n_value = symbols_buf[symbol_index - 1].nlist.n_value + last_len,
     };
 
-    const symbols = allocator.shrink(MachoSymbol, symbols_buf, symbol_index);
+    const symbols = allocator.shrink(symbols_buf, symbol_index);
 
     // Even though lld emits symbols in ascending order, this debug code
     // should work for programs linked in any valid way.