gopls daemon process issue and solution suggestion

[Qi Wang]

daemon process issue:

after install vim-go and coc.nvim and setup gopls correctly, I found there are two gopls daemon servers.

/go/bin/gopls serve -listen unix;/tmp/nvimPaFflp/gopls-0285b6-daemon.shared -listen.timeout 1m0s

/go/bin/gopls serve -listen unix;/tmp/gopls-0285b6-daemon.shared -listen.timeout 1m0s 21430

Root cause: vim-go and coc.nvim use different TMPDIR. for vim-go TMPDIR is "/tmp/" for coc.nvim TMPDIR is "/tmp/nvimPaFflp/". while gopls (autostart_posix.go) use os.TempDir() to to build the unix socket address. thus two daemon process appear.

solution suggestion:

the suggest solution is to change the gopls code. because os.TempDir() is very easy to be changed by others.

see this for the detail analysis.

[Robert Findley]

Thanks for your investigation.  Another alternative is to manage the daemon manually, as described in https://github.com/golang/tools/blob/master/gopls/doc/daemon.md, but I understand that's not ideal.

I can look into solutions on the gopls side.  Is there a specific gopls change that you would like to propose?

- Rob

--
You received this message because you are subscribed to the Google Groups "golang-tools" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-tools...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-tools/041d65b7-a3b1-4587-9561-aa065396aaa6n%40googlegroups.com.

[Qi Wang]

the biggest application of language server (gopls) is for the IDE: vscode or vim/neovim. automatic gopls management is the right direction for those IDE. people always want simple and good thing. for vim-go or coc-go, manually  manage the language server will not be easy, it's even harder for other developers to use it. a lot of post on the github already prove that. 

I absolutely support the automatic daemon management. while keep the manually management available for some rare cases.

i am not very familiar with the gopls code. after investigated the vim-go, coc-go and coc.nvim for some time. i turned to gopls. it took me several days to understand the daemon related code. If i am familiar with the gopls code, a PR will appear. 

there is indeed an improvement I will propose:

1. when edit a file, such as internal/lsp/lsprpc/lsprpc.go , 
2. you see a  statement in line 289, "func connectToRemote":
   "network, address = autoNetworkAddress(goplsPath, inAddr)",
   now, to find the autoNetworkAddress func, you send a 'definition' query to the gopls server.
3. in current implementation,  'definition' query will return the internal/lsp/lsprpc/autostart_default.go result. and the editor jump to that file without any choice. this implementation will mislead the developer. i checked the code several times and finally notice the 'build tags'
4. the propose is to return the internal/lsp/lsprpc/autostart_posix.go , the behavior of 'definition' query should consider the 'build tags', in this case, it is "// +build darwin dragonfly freebsd linux netbsd openbsd solaris".

if you think my propose is needed. i will file an issue. maybe  a PR will appear. 

qi wang

[Robert Findley]

Thanks, I do think this discussion is probably most suited for the issue tracker. I opened an issue for the daemon discovery / TMPDIR problem at https://golang.org/issue/41266.

Regarding the particular example you mentioned (autostart_posix.go): this is not a case of multiple definitions, but rather a variable being overwritten based on build constraints.  This was done so that the list of build constraints is only maintained in one place.  But if it were the case of multiple definitions (which is a common pattern), you are right that gopls would not handle this very gracefully.  We have an open issue for this, which I think covers your request: https://golang.org/issue/29202.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-tools/e4c4affd-e697-4380-8ddd-8ecf896f8878n%40googlegroups.com.

[Qi Wang]

thanks, 

I will check the https://golang.org/issue/29202.