x/tools/gopls: doesn't handle replace directive

[wtask]

go version go1.15 windows/amd64

Version: 1.48.0 (user setup)
Commit: db40434f562994116e5b21c24015a2e40b2504e6
Date: 2020-08-13T07:50:42.600Z
Electron: 7.3.2
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Windows_NT x64 10.0.19041

Go extension 0.16.1

gopls version

golang.org/x/tools/gopls 0.4.4
    golang.org/x/tools/gopls@v0.4.4 h1:8djGYsaZ0ByP0vaXg4T+mnyfDcHpWKSZ+tpQSGv9ahk=

I have a project with sub-module. The main repo contains api folder, so the main go.mod contain replace directive like:

replace {repo-url}/api => ./api

And I can not understand several things how to make extension to work as expected:

1. If I do not fix the api version manually, the go-command makes it version v0.0.0-00010101000000-000000000000, after go mod tidy. But vscode-go despite of replace and "special" module version value, opens old api-version references (ctrl+click) from global pkg/mod/ folder. Restarting the language server does not help to force using local api-folder.

2. If I run go get -u in module context to update api to latest available version (v0.2.0-pre in my case) then the go.mod file is properly modified. BUT vscode-go continue to use old module version which is not required and is not exists in go.mod. Restarting the gopls, reloading vscode does not help - an older version of api-module is opened by ctrl+click on api-references.

What do I need to do to force extension work in this simple case? Who of them the vscode-go OR the gopls is ignoring the replace-directive?

[stamblerre]

Can you please provide the gopls logs when you encounter this issue? Instructions on how to capture the logs are here. We are still working out some issues with replace directives in gopls, but this case should work.

[wtask]

@stamblerre I can not post logs of my private project. But I have completed some investigation for this issue. Primary, I have a big workspace for over 10 repos. Some of them is not yet updated to the latest dependencies versions and gopls logs contains errors just the same as go mod tidy output if I run the command inside repos. But the repo from which this issue is appeared was updated. I can suppose gopls collects or caches results for another workspace-entry-points and does not work "from scratch" for every workspace dir or may it lost the context or stops to respond and then wakes up ... But I'm not able to explain why the next experiment was successfull. I created temporary workspace for a single repo. And vscode started to work fine. But... Now it always opens local module from replace-directive and doesn't react at changes of the module version in go.mod. I am confused because the gopls works more or less fine only for simple workspaces.

[heschi]

gopls currently requires that each workspace folder be in a single module. If you're opening a directory that contains multiple modules, you will see strange results like those you're describing. Instead, you can use the Add Folder to Workspace option in VS Code to add new folders that each are in a single module.

[wtask]

@heschik I know. In my case, I worked only on "main" module inside the multi-module repo. The code of sub-module was updated before by adding it folder as workspace root. After updating was done the sub-module root was removed from workspace.

[heschi]

OK. In that case I'm not sure what the problem is, and without logs it's going to be difficult to investigate any further. If you can put together a reproducer we'll be happy to take a look.

[stamblerre]

Closing as this is in the WaitingForInfo state and gopls/v0.5.0 will be released soon. Please open a new issue if you still have this issue with gopls/v0.5.0-pre3 (GO111MODULE=on go get golang.org/x/tools/gopls@v0.5.0-pre3.