zigtools / zls Goto Github PK
View Code? Open in Web Editor NEWA Zig language server supporting Zig developers with features like autocomplete and goto definition
License: MIT License
A Zig language server supporting Zig developers with features like autocomplete and goto definition
License: MIT License
There are a few allocated chunks of memory that are never freed.
I wonder why vector definitions isn't exists in std ast. 😕
For both completions, go to and hovers.
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.
Resolve the type of the expression, keep the value type of the error union, done.
zls_version
: f5b30cfneovim_version
: v0.5.0-508-gc37d9fa3dnvim-lsp_version
: neovim/nvim-lspconfig@205a9f0zls.json
:
{"zig_lib_path": "/home/demizer/zig-linux-x86_64-0.6.0+0fd77c2de/lib/zig/std"}
When I type std.
nothing happens. There are no arguments for logging that I can discern to see why this is happening.
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
.
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...
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.
This was suggested by somebody in the Zig Discord.
Examples would include:
At least in VSCode, an empty string name will cause it to ignore all symbols
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.
Line 82 in 8468207
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.
// b.zig
pub const foo = 1;
const bar = 2;
// a.zig
const b = @import("b.zig");
test "" {
b. // only 'foo' should show up
}
Like FnDecls in ContainerDecls, ContainerDecls in FnDecls etc.
zls: 5c78e88
but if i removed the try
and it won't compile
Quick example:
const std = @import("std");
pub fn main() void {
std.ArrayLi // <- ArrayList completion is a variable, not a function
}
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());
^
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.
This is reproducible at least in VSCode, with following steps to reproduce the Issue:
.zig
file with following contents:const std = @import("std");
pub fn main() void {
std.math.cos(0);
}
Ctrl-Click
the cos
.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?
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
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"
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);
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.
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)
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.
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.")
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
There are two options to do this:
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 packagesAlso 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).
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 :)
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!
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.
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'),
\})
Find all enum fields in scope, complete to those.
Testcase
fn foo() void {
for (a) |b| {
b.
}
}
With some option to disable them like operator_completions: bool
const std = @import("std");
pub fn main() void {
const u13_max = std. // I want std.math.maxInt, why you no complete :(
}
const std = @import("std");
const json = std.json;
pub fn main() void {
json. // <- No completions
}
Sooner or later we will need to add tests to check for regressions.
I propose the following three kinds of tests:
Create an analysis engine that can perform basic completion and goto.
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.
Currently we only look in the module scope.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.