Improving Your Zig Language Server Experience

Media
,
1

@kristoff new blog post Improving Your Zig Language Server Experience is a follow up to this discovery Why `-fno-emit-bin` is so much faster to get to the first compilation error?

13 Likes
2

That discussion was definitely where I first learned of the main trick (building with fno-emit-bin) but the ZLS option to run a build step on save (+ error parsing and reporting as a diagnostic) predates it (the setting was added in august 2023), which I imagine was added to support the general use case of displaying build errors in the editor.

3 Likes
3

The credit for the check discovery goes to @Brysen, who asked a very reasonable question of why zig build check isn’t a thing!

3 Likes
4

This is a great article! Can we expect to have this functionality bundled?

5

Thanks @kristoff for that informative article. I hope this doesn’t mean what it seems to mean:

the late Alex Naskos

6

My only gripe is that this, as written, assumes that there’s a check step in every project you run zls against, right?

I wonder if I could configure eglot to pass --config-path…

Great article, thank you, and it helps clarify some build.zig stuff for me too :slight_smile:

7

I don’t think so, defining what your build looks like is always entirely up to you (the user). Maybe there might be some things that could be done to make it easier to either discover this functionality (eg have zig init create a check step), or exploit it (eg make it so your default step could be made non-emitting via a cli flag), but at it’s core the build script is userland code that you’re expected to be in control of.

related issues:
https://github.com/zigtools/zls/issues/1918

https://github.com/ziglang/zig/issues/18877
https://github.com/ziglang/zig/pull/20388

1 Like
8

Yes but if the step is not present nothing bad happens. See also the ZLS issue I linked in my previous message for potential future improvements.

1 Like
9

Alex passed away in September 2023

10

Deeply saddened to hear this.

11

Wow. Terrible news. He will be missed.

12

Great tip in that article. It got me thinking and I think that you can reduce that addition in build.zig to just these 2 lines right?

const check = b.step("check", "Check if foo compiles");
check.dependOn(&exe.step);

or just 1:

b.step("check", "Check if foo compiles").dependOn(&exe.step);
13

no that won’t get you the -fno-emit-bin flag, see the issues I linked above. currently you need to define a different exe step that doesn’t get referenced by b.installArtifact.

you can test this claim by doing zig build --verbose 2>&1 | grep fno-emit-bin using either configuration

1 Like
14

This is really neat!

I have a question. I’ve tested this out on just a basic zig init project to make sure my config was set up right and I’ve noticed that only some compile errors are emitted. For example:

const std = @import("std");

pub fn main() !void {
    // Prints to stderr (it's a shortcut based on `std.io.getStdErr()`)
    std.debug.print("All your {b} are belong to us.\n", .{4.01});

    var res = [_]i8{255};
    _ = &res;

    // stdout is for the actual output of your application, for example if you
    // are implementing gzip, then only the compressed bytes should be sent to
    // stdout, not any debugging messages.
    const stdout_file = std.io.getStdOut().writer();
    var bw = std.io.bufferedWriter(stdout_file);
    const stdout = bw.writer();

    try stdout.print("Run `zig build test` to run the tests.\n", .{});

    try bw.flush(); // don't forget to flush!
}

The error with using an i8 rather than a u8 shows up, but there is no error diagnostic for using b with a float in the std.debug.print call. Both of these issue compile errors when I run my check command, so I’m curious as to why only the first one is reported by zls. Any ideas?

15

That’ll be because the error there isn’t being triggered at the std.debug.print call, but rather in the standard library. That std.debug.print call just happens to be in the (hypothetical) call stack for the error!

1 Like
16

Ahh. That makes sense. I’m trying to think about how you could trace the error back to the “correct” call-site. Not even sure how to define what the “correct” call-site would be.