This makes all commands in the zig executable that support color
output respect the user's preference for color output based on the
NO_COLOR and CLICOLOR_FORCE environment variables. Setting color
preference via command line option still overrides preferences set via
environment variables.
Previously, if the same inline function was called multiple times
by the same caller, the inline function's frame would be repeated
multiple times, once for each prior call.
makes the build system compile on 32 bit systems
bonus, also fix incorrectly passing advanced debug options to the maker
process which doesn't care about them
On 32-bit systems usize is not u64 but it was assumed in multiple places
of the build script.
Sometimes using u64 instead of usize since available and used memory can
exceed usize on 32-bit systems (just like totalSystemMemory)
Example errors:
lib/compiler/build_runner.zig:508:26: error: expected type 'usize', found 'u64'
.available_rss = max_rss,
^~~~~~~
lib/compiler/build_runner.zig:508:26: note: unsigned 32-bit int cannot represent all possible unsigned 64-bit values
referenced by:
callMain [inlined]: lib/std/start.zig:699:88
callMainWithArgs [inlined]: lib/std/start.zig:638:20
posixCallMainAndExit: lib/std/start.zig:590:38
2 reference(s) hidden; use '-freference-trace=5' to see all references
lib/std/Build/WebServer.zig:849:38: error: expected type 'usize', found 'u64'
const buf = gpa.realloc(old_buf, new_len) catch @panic("out of memory");
^~~~~~~
lib/std/Build/WebServer.zig:849:38: note: unsigned 32-bit int cannot represent all possible unsigned 64-bit values
lib/std/mem/Allocator.zig:399:58: note: parameter type declared here
pub fn realloc(self: Allocator, old_mem: anytype, new_n: usize) Error!@TypeOf(old_mem) {
^~~~~
build.zig:548:10: error: type 'usize' cannot represent integer value '9300000000'
.max_rss = 9_300_000_000,
~^~~~~~~~~~~~~~~~~~~~~~~
build.zig:778:10: error: type 'usize' cannot represent integer value '8000000000'
.max_rss = 8_000_000_000,
~^~~~~~~~~~~~~~~~~~~~~~~
There is no concept of a "build runner" any more; it has been split in two:
configurer and maker.
Users of this feature will likely want to no longer override any logic, and
instead consume the configuration file produced by configurer.
If overriding one or the other of these is desired, the feature will need to be
re-introduced (as --override-maker or --override-configurer).
This is intended to replace the common pattern:
print("invalid foobar: '{s}': {t}", ...)
The idea is to not invent imaginary syntax. If the string contained
single quotes for example, this would be a nonsensical error message.
On the other hand with the new pattern:
print("invalid foobar: {q}: {t}", ...)
It's both easier on the eyes at the print site, and also it will allow
the user to copy paste a properly escaped string, should the quoted text
contain any odd characters, including invisible ones like null bytes.
Not sure what I was thinking. This is silly, translate-c package simply
needs to pass this data (link_libc and target) to the CLI application,
which can then do the appropriate behavior.
Siddharth Sinha