IIUC, Zig’s semantics are operational in nature and most probably not going to change in the coming future. I have no problem with that as the procedural, stateful nature of comptime has opened up lots of use cases. An intriguing consequence of that, however, is the creation of a declarative, “shadow” language when Zig is AST-grounded. To put it simply, think of either type and (unknown type) in ZLS, which aren’t a thing in Zig, because nodes in a compilation graph aren’t necessarily bijective to the AST nodes. Another major architectural difference between a compiler and a language server is, the latter can’t always evaluate code in totality because of the DX-destroying halting problem. So I wonder if the compiler daemon in the future is also designed for the lazy, query-driven, polymorphic view that a language server requires by nature?
I don’t know if the end goal is query driven, or if it has even been planned that far.
The current state of the protocol is feature parity with the CLI (+a little extra), which now includes the information that ZLS previously had to inject a custom build runner to obtain. So the next release isn’t going to have any visible improvements, aside from internal build API changes not breaking ZLS.
I would bet (don’t quote me on this) the query driven API starts and ends with “compile with X configuration” so that the compile server doesn’t need to maintain state that is only applicable to 3rd party tools. If those tools, like ZLS, are query driven then they can maintain the necessary states themselves.
It would be really cool if the API evolved in that sense, recently I wanted to make a little tool for zig, that uses the std.zig namespace, AST etc, to recursively parse zig, and generate a call graph and export it as a dot file, and was frustrated, because currently there’s no way to get back the full with comptime output it seems (or at least I haven’t find it). And if there was a way to querry the compiler about what will be the zig code, after everything is evaluated, that would be really nice.
So ZLS is no longer blocked? I was under the impression that it still is blocked. And since there is only one open issue left in 0.17.0, it seemed to me like 0.17 might release with ZLS still blocked and that I might skip a zig release.
Much of the very base build protocol is implemented, but it has plenty of outstanding issues which may not be in the 0.17 release. I think it might be unblocked, but its not clear.
At the very least, its close enough that I expect zls to be unblocked before 0.17, Andrew is explicitly asking if relevant issues are a blocker for zls when deciding to postpone them.
In particular, the separation of maker process and configurer process is a breaking change that prevents the ZLS project from working with 0.17.0.
alas, no ZLS for 0.17 
Aside, the following implies we still have a curious question for how the future compiler may tackle the non-bijection between the compilation graph and the AST.
It is also planned for the build server to multiplex compiler server protocol for the compilation steps, providing type-system information, refactoring, and other advanced editing capabilities (#615).
What’s confusing to me is that I was following master and the ZLS has been working mostly fine even after the maker split. Does anyone know why that might be and if that “mostly fine” will still happen for the official 0.17 tag?
edit: yeah, just checked and ZLS from master still “works” for the most part, but obviously isn’t fully functional.
ZLS should be able to be mostly functional, it just needs to be updated.
The main dev happens to be the same person who did most of the build protocol work that did get into this release so it shouldn’t take too long.
The second statement is about more advanced stuff that would allow ZLS to inspect actual comptime instead of guessing with its limited, bespoke interpreter.
AST stuff is tangential to the build/compiler protocols, LSPs just read the source files.