Zig 0.17.0 Ships Incremental Builds on Linux and Breaks ZLS Until Its Own Release Lands

Zig 0.17.0 shipped on October 2 with a rebuilt zig build and incremental compilation for x86_64-linux, but the build change breaks ZLS, the language server most Zig editors use, until a matching ZLS release lands.

The Zig Software Foundation's release notes put the cycle at 5 months, 206 contributors and 925 commits. The announcement page itself is a landing page that links to those notes and the downloads.

The editor gap

The notes say outright that the new split between a configurer process and a maker process "is a breaking change that prevents the ZLS project from working with 0.17.0". The Zig and ZLS teams are working together on the build server protocol, and some progress was made during the cycle.

On the ZLS side, the project's GitHub shows a pull request titled "update to Zig 0.17.0" (#3269) merged on October 3, and one titled "release ZLS 0.17.0" (#3267) still open from October 2. Whether the merged update restores build-file support is not something either page says.

For anyone upgrading today, the practical result is that the compiler is ready and the editor integration is not. That is the ZLS gap, and it is the first thing to check before bumping a project.

What changed in zig build

zig build now runs a project's build.zig in a separate executable from the one that handles package management and executes the build graph. The notes give three reasons it is faster: the maker executable is built once after install, it is built with optimizations on, and build.zig logic can sometimes be skipped depending on the flags.

Passing --listen=- makes the build system serve a protocol that lets IDEs read the build graph and request steps. The cache also moved to a binary format that, per the notes, saves roughly 25% of file size and gives a 5% to 10% speedup on cache hits.

Incremental compilation is the other headline. The notes say most projects targeting x86_64-linux can now run zig build -fincremental --watch and get near-instant rebuilds. They give no timings.

Breaking changes to budget for

Change	What to do
@cImport removed	Depend on the ZSF translate-c package and use Translator in build.zig
a ** b array multiplication removed	Use @splat, for example @splat(0)
@bitCast on extern struct or extern union disallowed	Use @ptrCast or an extern union

The notes also list @intFromEnum and @enumFromInt as replaced by @backingInt and @fromBackingInt, and @hasDecl now returns true only for public declarations. std.Build.Step.TranslateC is deprecated in favor of the external package, which has its own release cadence.

The C-translation move is the one that costs a build file edit rather than a find and replace. @cImport was deprecated in 0.16.0, so projects that ignored that warning now owe the whole migration at once.

Known problems and the toolchain

The release ships on LLVM 22.1.8. The notes say loop vectorization stays disabled: a fix for the LLVM miscompilation that forced the workaround has merged in LLVM's main branch but is not in LLVM 22.

The notes' own list of regressions includes a compiler-rt soft-float compile failure on x86, a std.debug.simple_panic compile failure, and the maker and configurer split breaking response file handling. SPIR-V backend regressions are also listed.

The date to watch is the ZLS 0.17.0 release, whose pull request was still open on October 3 and which neither project has given a date. For another toolchain release with a migration bill, see our coverage of Rust 1.99.0, and for a storage-format change weighed on cost, Git 3.0's SHA-256 default.