"Go to Definition" not working with gogetdoc for stdlib in Go module mode

[nezorflame]

Go to Definition feature seems to be broken while browsing inside the stdlib while using gogetdoc as the docsTool.

This doesn't happen with godoc, but since godoc doesn't show the description, would be nice to get gogetdoc working.

Setup:

• Go version: 1.11.4
• vscode-go version: 0.8.0
• GO111MODULE=on (system-wide)
• "go.docsTool": "gogetdoc" set in VSCode settings

Example code

package main

import (
	"fmt"
)

func main() {
	fmt.Println("Hello, world!")
}

Steps to Reproduce:

1. Action: Right-click on Println -> Go to Definition
   Expected: IDE should redirect you to the fmt/print.go:263 line
   Got: Redirected successfully (although kinda slow).
2. Action: On line 263 right-click on Fprintln -> Go to Definition
   Expected: IDE should redirect you to the fmt/print.go:252 line
   Got: Error Definition for "Fprintln" not found

[ramya-rao-a]

It works as expected for me though in my setup I have a go.mod file and am not using the GO111MODULE env variable.

Can you ensure you have the latest version of gogetdoc? Run the command Go: Install/Update tools, select gogetdoc, press Ok to update it.

If you still have issues, also do try running gogetdoc from the terminal. You will need file path and offset. For offset, use the extension show-offset

cc @zmb3

[nezorflame]

Seems like gogetdoc (or, rather, go list) issue (/Users/nezorflame/.gvm/gos/go1.11.4 is where my Go is installed, through gvm):

Input:
~ gogetdoc -pos=/Users/nezorflame/.gvm/gos/go1.11.4/src/fmt/print.go:#7660

Output:
cannot load package containing /Users/nezorflame/.gvm/gos/go1.11.4/src/fmt/print.go: go [list -e -json -compiled -test=false -export=false -deps=true -- /Users/nezorflame/.gvm/gos/go1.11.4/src/fmt]: exit status 1: go: cannot determine module path for source directory /Users/nezorflame/.gvm/gos/go1.11.4 (outside GOPATH, no import comments)

[nezorflame]

And yeah, I confirm that GO111MODULE=on causes the issue:

Input:
~ GO111MODULE=auto gogetdoc -pos=/Users/nezorflame/.gvm/gos/go1.11.4/src/fmt/print.go:#7660

Output:

import "fmt"

func Fprintln(w io.Writer, a ...interface{}) (n int, err error)

Fprintln formats using the default formats for its operands and writes to w.
Spaces are always added between operands and a newline is appended. It returns
the number of bytes written and any write error encountered.

[nezorflame]

I've created new issue in the gogetdoc repo: zmb3/gogetdoc#54

[nezorflame]

@ramya-rao-a related question - does Go extension autodetect the presence of go.mod inside my project and invoke module-related commands if I don't explicitly set GO111MODULE=on for packages inside GOPATH?

[ramya-rao-a]

@nezorflame Great findings!

I'll close this issue as we have an upstream one in the gogetdoc repo to track the problem.

does Go extension autodetect the presence of go.mod inside my project and invoke module-related commands if I don't explicitly set GO111MODULE=on for packages inside GOPATH?

Yes.

[ramya-rao-a]

When the fix makes it into the gogetdoc repo, remember to update your version of the tool by using the Go: Install/Update Tools command

[zmb3]

Note that there isn't a separate module-aware version of gogetdoc - it should just work with both modules and the traditional GOPATH setup. A few follow up questions for you @ramya-rao-a.

The thing that's new now is the working directory absolutely matters, as the go tool will use this to look for the go.mod. Does vs-code set the working directory to the project directory when invoking gogetdoc?

Is vs-code explicitly setting GO111MODULE=on if a go.mod file is found? That might be our problem.

Edit: discovered that gogetdoc is explicitly setting the dir for go/packages - I think we need to not do that, and instead rely on editors to always use the working directory corresponding to the original project.

[ramya-rao-a]

Does vs-code set the working directory to the project directory when invoking gogetdoc?

Not yet. We do this for godef. I can do the same for gogetdoc

Is vs-code explicitly setting GO111MODULE=on if a go.mod file is found

No. Do we need to?

[ramya-rao-a]

Pushed a commit to set the current project as working directory when calling gogetdoc

[zmb3]

Perfect, this should work as soon as I get an update for gogetdoc out. 👍

[nezorflame]

@ramya-rao-a @zmb3 it seems that the issue is resolved now with the latest beta of extension and latest gogetdoc.

[ramya-rao-a]

Thanks @nezorflame, @zmb3!

[ghost]

Still not working. I deleted my Go plugin and $HOME/go folder then re-installed the plugin and analysis tools. The tool works once or twice and then seems to get lost in the directory structure. There is an easy fix, just copy a version of the gogetdoc binary from November into $HOME/go/bin and then everything is fine after killing old gogetdoc processes

[ramya-rao-a]

@leakyshoe Please log a new issue with exact repro steps with a sample code, so that we can investigate the problem.