Update to Zig 0.16.0

[vancluever]

Closes #12228
Supersedes #12388

This commit represents the majority of the work necessary to upgrade Ghostty to use Zig 0.16.0.

At this point, all tests pass under Linux, but more work may be necessary to get them to build and function on other platforms.

There are some parts of this update that deserve commentary, so that follows below:

Use of std.Io.Threaded.global_single_threaded

All stdlib interactions that now require an I/O implementation due to the update of stdlib to 0.16.0 have had std.Io.Threaded.global_single_threaded passed in as their I/O implementation. This is just a static local instance of the single-threaded I/O implementation, so it saves us having to have .init_single_threaded everywhere.

This ultimately allows us to implement more complex and up-to-date I/O patterns piecemeal outside of the larger upgrade work.

There are a couple of uses of std.process.spawn that need to use Io.Threaded implementations directly (via .init). This is because .spawn requires an allocator to create args, and the single-threaded implementation, by default, assigns a failing allocator.

The lib/compat Tree

Several stdlib features that have been removed but still either seem they would be valuable to us or outright complex to move away from (particularly SegmentedList) have been extracted from 0.15.2, updated as needed, and placed in src/lib/compat. The intention again is to allow for piecemeal migration to more modern implementations or possibly straight local versions.

This paradigm has also allowed us to add std.Io.Condition.waitTimeout, which incidentally was missed in the 0.16.0 shuffle and has been re-added for 0.17.0. We can remove this in favor of the upstream when we eventually migrate to that, obviously.

Static local args and environment storage

Additionally, contained within the lib/compat tree is static local storage for std.process.Args and os_environ instances, along with any code we needed to work with these extracted. These are set on most entry points in various ways, but usually through lib/compat/init.zig.run.

Various parts of code in lib/compat shim most of our interaction with the environment and work off of the aforementioned static local variables.

translate-c Issues (functional on Linux, Darwin WIP)

UPDATE: Most of this is outdated, check progress below!

The biggest blocker to getting this fully built and functional right now seems to be was issues with Zig's migration to arocc for translate-c functionality. This is part of the transition to a standalone and LLVM-free translate-c (slated for 0.17.0, it seems, or at least that's when cImport is going away completely). Unfortunately, there have been issues with arocc's handling of GTK headers, see https://codeberg.org/ziglang/translate-c/issues/328 and Vexu/arocc#996. These had apparently been fixed, but it appears some issues still persist with use of translate-c for GTK, namely with #define handling:

/nix/store/18pf97n05kijiks2sznpcmm0856z7ijl-gtk4-4.20.3-dev/include/gtk-4.0/gdk/version/gdkversionmacros.h:19:2: error: \"Only <gdk/gdk.h> can be included directly.\" #error "Only <gdk/gdk.h> can be included directly."

This happens on the latest translate-c and arocc (on Zig master).

I am planning on looking into this further to see if we can move this along - namely, looking into what's causing this lingering issue in arocc/translate-c.

To fix this in some parts of apprt/gtk that only required access to version information from the GTK/libadwaita headers, I have just added some modules that build version data from call-outs to pkg-config. I'm not too sure if the rest of the code could be shimmed out a similar way, but it seems there are at least two places that it may be more complex to or not feasible:

• gtk4-layer-shell bits (pkg/gtk4-layer-shell)
• The generated ghostty_resources.h file (references gio/gio.h which contain similar #define statements in nested files).

---

That's about it for now. I'm still working on this; there's a number of things that still need updating otherwise due to the build failing due to the translate-c issues, but I wanted to get this work up so that folks new there was significant progress made. More updates when I have them - feel free to leave feedback on any of the work already done!

[jacobsandlund]

uucode related changes look good!

[vancluever]

Vexu/arocc#1010 has been opened to address the previously mentioned arocc issue.

There now seems to be an issue with the translated Zig artifact. Will work on tracking this down next:

generated.zig:6603:194: error: expected ';' after statement
        if (__builtin.constant_p(!(@as(c_int, 0) != 0)) != 0) if (!(@as(c_int, 0) != 0)) _ = g_string_free(string, @intFromBool(!(@as(c_int, 0) != 0))) else _ = g_string_free_and_steal(string) else _ = g_string_free(string, @intFromBool(!(@as(c_int, 0) != 0)));

[vancluever]

Opened a couple of translate-c issues:

• https://codeberg.org/ziglang/translate-c/pulls/386 - fixes some suppression issues that was keeping translation from happening properly
• https://codeberg.org/ziglang/translate-c/pulls/388 - ensures that the Zig libc headers are used regardless of platform (looks like Aro still lacks a decent amount of coverage, even on Linux).

These two changes along with the Aro update seem to have unblocked us and I can proceed with fixing the full build again. 🙂 🤞

[vancluever]

I'm now happy to say that the project builds, tests, and runs under Linux!

The pkg-config bits that we were using to work around the translate-c issues have been moved back to translate-c since the previously mentioned fixes unblock us there.

Nothing particularly notable otherwise to mention (Vexu/arocc#1010 has been merged though!). I'm not going to say that there aren't any upgrade-related regressions yet, although I'm not aware of any, and I'm planning on driving this soon to check. My focus now will be moving to Darwin (testing/building on MacOS). There are also some issues with the translate-c fixes on Darwin and other platforms, so these need to be corrected too.