zig --help -> ok
zig --help --c-source -> ok
zig --c-source --help -> crash [fixed]
'i' was being incremented without regard for the 'argc' limit, so
we were running off the end of 'argv'.
The code creates temporary ConstExprValue with global_refs set to
nullptr and that's carried over to the final value. Doing so prevents
the deduplication mechanism to work correctly, causing all sorts of
runtime crashes.
Fixes#1636Fixes#1608 (Even though it was already fixed by #1991)
Previously, `zig fmt` on the stage1 compiler (which is what we currently
ship) would perform what equates to `zig run std/special/fmt_runner.zig`
Now, `zig fmt` is implemented with the hybrid zig/C++ strategy outlined
by #1964.
This means Zig no longer has to ship some of the stage2 .zig files, and
there is no longer a delay when running `zig fmt` for the first time.
After 4df2f3d74f test names have the word "test" in them so the
redundant word is removed from test runner. Also move the prefix/suffix
to where it logically belongs in the fully qualified symbol name.
Tests now have the symbol name of the format `test "<name>"` in order
to be more easily distinguished from functions with similar names.
See issue #2267.
Previously the memory would be copied to a different aligned address in some cases where the old offset could have been used. This fixes it so that it will always try to use the old offset when possible, and only uses a different offset if the old one is truly invalid (not aligned or not enough space to store the alloc at the old offset).
This defines `@sizeOf` to be the runtime size of a type, which means
that it is zero for types such as comptime_int, type, and (enum
literal).
See #2209
On macOS building with Xcode/clang the linker complains loudly when
symbol visibility is inconsistent. This option syncs visibilty setting
of both LLVM and Zig.
Previously libuserland was being built for the native target,
which could depend on native CPU features such as AVX. The
CI infrastructure is intending to create binaries that are
widely compatible and do not make use of specific CPU features.
There could be something to gain from enabling native CPU features
sometimes, by introducing a new cmake configuration option, but
since it's planned to eventually ship self-hosted rather than stage1,
I don't think it really matters.
closes#2348