diff options
| author | Cody Tapscott <topolarity@tapscott.me> | 2022-09-13 15:31:07 -0700 |
|---|---|---|
| committer | Cody Tapscott <topolarity@tapscott.me> | 2022-10-21 10:44:20 -0700 |
| commit | 3007fdde45868142654d0bfa59bc0e17e5f24a1c (patch) | |
| tree | 94611e7212e5050491e72204f7a231cfbfe9a71e /src/codegen/c.zig | |
| parent | 0c3a50fe1c1370c975d7de1f2f00458b4a3ec299 (diff) | |
| download | zig-3007fdde45868142654d0bfa59bc0e17e5f24a1c.tar.gz zig-3007fdde45868142654d0bfa59bc0e17e5f24a1c.zip | |
stage2: Pop error trace when storing error to var/const
In order to enforce a strict stack discipline for error return traces,
we cannot track error return traces that are stored in variables:
```zig
const x = errorable(); // errorable()'s error return trace is killed here
// v-- error trace starts here instead
return x catch error.UnknownError;
```
In order to propagate error return traces, function calls need to be passed
directly to an error-handling expression (`if`, `catch`, `try` or `return`):
```zig
// When passed directly to `catch`, the return trace is propagated
return errorable() catch error.UnknownError;
// Using a break also works
return blk: {
// code here
break :blk errorable();
} catch error.UnknownError;
```
Why do we need this restriction? Without it, multiple errors can co-exist
with their own error traces. Handling that situation correctly means either:
a. Dynamically allocating trace memory and tracking lifetimes, OR
b. Allowing the production of one error to interfere with the trace of another
(which is the current status quo)
This is piece (3/3) of https://github.com/ziglang/zig/issues/1923#issuecomment-1218495574
Diffstat (limited to 'src/codegen/c.zig')
0 files changed, 0 insertions, 0 deletions
