zigtools / zls Goto Github PK

View Code? Open in Web Editor NEW

2.5K 30.0 267.0 7.39 MB

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

License: MIT License

Zig 99.87% Nix 0.13%

zig ziglang zig-language-server zls language-server language-support

zls's Issues

Add enum literal completions

Find all enum fields in scope, complete to those.

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

Field access on a capture causes segfault

Testcase

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

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...

Lookup symbols from the innermost scope outwards

Currently we only look in the module scope.

Add label support

For both completions, go to and hovers.

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.

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.

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.

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
}

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

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

Nested declarations should show up in outlines

Like FnDecls in ContainerDecls, ContainerDecls in FnDecls etc.

Local completions should work in test blocks

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
}

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.

Support try expressions

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

Analysis engine

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

Zig "std" implementations marked as zls(BadStyle)

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

Create a .zig file with following contents:

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

Ctrl-Click the cos.
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?

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"

Go to definition on imports is broken

Add zig topic to repo

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.

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)

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.

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

issues with try expression

zls: 5c78e88

but if i removed the try

and it won't compile

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..

Fix memory leaks

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

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).

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

Fix builtin-based completions such as with Vectors

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

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

With some option to disable them like operator_completions: bool

zls occasionally crashes when typing `break :`

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.)

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,

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());
                                      ^

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

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 :( 
}

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
}

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 :)

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'),
			\})

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.

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!

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.")

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.

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);

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.

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.

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.

zigtools / zls Goto Github PK

zls's Issues

Recommend Projects

Recommend Topics

Recommend Org