Hello! I’m using the “mojo-lsp-server” with Neovim 0.12. If I define a struct within my pixi project, then I use that struct in another file and run the :lua vim.lsp.buf.definition() command, it jumps me to the .mojo file where I defined that struct. However no matter what I do, when I try to go to the definition of any standard library structs or functions, it says “No locations found”.
When I run “mojo-lsp-server --help”, I can see there’s an argument for:
-I - Append directory to the search path list used to resolve imported modules in a document
It makes sense that, since the pixi package manager only installs a couple binaries and NOT the entire Mojo source code, the LSP server would require me to pass in the location for the source code. So I’ve updated my Neovim LSP config to add an -I that points to a modular/Mojo/stdlib location on my computer, as well as modular/Mojo/stdlib/std and other locations while experimenting… however nothing I’ve tried works. Anytime I “go to definition” on an Int or String or random.seed() or anything, I get “No locations found”
Does anyone have any advice for how to get my LSP’s “go to definition” to jump to files within the Modular repo’s source code?
Mojo stdlib is precompiled and shipped without the source - I don’t see how passing location arguments should help here.
I myself also think this should be supported; in languages I’ve worked with (Python, Go), I’m used to looking at stdlib api definitions as well.
There are two issues here, we should definitely fix both.
The first is that as mentioned, we only ship std.mojoc. I think there’s a good route where we can ship the std source files as part of the mojo package (still leaving it out of mojo-compiler to keep things lean).
The second is that the LSP uses the same import resolution order as the compiler, so it prefers a .mojoc file if it can get one. We need to change that order in the LSP so that it prefers source.
As a temporary hack: If you modify your local venv to remove the prebuilt std and place the sources in instead (or use -I to a local checkout, double check that it’s the exact same version), I think that should work. Though not sure if the compiler would be happy, at the very least it would increase compile times.