- walk the stack via the method that is aware of unwind info (fixes x86_64 / aarch64 traces)
- enhance the output for frames where the debug info isn't available by printing the module name
DELETE_PENDING can happen when the file is yet to be closed for deletion
or if it never get closed. In that case, DeleteFile should assume the
file deletion is succeeding (no CloseHandle is required as it's a "failure"). In case of `DELETE_PENDING` failure, the file
may still exist. In which case if it's part of `deleteTree`, it will
eventually fail on `error.DirNotEmpty`.
This fixes `.INVAL => unreachable` being triggered by the cache system
on macOS when multiple processes race to create the same compilation.
The problem is that when two processes race to create a file, it
sometimes returns ENOENT even though that error code is nonsensical for
this situation.
Commit 2b0929929d67e222ca6a9523a3a594ed456c4a51 purportedly solved this,
but it did not open the file with write permissions, leading to the
EINVAL panic later on. This commit remedies the situation by introducing
a loop and simply retrying when the ENOENT occurs.
Deleting a read-only file should result in `AccessDenied` (`CANNOT_DELETE`).
Note: This test was observed to fail when the file is closed then reopened
before the change in permission due to the absence of
`FILE_WRITE_ATTRIBUTES` when re-opened. (see #15316).
to avoid getting OOM killed. It's been happening regularly recently. We
need to have a high number of GitHub Actions runners simultaneously
active, otherwise the hardware ends up underutilized. But with zig build
running in parallel now, this sometimes results in memory usage spikes
that have been causing the runner to get killed.
This number is the total physical memory (126G) divided by the number of
runners we have active (6).
This reverts commit a34752c941c81e600c56670abb612fc86d0a2b73.
With #15277 merged, the macOS CI will still run the self-hosted x86_64
tests even with -Dskip-non-native. This was the main motivation for the
commit.
It would be nice to keep this flag enabled, however, we don't have
enough CI computing power, and the macOS CI lags behind with these extra
tests enabled.
Following @Luukdegram's comment[1]:
> The default should remain Debug when unspecified. In ReleaseSmall the
> user would lose all DWARF support when testing their WebAssembly code.
> Building a release version should be opt-in, not the default.
[1]: https://github.com/ziglang/zig/pull/15192#discussion_r1160824726
I find myself quite often creating ReleaseSafe builds and putting them
to production for certain experiments:
- Debug info are for stack traces. An ongoing example where those would
help is #14815.
- Safety checks would have saved a couple of mine and @kubkon's hours in
#15098.
This is a breaking change for scripts that make Zig releases -- I will
submit another PR to zig-bootstrap and release-cutter after this is
merged.
Using `FILE_DELETE_ON_CLOSE` can silently succeed without reporting any error
on non-empty directory. This commit adds usage of NtSetInformationFile
which will report `DIRECTORY_NOT_EMPTY`.
The CI now runs C backend tests in addition to compiling them. It uses
-std=c99 -pedantic -Werror in order to catch non-conformant C code.
This necessitated disabling a test case that caused a C compile error,
in addition to disabling a handful of warnings that are already being
triggered by Zig's C backend output for the behavior tests.
The upshot is that I was able to, very cleanly, integrate the C backend
tests into the build system, so that it communicates via the test runner
protocol along with all the other behavior tests.
Make the test targets use options that match the actual options of
CompileStep. This makes the code more straightforward, and ends up
making fewer tests incorrectly skipped. For example, now the CI runner
on Windows will no longer skip self-hosted x86_64 backend tests.
