zigtools/zls

A Zig language server supporting Zig developers with features like autocomplete and goto definition

Need support? Wanna help out? Join our Discord server!

The Zig Language Server (ZLS) is a tool that implements Microsoft's Language Server Protocol for Zig in Zig. In simpler terms: it'll provide you with completions, go-to definition, etc. when you write Zig code!

Table Of Contents

• Installation
  • From Source
  • Configuration Options
  • Per-build Configuration Options
    • BuildOption
• Features
• Using as a library
• Related Projects
• Quick Thanks :)
• License

Installation

See the install zls tool for editor and binary installation instructions.

From Source

Building ZLS is very easy. You will need a build of Zig master to build ZLS.

git clone https://github.com/zigtools/zls
cd zls
zig build -Doptimize=ReleaseSafe

Configuration Options

You can configure zls by editing your zls.json configuration file. Running zls --show-config-path will show a path to an already existing zls.json or a path to the local configuration folder instead.

zls will look for a zls.json configuration file in multiple locations with the following priority:

• In the local configuration folder of your OS (as provided by known-folders)
• In the global configuration folder of your OS (as provided by known-folders)

The following options are currently available.

Option	Type	Default value	What it Does
enable_snippets	bool	true	Enables snippet completions when the client also supports them
enable_argument_placeholders	bool	true	Whether to enable function argument placeholder completions
enable_build_on_save	bool	false	Whether to enable build-on-save diagnostics
build_on_save_step	[]const u8	"install"	Select which step should be executed on build-on-save
enable_autofix	bool	false	Whether to automatically fix errors on save. Currently supports adding and removing discards.
semantic_tokens	enum	.full	Set level of semantic tokens. Partial only includes information that requires semantic analysis.
enable_inlay_hints	bool	true	Enables inlay hint support when the client also supports it
inlay_hints_show_variable_type_hints	bool	true	Enable inlay hints for variable types
inlay_hints_show_struct_literal_field_type	bool	true	Enable inlay hints for fields in struct and union literals
inlay_hints_show_parameter_name	bool	true	Enable inlay hints for parameter names
inlay_hints_show_builtin	bool	true	Enable inlay hints for builtin functions
inlay_hints_exclude_single_argument	bool	true	Don't show inlay hints for single argument calls
inlay_hints_hide_redundant_param_names	bool	false	Hides inlay hints when parameter name matches the identifier (e.g. foo: foo)
inlay_hints_hide_redundant_param_names_last_token	bool	false	Hides inlay hints when parameter name matches the last token of a parameter node (e.g. foo: bar.foo, foo: &foo)
warn_style	bool	false	Enables warnings for style guideline mismatches
highlight_global_var_declarations	bool	false	Whether to highlight global var declarations
dangerous_comptime_experiments_do_not_enable	bool	false	Whether to use the comptime interpreter
skip_std_references	bool	false	When true, skips searching for references in std. Improves lookup speed for functions in user's code. Renaming and go-to-definition will continue to work as is
prefer_ast_check_as_child_process	bool	true	Favor using zig ast-check instead of ZLS's fork
builtin_path	?[]const u8	null	Path to 'builtin;' useful for debugging, automatically set if let null
zig_lib_path	?[]const u8	null	Zig library path, e.g. /path/to/zig/lib/zig, used to analyze std library imports
zig_exe_path	?[]const u8	null	Zig executable path, e.g. /path/to/zig/zig, used to run the custom build runner. If null, zig is looked up in PATH. Will be used to infer the zig standard library path if none is provided
build_runner_path	?[]const u8	null	Path to the build_runner.zig file provided by ZLS. null is equivalent to ${executable_directory}/build_runner.zig
global_cache_path	?[]const u8	null	Path to a directory that will be used as zig's cache. null is equivalent to ${KnownFolders.Cache}/zls
build_runner_global_cache_path	?[]const u8	null	Path to a directory that will be used as the global cache path when executing a projects build.zig. null is equivalent to the path shown by zig env
completion_label_details	bool	true	When false, the function signature of completion results is hidden. Improves readability in some editors

Per-build Configuration Options

The following options can be set on a per-project basis by placing zls.build.json in the project root directory next to build.zig.

