i’ll post specific examples as i can better isolate them, but i’ve sometimes found that ZLS (under VSCode) will report “unknown” as a type when hovering – even though the compiler presumably “knows” the type when i actually build…
in some cases, the idiom const MY_CONST = complex_expr; would leave ZLS in the dark; adding a specific MY_CONST: SomeType often fixes the problem…
in my particular use-case, i have some pretty “deeply-nested” generic types which return different struct types based on some comptime constant…
my (future) users will absolutely depend upon hover/completion in VSCode to guide when learning Zig in my curated environment…
to increase my understanding, why does ZLS seem “less aware” then the actually compiler vis-a-vis types of variables/expressions??? and are there idioms i should try to use in my own libraries to optimize the end-user experience in VSCode???
Could you include an example?
A known limitation of ZLS is types which involve some comptime calculation. There’s experimental support, which you can turn on in the settings. Other than that I’ve found it quite accurate.
ZLS has heuristics for understanding simple comptime expressions but past a certain level of complexity it gives up. When you pin down a type explicitly, you basically save ZLS the trouble of trying to analyze what a piece of comptime code is doing.
Of course the best solution is to have the LSP understand all of Zig, and the plan is to have the Zig compiler itself fulfill that role, but before we get there some other pieces have to fall into place.
Near the end of this blog post I talk about ZLS and the Zig roadmap a little (the rest of the blogpost might be useful aswell):
3 Likes
this is all goodness… i’ll be patient – and grateful for the ZLS support that’s already in place…
in the near-term, sounds like be more “type-explicit” in my own code certainly won’t make things any worse 