Use visualfc/gocode

[dzeban]

There are multiple versions of gocode now - the original nsf/gocode but
it's deprecated in favor of mdempsky/gocode. The latter is not
maintained anymore and doesn't support modules so there are multiple
versions of gocode with support for modules - stamblerre/gocode and
visualfc/gocode. The stamblerre was used as a separate binary
gocode-gomod alas it's not working all the time (see for example end of
the discussion microsoft/vscode-go#1932).

Meanwhile, visualfc/gocode is working great both for GOPATH code and modules
code so there is no need to support 2 binaries.

In these changes we switch to visualfc/gocode, remove stamblerre/gocode
version and also remove the unnecessary choice of binary.

ref: #1906.

[bhcleek]

Thank you for contributing.

There's more changes necessary, though, than just simply swapping out the binaries, because vsfcode/gocode supports a different set of options than mdempsky/gocode and stamblerre/gocode.

@stamblerre can you weigh in on the concerns about stamblerre/gocode?

[dzeban]

CI Test failures

I was trying to investigate on why completion test failed but had no luck - I couldn't trace the invocation of gocode autocomplete and also no gocode daemon was started during tests. My vimscript skills is not that good to reconstruct what's happening between go#complete#GetInfo(), runtest, GOPATH and gocode so I'm asking for help here.

Also, it would be great to write tests for completion with go modules enabled (outside of GOPATH) because now I see the GO111MODULES=off everywhere in tests.

Also also I have no clue why debug_test.vim failed in neovim environment (working in other) but as far as I can it is currently broken on master so I guess we can ignore it here.

[dzeban]

Regarding stamblerre/gocode I couldn't even see the invocation of gocode-gomod from vim-go 🤷‍♂️.

[stamblerre]

I can't speak to why gocode-gomod wouldn't be invoked from Vim, but stamblerre/gocode should work for $GOPATH and Go modules - it will just be slightly slower for $GOPATH than mdempsky/gocode. Ultimately gocode will be deprecated in favor of gopls, but if the 2 binaries are posing problems, I could probably merge mdempsky/gocode with stamblerre/gocode and have the modules check occur in gocode (much like godef does).

[bhcleek]

@stamblerre I was just wondering if the problems that @dzeban mentioned with stamblerre/gocode are real and/or if they're still a problem.

I'm working on the golsp integration for vim-go, and I'm not concerned about having two binaries.

If gocode-gomod isn't being invoked @dzeban then that's a separate problem that's likely particular to your environment for some reason, and doesn't justify swapping out for yet another gocode.

[stamblerre]

@bhcleek: The only potential issue with stamblerre/gocode is that it's slower in $GOPATH mode, but that's solved by having the other binary. What other problems are you referring to?

[bhcleek]

The stamblerre was used as a separate binary
gocode-gomod alas it's not working all the time (see for example end of
the discussion microsoft/vscode-go#1932).

[stamblerre]

Completion for unsaved imports has worked since stamblerre/gocode#21, which I think is the issue discussed in that conversation.

[dzeban]

Ok, it seems that something is utterly broken on my side as now completion doesn't work at all. I'm closing this and try to investigate on my own. Sorry for bothering.