Option	Type	Default value	What it Does
relative_builtin_path	?[]const u8	null	If present, this path is used to resolve @import("builtin")
build_options	?[]BuildOption	null	If present, this contains a list of user options to pass to the build. This is useful when options are used to conditionally add packages in build.zig.

BuildOption

BuildOption is defined as follows:

const BuildOption = struct {
    name: []const u8,
    value: ?[]const u8 = null,
};

When value is present, the option will be passed the same as in zig build -Dname=value. When value is null, the option will be passed as a flag instead as in zig build -Dflag.

Features

ZLS supports most language features, including simple type function support, using namespace, payload capture type resolution, custom packages, cImport and others. Support for comptime and semantic analysis is Work-in-Progress.

The following LSP features are supported:

• Completions
• Hover
• Goto definition/declaration
• Document symbols
• Find references
• Rename symbol
• Formatting using zig fmt
• Semantic token highlighting
• Inlay hints
• Code actions
• Selection ranges
• Folding regions

Using as a library

You can use zls as a library! Check out this demo repo for a good reference.

Related Projects

• sublime-zig-language by @prime31
  • Supports basic language features
  • Uses data provided by src/data to perform builtin autocompletion
• zig-lsp by @xackus
  • Inspiration for ZLS
• known-folders by @ziglibs
  • Provides API to access known folders on Linux, Windows and Mac OS
• zls by @zigtools
  • Used by many ZLS developers to more efficiently work on ZLS

Quick Thanks :)

We'd like to take a second to thank all our awesome contributors and donators/backers/sponsors; if you have time or money to spare, consider partaking in either of these options - they help keep ZLS awesome for everyone!

License

MIT

zls's Issues

Compiling with master branch of ziglang gives error.

Not sure if I'm doing this right, but, I checked out zig from master, built it, and tried to compile zls.

I received the following error:

./src/main.zig:63:39: error: TODO: type coercion of anon struct literal to struct
    try std.json.stringify(reqOrRes, .{}, arr.outStream());
                                      ^

Feature request: extra autocompletions after `catch`

It'd be neat if, for instance, the following was autocompleted:

a = b catch

Some useful autocompletions would be unreachable, |err| switch (err), and so on.

Go to definition not working with usingnamespace

Hi! Very cool that you've gotten this project so far already. Keep it up! :)

I noticed that i'm not able to use "go to definition" on declarations imported using usingnamespace.

Fix builtin-based completions such as with Vectors

I wonder why vector definitions isn't exists in std ast. 😕

Don't send error field at all when there isn't an error

The LSP spec says that the error field shouldn't exist at all if there isn't an error (yeah, this is annoying). It seems the lsp_types rust crate marks it as an invalid message if it is set (to null in this case).

I've worked around it by just commenting out the line, since zls doesn't actually send any errors yet.

zls/src/types.zig

Line 82 in 8468207

@"error": ?Error = null,

Detect self-parameters and skip the first argument in snippet completions

For functions that have a first argument of T, *T or *const T where T is the type of the expression we are field accessing.

Add a `zig_executable_path` option

Also use the executable path to try to find the library path if none is provided (including the executable path found in PATH if no zig_executable_path is provided).

The connected server does not support method textdocument/hover. [Emacs]

I connected ZLS to Emacs LSP and it works fine only when I edit a file and save it I get this error and the LSP server automatically stops. So it means I have to start it again everytime I save.

Error running timer: (error "The connected server(s) does not support method textDocument/hover To find out what capabilities support your server use ‘M-x lsp-describe-session’ and expand the capabilities section.")

Segfault when completing build-level packages

Currently on latest commit, master Zig, and I'm encountering a Segfault. Looking into it!

C:\users\augus\documents\programming\zig_oss\zlsp\zlsp\src\document_store.zig:491:27: 0x7ff7d26161c8 in document_store.AnalysisContext::document_store.AnalysisContext.tree (zls.obj)
        return self.handle.tree;
                          ^
C:\users\augus\documents\programming\zig_oss\zlsp\zlsp\src\document_store.zig:496:62: 0x7ff7d265ff64 in document_store.AnalysisContext::document_store.AnalysisContext.refreshScopeNodes (zls.obj)
        try analysis.addChildrenNodes(&scope_nodes, self.tree(), &self.tree().root_node.base);

