Now instead of zig.h being baked into the compiler binary, it is a
header file distributed along with all the other header files
distributed with Zig.
Closes#11643
This causes a stack overflow in a debug build of stage3 unfortunately. I
will open an issue to track this test coverage, which we absolutely
should get working - users of the compiler should get a compile error,
not a segfault if they hit the default branch quota from abusing
recursive inline functions.
Note that the problem does not occur in a release build of stage3
which has significantly reduced stack usage.
On Linux, I tried bumping up the stack size from 32 MiB to 64 MiB and it
did not solve the problem. I'm not sure why not. It seems like it should
be fine.
Note that we also have a problem of running test-cases in multi-threaded
mode which is currently the default. Currently Zig threads are spawned
with 16 MiB stack space.
This makes it so that in a -Dsingle-threaded build of test-cases, if a
crash happens, the test case name will be printed just before the stderr
of the crash.
* proper skip_stage1 mechanism that doesn't get side-stepped with
manually added test cases.
* avoid runtime-known function pointers.
* check for type equality more simply without checking the type name.
At least on Linux, the pwritev syscall checks the pointer and returns
EFAULT before it checks if the length is nonzero.
Perhaps this should be fixed in the standard library, however, these are
still improvements since they make the kernel do less work within the
syscall.
On some systems (esp. systems that use unique hashed file-paths for
library-versions like Nix), we can't expect LLVM and Clang to share
lib/bin directories.
The best we can do is find the matching clang libraries in the
CMAKE_LIBRARY_PATH provided by the environment
`getdents` on Linux can return `ENOENT` if the directory referred to by the fd is deleted during iteration. Returning null when this happens makes sense because:
- `ENOENT` is specific to the Linux implementation of `getdents`
- On other platforms like FreeBSD, `getdents` returns `0` in this scenario, which is functionally equivalent to the `.NOENT => return null` handling on Linux
- In all the usage sites of `Iterator.next` throughout the standard library, translating `ENOENT` returned from `next` as null was the best way to handle it, so the use-case for handling the exact `ENOENT` scenario specifically may not exist to a relevant extent
Previously, ENOENT being returned would trigger `os.unexpectedErrno`.
Closes#12211
