gopls code completion doesn't work in multi-language project

[thekvs]

Don't know if it is a gopls or vscode-go issue, but since I mostly use VSCode nowadays I am reporting it here.

I have a multi-language project, Go part lives in separate go folder (outside $GOPATH), Python -- in python etc. So structure looks like:

project/
├── go
├── python
└── README.md

Code completion with gopls doesn't work when I first open project folder in VSCode then navigate to go sub-folder and open Go file there, but does work when I directly open go folder in VSCode at the start of the session.

I use modules In Go code, so structure looks like:

project/go/
├── cmd
├── go.mod
├── go.sum
└── vendor

gocode-gomod doesn't have this issue.

I am using:

• VSCode version: 1.33.1
• Go plugin 0.10.2

[ramya-rao-a]

Thanks for reporting @thekvs

This is very similar to the issue #2431 and is a limitation on gopls that it doesnt work if the main folder opened in VS Code is not the one with the Go code.

@stamblerre Do you think that the extension should try and run go env GOMOD and use the folder path returned as the "root uri" for the language server?

[bhcleek]

@ramya-rao-a FWIW, I'm planning to modify vim-go so that it will use the dirname($(go env GOMOD)). Obviously, there are some edge that have to be handled (GOPATH mode, /dev/null modules, etc.) when doing this approach, but I think it's the right way to move forward and it's what user's naturally expect.

[thekvs]

Now vim-go works as I would expect it from the user's point of view. @ramya-rao-a can you please consider implementing similar behavior for vscode-go?

[ramya-rao-a]

@bhcleek Thanks for that tip. Do you plan to restart the language server when user moves to a file that belongs to a different module?

@thekvs Yes, this is something that we can definitely consider doing.

The only caveat is that the language server needs to be started right when the extension activates. This means that if you are working on a Go file belonging to one module, and then open another file belonging to another module (say you have a folder with multiple sub modules), then we need to restart the language server.

Right now, am not aware of a way to do this without forcing a VS Code window reload. @stamblerre, @ianthehat any thoughts here regarding if the language server can be told to switch the module directory it is using?

[ianthehat]

You should not need to restart the language server (and doing so in general is a bad idea, we hold some very expensive to re-calculate caches inside gopls, that is what makes it so fast).
We support workspace folders, and run a different "view" in each workspace folder within a single language server. We then direct all incoming messages to the most tightly bound view that holds that file.
We do not currently dynamically add/remove folders, so you have to reload the vscode window any time you change them right now, I was waiting for people to try the folder mechanic to see if it solves the problem before taking it further, but I have already started writing that part of the code.
There are still some interesting questions about how the set of workspace folders should be configured in the first place, one possible approach would be to have the extension find all go.mod files and suggest adding a workspace folder for each one to the user.

[bhcleek]

@ramya-rao-a I don't plan to update vim-go to restart gopls in that case. I will mostly likely be adding an explicit way for user's to indicate what their rootUri is; it's currently derived from the first Go file that they open in Vim.

Later, I plan to add support for letting users add workspace folders dynamically.

[ramya-rao-a]

@ianthehat So, when gopls does support multiple workspace folders, would it then determine the right folder to use based on the current file? Or do you expect the client to communicate the change in folder?

[ianthehat]

for every query gopls attempts to pick the view that contains the file most tightly (to cope with nested modules).
to make this operation fast it memorizes it, but it drops that memoization any time the set of folders is modified.
Note that the code for this is in https://go-review.googlesource.com/c/tools/+/175477 which is not yet submitted.

[ramya-rao-a]

That's great to know, thanks @ianthehat

Keeping this issue open just in case there is any extra work to be done from our side.
If possible, please drop a note here once the change goes in

[ianthehat]

Merged.

[thekvs]

As far as I understand current state we are still waiting for necessary changes in gopls. Right?

[ramya-rao-a]

@thekvs I believe the work in gopls is done.

@ianthehat, @stamblerre Is there anything to be done from the vscode go plugin's side (other than updating to the latest gopls) to make this work?

[thekvs]

I am asking because I've updated to the latest gopls but nothing seems to have changes in VSCode's behavior. Do I need to tweak some settings?

[tkvw]

I am facing the exact same issue. Using a monorepo with different languages. Any update? Something I can do?

[haggen]

@tkvw For now I'm opening each directory as its own workspace but in the same window (i.e. code -a ...). It still is a nuisance but it's a minor one and it got everything working again.

[tkvw]

@haggen: I'm doing the same (own workspace), not sure what code -a does for me? I need to do some window reloads after adding an import, so it feels buggy; but seeing gopls and modules are relatively new; I am happy I can get some work done 👍

[haggen]

@tkvw Assuming you're launching Code from the Terminal:

-a --add <folder>                 Add folder(s) to the last active window.

[tkvw]

@haggen : yeah I can read the command help 😄 , still not sure what is does?

/monorepo
  .vscode
  -> go/
  -> python/ 

What I am currently doing is:

code . <== Opens the monorepo 
code ./go <=== Opens a new window with the go workspace

Problem is that I need to maintain two .vscode settings this way.

[ramya-rao-a]

@ianthehat, @stamblerre, What do you need from the extension's side to make this work?

[stamblerre]

I think this is similar to the issue with having to add a workspace root for each module - we use the root URI passed in by VSCode to hand to go list. Possibly, VSCode-Go could detect that there is a subdirectory containing Go code and pass a different root URI?

[johan-lejdung]

I were just about to post an issue on either gopls or this Github.

What's the status on this so far @ramya-rao-a and @ianthehat?

[ramya-rao-a]

@stamblerre I believe we need an issue in gopls for this. In order to support mono repo with multiple Go projects (each a separate module), gopls need to dynamically change its context of "module" everytime a file from a different module is opened

[johan-lejdung]

I created an issue here: golang/go#32394

[ramya-rao-a]

Thanks @johan-lejdung
Closing in favor of the upstream issue golang/go#32394