Go to Definition doesn't work when using with Vim + ALE

[coffeebe4code]

I'm trying to solve a specific minor thing. and I'm trying to determine how to do so.

I have Vim, and I use ALE for my zls. I love, and usually need to look through the zig source code for the std library, or other modules as well which may be on my local, or in zig-cache because they were installed with the zon package method.

When i "Go to Definition" on a method in my source where zls is on the root dir. I can successfully navigate to wherever it is.

take for example:
~/zig/0.16.0/lib/std/Io/Dir.zig

/// Test accessing `sub_path`.
///
/// ...
pub fn access(dir: Dir, io: Io, sub_path: []const u8, options: AccessOptions) AccessError!void {
    return io.vtable.dirAccess(io.userdata, dir, sub_path, options);
}

I was able to use Go to Definition on std.Io.Dir.access. However, once in this file, or any other local downloaded module, I can't now Go to Definition for io.vtable.dirAccess.

How would I continue to navigate? Is this something zls could solve?

[Techatrix]

I checked this against VS Code and ZLS does resolve the Goto definition request on dirAccess to this location.

It looks like this issue specific to ALE. When I open any file in the Zig standard library and then run :ALEInfo, the output contains this at the end:

 LSP Error Messages:

(Errors for zls)
Failed to find project root, language server won't start.

It seems like ALE is refusing to run ZLS because it can't find a build.zig in any parent directory of the current file. I opened dense-analysis/ale#5082 to see if this could get addressed in ALE.

[coffeebe4code]

Oh okay, perfect. I'm not sure ALE will do much there, it's up to someone to read the zig setup vim file in the repository, and probably add some vimscript to handle such a case.

What would zls expect to receive for the std library? I could see if I can figure it out.

[Techatrix]

What would zls expect to receive for the std library?

Doesn't really matter to ZLS. ZLS doesn't care about it's cwd and no matter which LSP workspace folders it receives, it will always be able to handle most requests on files like those in standard library.