Previous commit caused this error to be printed:
zig build-exe zig Debug aarch64-macos-none: error: memory usage peaked
at 6323765248 bytes, exceeding the declared upper bound of 5200000000
I observed some out-of-memory conditions happening on one of the CI
servers. This should make it avoid scheduling compiler builds at the
same time as other memory-intensive operations.
Currently, Zig uses the oldest Debian release that is still under LTS
for the default version minimum. This is now Debian 10 (Buster), with
long-term support until 2024-06-30.
Debian Buster uses Linux 4.19 and glibc 2.28.
For the default version maximum, Zig uses the newest stable Linux
version, which is currently 6.5.7.
Citations:
* https://www.debian.org/News/2019/20190706
* https://packages.debian.org/source/buster/glibc
* https://kernel.org/
Previous update commit: 1530203c804db7e5abd7d6eac05cfbe449d30aea
This reverts commit 78855bd21866b515018259a2194e036e4b3120df.
This commit did not replace uses of `Type.err_int` of which there are
currently 60 uses.
Re-opens #786
* support 0x prefixed hex code for CLI seed arguments
* don't change the build summary; the printed CLI on build runner
failure is sufficient
* use `std.crypto.random` instead of system time for entropy
This reverts commit d7b73af8f65bb891c8700ed47777144bb6f35fe1.
I did not look at this closely enough. This is incorrect; it should not
implicitly add rpaths for every library, and it should not disable the
nice default of each_lib_path when compiling for the native OS.
See #16062 where we are working on a follow-up improvement to this.
The INCLUDE variable being used during `.rc` preprocessing was an accidental regression in https://github.com/ziglang/zig/pull/17412.
Closes#17585.
resinator changes:
source_mapping: Protect against NUL bytes in #line filenames
lex: Avoid recalculating column on every tab stop within string literals
Proper error handling for failing to open cwd instead of `catch unreachable`
Use platform-specific delimiter for INCLUDE env var parsing
Before this commit, the logic would fail with a "LTO not available"
error if the user set `-fno-lto` which doesn't make sense. This commit
corrects the logic to understand when the user is explicitly requesting
to turn LTO off.
This script is sometimes timing out, so let's test fewer things to save
time. The x86_64-windows-release script does include test coverage for
release builds of the standard library, behavior tests, etc.