Memory leak and [potentially] an infinite loop

For the past few days, I've been having occasional pauses where my computer locks up entirely. After leaving a small terminal running top in the background open, I noticed that every time this happens, ZLS is using 100% CPU and massive amounts of RAM, so I suspect there is a memory leak in an infinite loop somewhere.

This also explains why ZLS would sometimes become unresponsive...

Add zig topic to repo

Zig "std" implementations marked as zls(BadStyle)

This is reproducible at least in VSCode, with following steps to reproduce the Issue:

1. Create a .zig file with following contents:

const std = @import("std");
pub fn main() void {
    std.math.cos(0);
}

2. Ctrl-Click the cos.
3. zls now scans the lib/zig/std/math/cos.zig standard library file, and marks the line fn cos_(comptime T: type, x_: T) T with Functions should be camelCase zls(BadStyle)

Not sure if I should report this as an Issue here, but since zls flags "official" zig implementation code as bad style, seems pretty reasonable. Do you think this should be an Issue for ziglang/zig instead?

Add more testing to CI

As far as I can tell, the only CI right now is building ZLS. Since ZLS responds to JSON, it might be worth writing a test binary that invokes ZLS, sends it example documents, and verifies the responses. This can be used to ensure that future changes don't break specific completions, goto definitions, and so on.

Local completions should work in test blocks

Standard library completions not working

• zls_version: f5b30cf
• neovim_version: v0.5.0-508-gc37d9fa3d
• nvim-lsp_version: neovim/nvim-lspconfig@205a9f0
• zls.json:

  {"zig_lib_path": "/home/demizer/zig-linux-x86_64-0.6.0+0fd77c2de/lib/zig/std"}
  

  zls.json lives next to the zls binary.

When I type std. nothing happens. There are no arguments for logging that I can discern to see why this is happening.

Support try expressions

Resolve the type of the expression, keep the value type of the error union, done.

Add snippet completion configuration options

const std = @import("std");
const panic = std.debug.pan    <<-- TAB

After you TAB to complete that import in the newest vscode, zls completes and fills in the parameter signatures for the panic function. However, if you just wanted to complete to 'std.debug.panic;' by trying to hit ';' after the TAB (which is the default in some other languages), then the parameter signatures don't self delete properly.

Not sure if that is the correct behavior here but thought I would mention it.

Add compile-time error completion / suggestions

This was suggested by somebody in the Zig Discord.

Examples would include:

• "Name not defined" errors
• "Name redefined" errors
  etc..

Constant crashes referencing top-level @This()

With const name = @This(); at the top level of a file, anything attempting to complete from name - or from a parameter of type name - causes ZLS to crash.

This is actually one of the cases I had thought was an infinite loop; it's constantly dying and delaying the editor's lsp plugin as it restarts the server.

Add enum literal completions

Find all enum fields in scope, complete to those.

Fix memory leaks

There are a few allocated chunks of memory that are never freed.

auto-import

i'm not really sure if this is even possible with the lsp, but it would be cool if one could have this feature like you have it for e.g. java
example:
you type page_all<Tab> in your main function, but you don't have std.heap.page_allocator imported
then it suggests to add a import at the top which it does automatically when selection that completion

Go to definition on imports is broken

Analysis engine

Create an analysis engine that can perform basic completion and goto.

Nested declarations should show up in outlines

Like FnDecls in ContainerDecls, ContainerDecls in FnDecls etc.

Variables that use struct initializers don't complete

Example from the zls codebase:

// main.zig line 610+
var config = Config{};
const config_parse_options = std.json.ParseOptions{ .allocator = allocator };

config.<cursor> // <- No completions

Simple example:

const std = @import("std");

const S = struct {
    a: usize,
};

fn foo() S {}

const json = std.json;

pub fn main(s1: S) void {
    const s2: S = undefined;
    const s3 = S{};
    // s1. and s2. complete, s3. doesnt
} 

I will investigate this to get a chance to learn about the new code too :)

Add `*` and `?` operator completions when they apply

With some option to disable them like operator_completions: bool

Show types of struct members in completions

Here's how the completion for struct fields currently look like:

Fields are enumerated properly, but there's no type info.

Hard crash on incorrect import code

Hello all,

const std = @import("std");
const panic = std.debug.panic;
.
.
.
panic.

