I believe it should be LICENCE -> LICENSE :)

Something that occurred to me after the multi-object-for change — Have you considered how the embedded ast-check would handle codebases meant to be compiled with older compiler versions? Theoretically, if ZLS (w/ embedded AstGen) gets compiled with 0.11.0-dev.1681+0bb178bbb but then someone tries using it with an earlier compiler version, wouldn't they get error diagnostics for their for loops?
The obv solution is to have prefer_ast_check_as_child_process set to true by default, but also something to consider before going forward with deeper integration of compiler components.

zls master is only intended to really work with zig master, they update in lock-step. zls gets pinned in time for the zig releases to fix this exact problem.

zls master is only intended to really work with zig master, they update in lock-step. zls gets pinned in time for the zig releases to fix this exact problem.

I know, but keeping build_runner.zig backwards compatible says otherwise 😀

We do try to keep the runtime zig version requirements as wide as possible by making sure the build runner can run on as many versions as possible but we only do this as a best effort.

As @nullptrdevs points out the multi-object for is a breaking change to the language (for (a) |*item, i| is no longer valid) this means the embeded ast-check will find valid 0.9.1/0.10.1 code as invalid which means that with this change zls will only support zig versions after the multi-object change (which is a good excuse to simplify the build_runner to remove all the compatibility stuff)

On its own, this PR does not make sense, but in the wider picture Techatrix painted in the Discord of using ZIR for analysis and eventually comptime interpreting, it absolutely does. I believe that for now, it would make the most sense to have prefer_ast_check_as_child_process set to true by default.