LSP documentation seems to be generated from master branch of Zig ?

[devansh08]

I'm using zig and zls at version 0.16.0 (in screenshot). But when I take a look at the documentation for @intFromFloat, for example, it says deprecated, which is true for master branch of zig, but not the 0.16.0 version.

Please let me know if I'm missing something here.

Screenshot:

[yudin-s]

This looks like a Zig/ZLS version-channel mismatch rather than a project config problem: ZLS hover text for builtins comes from metadata bundled into the ZLS binary, not live from the zig 0.16.0 langref.

In the ZLS source, builtin hover docs are generated from src/tools/langref.html.in. The current checked-in entry for @intFromFloat says:

<p>Deprecated. Equivalent to {#link|@trunc#}.</p>

src/tools/config_gen.zig parses that langref file into builtin metadata, and src/features/hover.zig reads from data.builtins when showing hover text for builtins. So a ZLS binary built from current main/dev sources can show newer builtin docs even if the Zig binary selected by your project is 0.16.0.

I would first check which zls your editor is actually launching, because editors/extensions often use a different binary than the one you see in a terminal:

zig version
zls --version
which zls

Then compare that with your editor's ZLS path/extension setting. If ZLS came from a nightly/main artifact or was built from the current repository, use a matching Zig dev build. If you want Zig 0.16.0 docs and behavior, use the ZLS release/channel meant for Zig 0.16.0 and restart the editor so the old language server process is not still running.

If your editor really is launching an official 0.16.0 ZLS binary and it still embeds the newer @intFromFloat deprecation text, then the useful bug report is the exact mismatch: zig version, zls --version, install method, editor ZLS path, and the hover screenshot.

If this was just a mixed Zig/ZLS channel, marking this answered would help the next person check the language server binary first.

[devansh08]

Thanks for detailed reply!

About the zls binary, I've it installed via mason.nvim and I can see it was pulled with the 0.16.0 tag. Also that is the only binary (the one in my screenshot) that is on my system; I haven't installed zls via any other method. I'm fairly certain the binary has been pulled from the 0.16.0 tag, so I don't think there is a channel mismatch there.

But the src/tools/langref.html.in file you mentioned does have the deprecated description even in the 0.16.0 tag source code. Weirdly enough that is also the case with the original zig source code at 0.16.0 tag. I would assume zls pulls this doc from the zig source code itself, and so these 2 match.

Currently, I think the issue is with the ziglang website source code itself, which seems to be out of sync with the docs of zig. What's shown on the website is exactly the doc for 0.15.2.

I think raising an issue on ziglang.org would be the right call instead, I'll look into that. Let me know if I missing anything.

[yudin-s]

You are not missing much. With those links, this no longer looks like ZLS pulling from the wrong branch.

If zls 0.16.0 embeds the same langref.html.in text as the Zig 0.16.0 source tree, then ZLS is doing the consistent thing for the source it was built from. The mismatch is between the generated/public Zig 0.16.0 documentation page and the 0.16.0 source doc file.

So yes, I would report it against the Zig website/docs generation path rather than ZLS. The useful issue body is basically the three-way comparison you already made:

• Zig 0.16.0 source doc/langref.html.in says @intFromFloat is deprecated / equivalent to @trunc.
• ZLS 0.16.0 source src/tools/langref.html.in has the same text.
• The public ziglang.org/documentation/0.16.0/ page shows the older 0.15.2 wording.

That keeps the report focused: ZLS is matching the tagged source docs, while the published 0.16.0 website docs appear stale or generated from the wrong input.

[devansh08]

Thanks, raised it: https://codeberg.org/ziglang/ziglang.org/issues/631

Meanwhile, until this is fixed and anyone lands on this issue, one can get the language reference on local by just checking out the zig source to the specific tag/version (git checkout 0.16.0) and just running zig build in the project root. The HTML doc will be available in zig-out/doc/langref.html (love the simplicity ❤️).

[yudin-s]

Nice, that upstream issue and the local-doc note are useful. I agree this is better left as a Zig website/docs generation problem now; ZLS is matching the tagged source docs, and your Codeberg issue captures the mismatch clearly for anyone who lands here later.