The above code crashes the server (server has crashed 5 times in the last 3 seconds) using newest vscode-1.45.1 and zls-cb4354e494bfadd2e74d5e3e16955d214fc638c1. I realize this is malformed code but I just ran into it after forgetting that I had already aliased panic. This error happens at any scope.

I had to restart vscode to rectify this so I thought I would mention it here, as it could be a pain in larger files if you forget what all you have aliased.

Add label support

For both completions, go to and hovers.

Immediate crash on startup

I've only just started trying to mess with zig today so perhaps I've missed something but I followed the directions building in readme and when I run the built executable I get a crash immediately after resolving standard library; this is the full log

Found zig in PATH: /home/nox/.local/bin/zig
Using zig executable /home/nox/.local/bin/zig
Resolved standard library from executable: /home/nox/.local/bin/lib/zig

MissingCarriageReturn; exiting!incorrect alignment
/home/nox/.local/lib/zig/std/heap.zig:146:51: 0x2363af in std.heap.PageAllocator.shrink (zls)
        const old_mem = @alignCast(mem.page_size, old_mem_unaligned);
                                                  ^
/home/nox/.local/lib/zig/std/mem.zig:279:44: 0x25d241 in std.mem.Allocator.free (zls)
        const shrink_result = self.shrinkFn(self, non_const_ptr[0..bytes_len], Slice.alignment, 0, 1);
                                           ^
/home/nox/zig/zls/src/main.zig:1194:54: 0x25ee10 in main (zls)
    defer if (zig_exe_path) |exe_path| allocator.free(exe_path);
                                                     ^
