diff options
| author | Ryan Liptak <squeek502@hotmail.com> | 2022-06-23 17:20:24 -0700 |
|---|---|---|
| committer | Ryan Liptak <squeek502@hotmail.com> | 2022-06-23 17:20:24 -0700 |
| commit | c321b2f2a0257fa45262f1ece0a263b22e8c70f3 (patch) | |
| tree | cf0a1ada1de0b1cf7a3d4a69f784f052c33d3ef2 /src/stage1/codegen.cpp | |
| parent | def304a9a5b9d001e37c19509a9d2b2450088033 (diff) | |
| download | zig-c321b2f2a0257fa45262f1ece0a263b22e8c70f3.tar.gz zig-c321b2f2a0257fa45262f1ece0a263b22e8c70f3.zip | |
checkAllAllocationFailures: add possibility of SwallowedOutOfMemoryError (split from NondeterministicMemoryUsage)
Inducing failure but not getting OutOfMemory back is not as much of a problem as never inducing failure when it was expected to be induced, so treating them differently and allowing them to be handled differently by the caller is useful.
For example, the current implementation of `std.HashMapUnmanaged.getOrPutContextAdapted` always tries to grow and then recovers from OutOfMemory by attempting a lookup of an existing key. If this function is used (i.e. from `std.BufMap.putMove`) with `checkAllAllocationFailures`, then we'd have previously triggered `error.NondeterministicMemoryUsage`, but the real cause is that `OutOfMemory` is being recovered from and so the error is being swallowed. The new error allows us to both understand what's happening easier and to catch it and ignore it if we're okay with the code we're testing handling `error.OutOfMemory` without always bubbling it up.
Diffstat (limited to 'src/stage1/codegen.cpp')
0 files changed, 0 insertions, 0 deletions
