Zig Refactors Build Architecture, Shifting Package Management to Build System and Revamping SPIR-V Backend

Zig has decoupled package management from the compiler executable, transferring networking, crypto, and parsing logic directly to the build system's maker process. Concurrently, the compiler has overhauled its SPIR-V backend with multi-threaded codegen and corrected integer memory lowering in its LLVM backend.

Decoupling Package Management from the Compiler Core

In a significant architectural shift, Zig has relocated all package management functionality out of the compiler binary and into the build system's `maker` process. The subcommands `zig build`, `zig fetch`, `zig init`, and `zig libc` now run inside the `maker` process.

• The HTTP client, networking logic, TLS, and cryptographic primitives.
• The Git protocol implementation.
• Archive parsing and validation engines for xz, gzip, zstd, flate, and zip.
• Parser and validation logic for `build.zig.zon` files.

This change reduces the `ReleaseSmall` (no LLVM) compiler binary size by 4%, shrinking it from 14.1 MiB to 13.5 MiB.

Because these tools are compiled in `ReleaseSafe` mode as part of the `maker` executable, package fetching now executes with active safety checks. Cryptographic and hashing operations can also utilize host-specific CPU instructions that are typically too rare to target in widely distributed pre-compiled compiler binaries. Furthermore, users and contributors can now patch package management behavior directly in source form without needing to rebuild the compiler.

Process Architecture and Watch Mode Optimizations

The reallocation of package management solves a fundamental process lifecycle issue in long-running watch processes (`zig build --watch`).

• `zig build` (compiler + package manager) spawned `configurer` (user's `build.zig` logic) and `maker` (the build system) as sibling processes.

Under that model, if a user modified `build.zig`, the `configurer` process had to rerun. Because the package manager lived in the parent compiler process, the `maker` process had to exit entirely to let the parent handle package resolution again.

• `zig build` (compiler) spawns `maker` (build system + package manager), which then spawns `configurer` (user's `build.zig` logic).

Because `maker` is now the direct parent of `configurer`, it remains alive across modifications to the build script. When configuration changes are detected, `maker` simply spawns a new `configurer` instance. This persistent process model prevents the need to teardown the build runner and enables a clean build server protocol implementation, unblocking work on the Zig Language Server (ZLS).

This change replaces the `--maker-opt` flag with the `ZIG_DEBUG_MAKER` environment variable, and the `--zig-lib-dir` flag with `ZIG_LIB_DIR`.

SPIR-V Backend Modernization

The SPIR-V compiler backend has undergone a major rewrite to fix bitrot and align its capabilities with other self-hosted targets.

To represent graphics pipeline types that cannot be native to Zig, the compiler introduces the `@SpirvType` builtin. This enables developers to declare structures like samplers, images, and runtime arrays directly:

```zig const Sampler = @SpirvType(.sampler); const Image = @SpirvType(.{ .image = .{ .usage = .{ .sampled = u32 }, .format = .unknown, .dim = .@"2d" } }); ```

Execution modes, such as workgroup size and fragment origin, are now carried directly via target calling conventions (e.g., `spirv_task` and `spirv_mesh`) rather than using manual `OpExecutionMode` inline assembly. Inline emission of capabilities and extensions has also been banned; the compiler assembler now rejects direct `OpCapability` and `OpExtension` instructions, deriving them instead from target CPU features extracted from SPIRV-Headers.

For code generation, the SPIR-V backend no longer runs single-threaded in the linker thread. It now outputs Mir values and schedules codegen jobs onto the compiler’s thread pool. This change restores the `dedup_types` and `prune_unused` instruction selection passes. Additionally, the compiler now treats `.spv` files as object files, allowing the SPIR-V linker to stitch multiple SPIR-V modules together. These updates have increased the passing rate on `spirv64-vulkan` behavior tests to 49%.

LLVM Integer Lowering and `@bitCast` Semantics

The LLVM backend has changed how it handles arbitrary bit-width integers such as `u4`, `i13`, or `u40`.

Historically, Zig lowered these types directly to LLVM IR's arbitrary-width integer types (like `i4` or `i13`). Because Clang does not emit this style of IR, these codepaths are poorly tested inside LLVM, frequently causing optimization failures and miscompilations.

The updated LLVM backend limits the use of arbitrary-width integers to values in SSA (Static Single Assignment) form. When storing these values to memory, the backend now zero- or sign-extends them to ABI-sized types (`i8`, `i16`, `i32`, etc.), matching how Clang lowers C's `_BitInt(N)`.

This change prompted a redesign of `@bitCast`. The builtin was historically defined as a memory-pointer reinterpret cast, which caused undefined behavior when casting between types of differing memory sizes, such as casting `[3]u8` to `u24` on platforms where `@sizeOf(u24)` is 4 bytes. The backend is being updated to align `@bitCast` with stricter, well-specified value-level casting semantics.