/home/nox/.local/lib/zig/std/start.zig:252:37: 0x2373ad in std.start.posixCallMainAndExit (zls)
            const result = root.main() catch |err| {
                                    ^
/home/nox/.local/lib/zig/std/start.zig:123:5: 0x2370ef in std.start._start (zls)
    @call(.{ .modifier = .never_inline }, posixCallMainAndExit, .{});
    ^
Aborted (core dumped)

Private declarations should show up in completions when not from imported types

// b.zig
pub const foo = 1;
const bar = 2;

// a.zig
const b = @import("b.zig");
test "" {
    b. // only 'foo' should show up
}

add config file directory logic

I think zls should look for directories like $XDG_CONFIG_HOME on posix systems, %appdata% on Windows and so on...
Having zls.conf in /usr/bin because zls is there is really not optimal; e.g. it needs root privileges to change the config on linux systems.

Don't send snippets if the client doesn't ask for them

The editor I use doesn't really have great support for snippets, but other language servers don't send them since snippetSupport isn't set here: https://microsoft.github.io/language-server-protocol/specification#textDocument_completion.

This isn't really a high priority thing, but just once you get support for client capabilities, it would be nice :)

edit: wasn't aware there was already a config file!

Segfault when saving file

• neovim_version: v0.5.0-508-gc37d9fa3d
• nvim_lsp_git_head: 205a9f0ca9e733d94f15f228b9e23b29a80af7cd
• zls_git_head: f5b30cf

The following segfault occurs in neovim after showing completions for std. then saving the source file:

[ ERROR ] 2020-05-26T23:41:15Z-0700 ] /usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:317 ] "rpc"   "/home/demizer/bin/zls" "stderr"        "Freeing document: file:///data/code/zig/zig-md2020/src/md/parse.zig\nFreeing document: file:///home/demizer/zig-linux-x86_64-0.6.0%2B0fd77c2de/lib/zig/std/std.zig\nFreeing document: file:///home/demizer/zig-linux-x86_64-0.6.0%2B0fd77c2de/lib/zig/std/mem.zig\nFreeing document: file:///home/demizer/zig-linux-x86_64-0.6.0%2B0fd77c2de/lib/zig/std/json.zig\n"
[ ERROR ] 2020-05-26T23:41:15Z-0700 ] /usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:317 ] "rpc"   "/home/demizer/bin/zls" "stderr"        "Freeing document: file:///home/demizer/zig-linux-x86_64-0.6.0%2B0fd77c2de/lib/zig/std/array_list.zig\n"
[ ERROR ] 2020-05-26T23:41:15Z-0700 ] /usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:317 ] "rpc"   "/home/demizer/bin/zls" "stderr"        "Freeing document: file:///home/demizer/zig-linux-x86_64-0.6.0%2B0fd77c2de/lib/zig/std/array_list_sentineled.zig\n"
[ ERROR ] 2020-05-26T23:41:15Z-0700 ] /usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:317 ] "rpc"   "/home/demizer/bin/zls" "stderr"        "Freeing document: file:///home/demizer/zig-linux-x86_64-0.6.0%2B0fd77c2de/lib/zig/std/hash_map.zig\nFreeing document: file:///home/demizer/zig-linux-x86_64-0.6.0%2B0fd77c2de/lib/zig/std/bloom_filter.zig\nFreeing document: file:///home/demizer/zig-linux-x86_64-0.6.0%2B0fd77c2de/lib/zig/std/buf_map.zig\nFreeing document: file:///home/demizer/zig-linux-x86_64-0.6.0%2B0fd77c2de/lib/zig/std/buf_set.zig\nFreeing document: file:///home/demizer/zig-linux-x86_64-0.6.0%2B0fd77c2de/lib/zig/std/child_process.zig\nFreeing document: file:///home/demizer/zig-linux-x86_64-0.6.0%2B0fd77c2de/lib/zig/std/dynamic_library.zig\nFreeing document: file:///home/demizer/zig-linux-x86_64-0.6.0%2B0fd77c2de/lib/zig/std/mutex.zig\nFreeing document: file:///home/demizer/zig-linux-x86_64-0.6.0%2B0fd77c2de/lib/zig/std/packed_int_array.zig\n"
[ ERROR ] 2020-05-26T23:41:15Z-0700 ] /usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:317 ] "rpc"   "/home/demizer/bin/zls" "stderr"        "Freeing document: file:///home/demizer/zig-linux-x86_64-0.6.0%2B0fd77c2de/lib/zig/std/priority_queue.zig\nSegmentation fault at address 0x7f721eab1030\n"
[ ERROR ] 2020-05-26T23:41:15Z-0700 ] /usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:317 ] "rpc"   "/home/demizer/bin/zls" "stderr"        "/data/src/zig/zls/src/document_store.zig:277:20: 0x291736 in document_store.decrementCount (zls)\n"
[ ERROR ] 2020-05-26T23:41:15Z-0700 ] /usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:317 ] "rpc"   "/home/demizer/bin/zls" "stderr"        "       "
[ ERROR ] 2020-05-26T23:41:15Z-0700 ] /usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:317 ] "rpc"   "/home/demizer/bin/zls" "stderr"        " entry.value.count -= 1;\n                   ^\n"
[ ERROR ] 2020-05-26T23:41:15Z-0700 ] /usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:317 ] "rpc"   "/home/demizer/bin/zls" "stderr"        "/data/src/zig/zls/src/document_store.zig:292:32: 0x291871 in "
[ ERROR ] 2020-05-26T23:41:15Z-0700 ] /usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:317 ] "rpc"   "/home/demizer/bin/zls" "stderr"        "document_store.decrementCount (zls)\n"
[ ERROR ] 2020-05-26T23:41:15Z-0700 ] /usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:317 ] "rpc"   "/home/demizer/bin/zls" "stderr"        "     "
[ ERROR ] 2020-05-26T23:41:15Z-0700 ] /usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:317 ] "rpc"   "/home/demizer/bin/zls" "stderr"        "       self.decrementCount(import_uri);\n"
[ ERROR ] 2020-05-26T23:41:15Z-0700 ] /usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:317 ] "rpc"   "/home/demizer/bin/zls" "stderr"        "                               ^\n"
[ ERROR ] 2020-05-26T23:41:15Z-0700 ] /usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:317 ] "rpc"   "/home/demizer/bin/zls" "stderr"        "/data/src/zig/zls/src/document_store.zig:292:32: 0x291871"
[ ERROR ] 2020-05-26T23:41:15Z-0700 ] /usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:317 ] "rpc"   "/home/demizer/bin/zls" "stderr"        " in document_store.decrementCount (zls)\n"
[ ERROR ] 2020-05-26T23:41:15Z-0700 ] /usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:317 ] "rpc"   "/home/demizer/bin/zls" "stderr"        "         "
[ ERROR ] 2020-05-26T23:41:15Z-0700 ] /usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:317 ] "rpc"   "/home/demizer/bin/zls" "stderr"        "   self.decrementCount(import_uri);\n                               ^\n"
[ ERROR ] 2020-05-26T23:41:15Z-0700 ] /usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:317 ] "rpc"   "/home/demizer/bin/zls" "stderr"        "/data/src/zig/zls/src/document_store.zig:306:24: 0x"
[ ERROR ] 2020-05-26T23:41:15Z-0700 ] /usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:317 ] "rpc"   "/home/demizer/bin/zls" "stderr"        "273b44 in document_store.closeDocument (zls)\n"
[ ERROR ] 2020-05-26T23:41:15Z-0700 ] /usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:317 ] "rpc"   "/home/demizer/bin/zls" "stderr"        "    self"
[ ERROR ] 2020-05-26T23:41:15Z-0700 ] /usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:317 ] "rpc"   "/home/demizer/bin/zls" "stderr"        ".decrementCount(uri);\n                       ^\n"
[ ERROR ] 2020-05-26T23:41:15Z-0700 ] /usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:317 ] "rpc"   "/home/demizer/bin/zls" "stderr"        "/data/src/zig/zls/src/main.zig:761:37: 0x2650c7"
[ ERROR ] 2020-05-26T23:41:15Z-0700 ] /usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:317 ] "rpc"   "/home/demizer/bin/zls" "stderr"        " in processJsonRpc (zls)\n"
[ ERROR ] 2020-05-26T23:41:15Z-0700 ] /usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:317 ] "rpc"   "/home/demizer/bin/zls" "stderr"        "        "
[ ERROR ] 2020-05-26T23:41:15Z-0700 ] /usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:317 ] "rpc"   "/home/demizer/bin/zls" "stderr"        "document_store.closeDocument(uri);\n"
[ ERROR ] 2020-05-26T23:41:15Z-0700 ] /usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:317 ] "rpc"   "/home/demizer/bin/zls" "stderr"        "                                    ^\n"
[ ERROR ] 2020-05-26T23:41:15Z-0700 ] /usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:317 ] "rpc"   "/home/demizer/bin/zls" "stderr"        "/data/src/zig/zls/src/main.zig:955:27: 0x"
[ ERROR ] 2020-05-26T23:41:15Z-0700 ] /usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:317 ] "rpc"   "/home/demizer/bin/zls" "stderr"        "25af08 in main (zls)\n"
[ ERROR ] 2020-05-26T23:41:15Z-0700 ] /usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:317 ] "rpc"   "/home/demizer/bin/zls" "stderr"        "       "
[ ERROR ] 2020-05-26T23:41:15Z-0700 ] /usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:317 ] "rpc"   "/home/demizer/bin/zls" "stderr"        " try processJsonRpc(&json_parser, buf, config);\n                          ^\n"
[ ERROR ] 2020-05-26T23:41:15Z-0700 ] /usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:317 ] "rpc"   "/home/demizer/bin/zls" "stderr"        "/home/demizer/zig-linux-x86_64-0.6.0+0fd77c2de/lib/zig/std/start.zig:252:37: 0x"
[ ERROR ] 2020-05-26T23:41:15Z-0700 ] /usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:317 ] "rpc"   "/home/demizer/bin/zls" "stderr"        "23379d in std.start.posixCallMainAndExit (zls)\n"
[ ERROR ] 2020-05-26T23:41:15Z-0700 ] /usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:317 ] "rpc"   "/home/demizer/bin/zls" "stderr"        "     "
[ ERROR ] 2020-05-26T23:41:15Z-0700 ] /usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:317 ] "rpc"   "/home/demizer/bin/zls" "stderr"        "       const result = root.main()"
[ ERROR ] 2020-05-26T23:41:15Z-0700 ] /usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:317 ] "rpc"   "/home/demizer/bin/zls" "stderr"        " catch |err| {\n                                    ^\n"
[ ERROR ] 2020-05-26T23:41:15Z-0700 ] /usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:317 ] "rpc"   "/home/demizer/bin/zls" "stderr"        "/home/demizer/zig-linux-x86_64-0.6.0+0fd77c2de/lib/zig/std/start.zig:123:"
[ ERROR ] 2020-05-26T23:41:15Z-0700 ] /usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:317 ] "rpc"   "/home/demizer/bin/zls" "stderr"        "5: 0x2334df in std.start._start (zls)\n"
[ ERROR ] 2020-05-26T23:41:15Z-0700 ] /usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:317 ] "rpc"   "/home/demizer/bin/zls" "stderr"        "    @call(.{ ."
[ ERROR ] 2020-05-26T23:41:15Z-0700 ] /usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:317 ] "rpc"   "/home/demizer/bin/zls" "stderr"        "modifier = .never_inline }, posixCallM"
[ ERROR ] 2020-05-26T23:41:15Z-0700 ] /usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:317 ] "rpc"   "/home/demizer/bin/zls" "stderr"        "ainAndExit, .{});\n    ^\n"

