multithreaded job processing

[Techatrix]

Independent requests, diagnostics and build file loading will now be processed in parallel. This means faster message handling as well as near instant startup time and more race conditions.

I would appreciate if anyone who reads this would try out this PR to see if there are any issues that need to be addressed.
Also, should multithreading be enabled by default? I already made sure that ZLS can still be build as a single threaded executable.

I've also redesigned the public API of Server that plays nice with zls-as-lib-demo.

Future Improvements:

• build on save using the Zig Compile Server Explore compile server integration #1076 (I am really excited for this one)
• request cancelling, partial results & progress report

Tracy is starting to look interesting

[FnControlOption]

Currently giving this a try while starting work on peer type resolution in zls; issues I'm having so far:

• Does not add _ = foo for unused foo
• VS Code is printing "[Error] Stopping server timed out"
• No error with -Dsingle-threaded=true

[leecannon]

Ditto to VS Code printing "[Error] Stopping server timed out" even though it seems to just keep going and works fine.

Seems to be some weirdness with go to in hover, hovering over errorable in the below:

const E = error{ X, Y };
const S = struct { alpha: u32 };

fn errorable() E!S {
    return undefined;
}

On master:

This PR:

[Techatrix]

Seems to be some weirdness with go to in hover, hovering over errorable in the below:

I overlooked a change while resolving merge conflicts. This should be resolved now

[Techatrix]

• Does not add _ = foo for unused foo

I've also encountered this issue and though this was a configuration issue. Is is it possible that you are using VSCode and have set zig.astCheckProvider to extension because that causes vscode-zig to set enable_ast_check_diagnostics to false that stops ZLS from generating ast-check diagnostics and therefore won't provide any code actions including autofix.

[Error] Stopping server timed out

I suspect that I am not responding to some request. I will need to do some more investigating.

[FnControlOption]

is it possible that you are using VSCode and have set zig.astCheckProvider to extension

Nope, it's set to zls. It might be that the server simply crashed before it could add _ = foo but I'm not certain 🤔

[leecannon]

Sometimes zls stops responding and the server has to be restarted.

Attaching a debugger shows multiple threads sitting here:

zls/src/features/diagnostics.zig

Line 232 in 1c749e4

const stderr_bytes = try process.stderr.?.reader().readAllAlloc(server.allocator, std.math.maxInt(usize));

After locking up and restarting zls five times:

$ ps -A | grep zig
 122908 ?        00:00:00 zig
 122909 ?        00:00:00 zig
 122952 ?        00:00:00 zig
 122953 ?        00:00:00 zig
 123128 ?        00:00:00 zig
 123129 ?        00:00:00 zig
 123523 ?        00:00:00 zig
 123524 ?        00:00:00 zig
 123584 ?        00:00:00 zig
 123585 ?        00:00:00 zig

[leecannon]

The issue occurs when multiple zig child processes are spawned to do ast check at the same time.

I've confirmed that adding a mutex to getDiagnosticsFromAstCheck stops the lockup.

[leecannon]

Can't recreate the lockup any more 👍.

I will keep trying to break it but so far this is looking good, also I will hold off on merging other PRs for a while to prevent so many conflicts building up here.

[FnControlOption]

Rebased this branch on commit 952d51b in master and did git merge master: 2a9fe36 (There were no conflicts in src/analysis.zig so you can ignore that file)

[leecannon]

I haven't been able to break this after ~12 hours of use, so I think its time to merge it and wait for the screams :)