Find a file
Cody Tapscott d060cbbec7 stage2: Keep error return traces alive when storing to const
This change extends the "lifetime" of the error return trace associated
with an error to continue throughout the block of a `const` variable
that it is assigned to.

This is necessary to support patterns like this one in test_runner.zig:
```zig
const result = foo();
if (result) |_| {
    // ... success logic
} else |err| {
    // `foo()` should be included in the error trace here
    return error.TestFailed;
}
```

To make this happen, the majority of the error return trace popping logic
needed to move into Sema, since `const x = foo();` cannot be examined
syntactically to determine whether it modifies the error return trace. We
also have to make sure not to delete pertinent block information before it
makes it to Sema, so that Sema can pop/restore around blocks correctly.

* Why do this only for `const` and not `var`? *

There is room to relax things for `var`, but only a little bit. We could
do the same thing we do for const and keep the error trace alive for the
remainder of the block where the *assignment* happens. Any wider scope
would violate the stack discipline for traces, so it's not viable.

In the end, I decided the most consistent behavior for the user is just
to kill all error return traces assigned to a mutable `var`.
2022-10-21 12:40:29 -07:00
.builds CI: update sourcehut oauth token 2022-09-21 20:34:17 -07:00
.github codeowners: mark myself as the codeowner of /src/autodoc/ 2022-09-02 17:35:41 +02:00
ci ci: make directory structure in releases consistent 2022-10-21 12:51:04 -04:00
cmake build: avoid compiling self-hosted twice 2022-10-18 16:52:43 -07:00
deps stage2: Fix softfloat support for PPC64(LE) 2022-10-13 12:53:20 -07:00
doc all: rename @maximum to @max and @minimum to @min 2022-10-18 14:15:16 +03:00
lib stage2: Keep error return traces alive when storing to const 2022-10-21 12:40:29 -07:00
src stage2: Keep error return traces alive when storing to const 2022-10-21 12:40:29 -07:00
test stage2: Keep error return traces alive when storing to const 2022-10-21 12:40:29 -07:00
tools add m68k target CPU features 2022-10-20 09:21:06 -07:00
.gitattributes mark tsan as linguist-vendored 2021-06-25 12:46:23 +03:00
.gitignore std/build: change default install prefix to zig-out 2021-04-29 23:58:45 +02:00
build.zig build: avoid compiling self-hosted twice 2022-10-18 16:52:43 -07:00
CMakeLists.txt build: avoid compiling self-hosted twice 2022-10-18 16:52:43 -07:00
LICENSE Y++ 2021-12-31 19:58:21 -05:00
README.md move some files to the .github directory 2022-03-24 12:22:23 -07:00

ZIG

A general-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.

Resources

Installation

License

The ultimate goal of the Zig project is to serve users. As a first-order effect, this means users of the compiler, helping programmers to write better software. Even more important, however, are the end-users.

Zig is intended to be used to help end-users accomplish their goals. Zig should be used to empower end-users, never to exploit them financially, or to limit their freedom to interact with hardware or software in any way.

However, such problems are best solved with social norms, not with software licenses. Any attempt to complicate the software license of Zig would risk compromising the value Zig provides.

Therefore, Zig is available under the MIT (Expat) License, and comes with a humble request: use it to make software better serve the needs of end-users.

This project redistributes code from other projects, some of which have other licenses besides MIT. Such licenses are generally similar to the MIT license for practical purposes. See the subdirectories and files inside lib/ for more details.