Test declarations with empty names will cause the document's outline to be empty

At least in VSCode, an empty string name will cause it to ignore all symbols

builtin functions aren't completed if a part of it is already typed

As I already said in discord, I added zls as lsp and it get's called but I have neither completion for builtin functions nor for global variables. This might just as well be a misconfiguration on my side, but it could also be a zls bug. Here is my full vim config, and those are the significant parts:

let lsp_filetypes = [ 'rust', 'zig', 'c', 'cpp', 'go', 'java', 'kotlin', 'sh', 'zsh', 'vim', 'javascript', 'typescript', 'python' ]

Plug 'dense-analysis/ale', { 'for': lsp_filetypes }
Plug 'Shougo/deoplete.nvim', { 'do': ':UpdateRemotePlugins', 'for': lsp_filetypes }

let g:ale_linters = {
			\ 'rust': ['analyzer', 'clippy', 'rustfmt'],
			\ 'zig': ['zls'],
			\ 'python': ['pyls'],
			\ 'go': ['gopls'],
			\ 'javascript': ['tsserver', 'flow', 'eslint'],
			\ 'typescript': ['tsserver', 'eslint'],
			\ }

function! GetCommand(buffer) abort
	return '%e'
endfunction

function! GetZigProjectRoot(buffer) abort
	let l:cargo_file = ale#path#FindNearestFile(a:buffer, 'build.zig')

	return !empty(l:cargo_file) ? fnamemodify(l:cargo_file, ':h') : getcwd()
