working directory not preserved correctly

[nezorflame]

Seems like gogetdoc (or, rather, go list?) is unable to get documentation for stdlib packages with GO111MODULE=on (/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)

If I explicitly set GO111MODULE=auto (or off) before invoking it, it works:

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.

Details on that issue can be found here: microsoft/vscode-go#2213

[ramya-rao-a]

cc @zmb3

[zmb3]

Thanks for tracking this down - the detail in your vscode-go issue helped tremendously.

This is an issue of preserving context properly. In its current state, gogetdoc uses the directory containing your file query as the working directory for go list. This is why your initial query succeeds.

When you try to navigate again from within the fmt package, we are using a working directory inside the go source instead of your original project directory, and the go tool cannot find the main module.

[ramya-rao-a]

@zmb3 In that case, I believe I can fix this from vscode-go just like I did previously for godef

I dont set a working directory for the child process being spawned for calling gogetdoc.
But for godef, I pass the current project opened in VS Code as the working directory.

Will doing the same help gogetdoc as well?

[zmb3]

Will doing the same help gogetdoc as well?

Yes, it will. But I need to push a fix to gogetdoc before it will make a difference.

[nezorflame]

Seems like the issue is resolved now.
Thanks @zmb3!

[zmb3]

Thanks for following up @nezorflame!

[karim]

@zmb3 The fix for this issue introduced another issue. The details are here microsoft/vscode-go#2246. Would you mind taking a look at it?

[zmb3]

@karim this is intentional. Editors must provide a working directory when invoking the tool. The fix will have to be made in the extension. Let’s take the conversation over to that issue.

[karim]

I see, thanks.