endfunction

call ale#linter#Define('zig', {
			\   'name': 'zls',
			\   'lsp': 'stdio',
			\   'executable': '/usr/bin/zls',
			\   'command': function('GetCommand'),
			\   'project_root': function('GetZigProjectRoot'),
			\})

Functions defined directly as a field access of an import currently complete as variables

Quick example:

const std = @import("std");

pub fn main() void {
    std.ArrayLi // <- ArrayList completion is a variable, not a function
}

Field access on a capture causes segfault

Testcase

fn foo() void {
    for (a) |b| {
        b.
    }
}

Improve tests

Sooner or later we will need to add tests to check for regressions.

I propose the following three kinds of tests:

• Function unit tests (mainly for the parsing functions)
• I/O testing: simulate a client sending requests from a different process and check the responses are correct
• Internal state testing: simulate a client sending requests from a different process and check our internal state (number of documents, text of documents, latest sane_text of documents etc.)

Clicking the string in a @import should open the file.

Lookup symbols from the innermost scope outwards

Currently we only look in the module scope.

issues with try expression

zls: 5c78e88

but if i removed the try

and it won't compile

Field completions do not trigger in all contexts

const std = @import("std");

pub fn main() void {
    const u13_max = std. // I want std.math.maxInt, why you no complete :( 
}

Redefinitions of imports in variables should support field access completions

const std = @import("std");
const json = std.json;

pub fn main() void {
    json. // <- No completions
}

zls occasionally crashes when typing `break :`

compile error

Hi,

I've got a compile error:

C:\temp\zls>zig build
.\src\main.zig:63:39: error: TODO: type coercion of anon struct literal to struct
    try std.json.stringify(reqOrRes, .{}, arr.outStream());
                                      ^
.\src\main.zig:194:13: note: called from here
    try send(types.Notification{
            ^
.\src\main.zig:127:75: note: called from here
fn publishDiagnostics(handle: DocumentStore.Handle, config: Config) !void {
                                                                          ^
.\src\main.zig:63:27: note: referenced here
    try std.json.stringify(reqOrRes, .{}, arr.outStream());
                          ^
.\src\main.zig:194:5: note: referenced here
    try send(types.Notification{
    ^
.\src\main.zig:971:9: note: referenced here
        try publishDiagnostics(handle.*, configFromUriOr(uri, config));
        ^
.\src\main.zig:1366:9: note: referenced here
        try processJsonRpc(&json_parser, buf, config, &keep_running);
        ^
zls...The following command exited with error code 1:
C:\Program Files\zig\zig.exe build-exe C:\temp\zls\src\main.zig --pkg-begin build_options C:\temp\zls\zig-cache\zls_build_options.zig --pkg-end --cache-dir C:\temp\zls\zig-cache --name zls --pkg-begin known-folders C:\temp\zls\src\known-folders\known-folders.zig --pkg-end --cache on

Build failed. The following command failed:
C:\temp\zls\zig-cache\o\2aCxu3sZT8J2_mEoCB25STpC_1PPEEAKtJ7REcBd8kGgMejnbfsoa52RIFD8FIqc\build.exe C:\Program Files\zig\zig.exe C:\temp\zls C:\temp\zls\zig-cache

C:\temp\zls>zig version
0.6.0+4302f276e

I'm not sure if I need a newer or older compiler version.

Test decl outlines should use the test's string literal name instead of 'no_name'

Fail to install on Arch Linux.

Running with zig build config and getting these errors:

error: FileNotFound
/usr/lib/zig/std/os.zig:1767:19: 0x274e8c in std.os.mkdiratZ (build)
        EEXIST => return error.PathAlreadyExists,
                  ^
/usr/lib/zig/std/os.zig:1750:9: 0x274d5b in std.os.mkdirat (build)
        return mkdiratZ(dir_fd, &sub_dir_path_c, mode);
        ^
/usr/lib/zig/std/fs.zig:744:9: 0x274bf6 in std.fs.Dir.makeDir (build)
        try os.mkdirat(self.fd, sub_path, default_new_dir_mode);
        ^
/usr/lib/zig/std/os.zig:930:23: 0x25e40b in std.os.openatZ (build)
            ENOENT => return error.FileNotFound,
                      ^
/usr/lib/zig/std/fs.zig:864:25: 0x297c45 in std.fs.Dir.openDirFlagsZ (build)
            else => |e| return e,
                        ^
/usr/lib/zig/std/fs.zig:835:13: 0x2886e8 in std.fs.Dir.openDirZ (build)
            return self.openDirFlagsZ(sub_path_c, os.O_DIRECTORY | os.O_RDONLY | os.O_CLOEXEC | O_PATH);
            ^
/usr/lib/zig/std/fs.zig:822:13: 0x27b40f in std.fs.Dir.openDir (build)
            return self.openDirZ(&sub_path_c, args);
            ^
/home/aprokurov/zls/build.zig:19:15: 0x27e7ee in std.special.config (build)
    var dir = try std.fs.cwd().openDir(builder.exe_dir, .{});
              ^
/usr/lib/zig/std/build.zig:2394:9: 0x275cbe in std.build.Step.make (build)
        try self.makeFn(self);
        ^
/usr/lib/zig/std/build.zig:404:9: 0x2746b3 in std.build.Builder.makeOneStep (build)
        try s.make();
        ^
/usr/lib/zig/std/build.zig:359:13: 0x26a9e7 in std.build.Builder.make (build)
            try self.makeOneStep(s);
            ^
/usr/lib/zig/std/special/build_runner.zig:125:21: 0x26339d in main (build)
            else => return err,
                    ^

Build failed. The following command failed:
/home/aprokurov/zls/zig-cache/o/xvCpi0WL6uGJa0YULTtO8TZpjpETQ0KcZo-_-aUr3ilWRLYVOwYH3Plxkbapz707/build /usr/bin/zig /home/aprokurov/zls /home/aprokurov/zls/zig-cache config

Add custom package support

There are two options to do this:

• Parse build.zig, try to find invocations of addPackage.
• Find zig in PATH, make a custom build runner that only outputs the packages instead of executing the build, run zig to build the build runner with the build.zig as a Child process, collect the packages