Go: x/tools/cmd/guru: referrers doesn't return references if used on the definition of the method

[johan-lindqvist]

What version of Go are you using (go version)?

go version go1.9.2 windows/amd64

Does this issue reproduce with the latest release?

The latest stable, yes. I haven't tried the beta.

What operating system and processor architecture are you using (go env)?

PS C:codegobin> go env
set GOARCH=amd64
set GOBIN=
set GOEXE=.exe
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=c:codego
set GORACE=
set GOROOT=C:Go
set GOTOOLDIR=C:Gopkgtoolwindows_amd64
set GCCGO=gccgo
set CC=gcc
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0
set CXX=g++
set CGO_ENABLED=1
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config

What did you do?

Example project: config.zip

1. Open the attached project in Visual Studio Code, or using guru directly in the CLI.
2. Go to the file config.go in pkg/config
3. Use "Find all references" on the function GetConfig. Get zero results.

What did you expect to see?

All the references to the function GetConfig, in this case 2.

What did you see instead?

Zero references are returned, when it should actually return 2.

---

The strange thing is that a colleague doesn't have this issue, and the only difference is that he's running VS Code on Mac, and I'm running it on Windows. There are other colleagues that have the same issue and they're running Windows as well.

Reference to issue that has already been opened but could not be solved on the vscode-go repo: https://github.com/Microsoft/vscode-go/issues/1415

[johan-lindqvist]

Some more information when using guru from the cli to find referrers.

Using guru referrers on the definition of the function gives the following result:

PS C:\code\go\src\config> C:\code\go\bin\guru.exe referrers c:\code\go\src\config\pkg\config\config.go:#53
c:\code\go\src\config\pkg\config\config.go:4.6-4.14: references to func GetConfig(path string) string

Here I expect to see the two usages of the function in the other files.

---

Using guru referrers on one of the usages of the function (in main.go) gives the following result:

PS C:\code\go\src\config> C:\code\go\bin\guru.exe referrers c:\code\go\src\config\main.go:#100
c:\code\go\src\config\pkg\config\config.go:4.6-4.14: references to func GetConfig(path string) string
c:\code\go\src\config\pkg\config1\config1.go:7.9-7.17:  config.GetConfig("asdf")
c:\code\go\src\config\main.go:9.19-9.27:        config := config.GetConfig("config")

---

Using guru referrers on one of the usages of the function (in config1.go) gives the following result:

PS C:\code\go\src\config> C:\code\go\bin\guru.exe referrers c:\code\go\src\config\pkg\config1\config1.go:#98
c:\code\go\src\config\pkg\config\config.go:4.6-4.14: references to func GetConfig(path string) string
c:\code\go\src\config\pkg\config1\config1.go:7.9-7.17:  config.GetConfig("asdf")
c:\code\go\src\config\main.go:9.19-9.27:        config := config.GetConfig("config")

[johan-lindqvist]

Any ideas on what the cause of this could be? Or is there something I could try that would fix the issue?

[doxxx]

I'm seeing the same behavior on Windows as well. Haven't tried on a different platform yet.

[sandipb]

I found why Guru was behaving like this for my case. It appears that Guru doesn't work when there are symlinks in your GOPATH. My package was symlinked into GOPATH because of certain workspace related build environment requirements.

I converted the symlink to a hardlink, and Guru started working for me.

[doxxx]

For me that's not the issue. I'm using VSCode with the Go extension. When I try to find usages of a method or field at the location where it's defined, it doesn't find usages in the same workspace (i.e. project) outside of the current package.

[sandipb]

Sorry, I wasn’t clear. I am not directly using guru myself. Like you, i was using Guru via VSCode’s Go extension.

[johan-lindqvist]

The problem still exists with go1.9.4. This issue is pretty severe, not being able to trust Find All References makes guru unusable.

[teroy]

+1

[andybons]

Please don’t add “Me too” comments to issues: https://github.com/golang/go/wiki/NoMeToo

@alandonovan for the original report.

[tuhlmann]

I've created a little proxy app that takes the guru call from VS Code and passes the arguments and stdin to the Linux version of guru installed in Windows WSL: https://github.com/tuhlmann/guru-wsl-bridge

It works on my system, but hasn't been thoroughly yet, I'm only using it through Visual Studio Code.
I hope this is a short lived workaround...

Maybe someone finds it helpful.

[nesvold]

This is still an issue with go 1.11. It works on mac/linux, but not on Windows. (No symlinks.)

[jerryxguo]

an issue here with go1.11 windows/amd64

[doxxx]

This should be fixed by golang/tools#56 (CL 151057).

[tuhlmann]

Cool! I patched my local version of guru with the provided fix and it works for me. I'm using VSCode that uses the Windows version of the tools and WSL to compile and run the application.

[eparziale]

Thanks @doxxx for the fix, and @tuhlmann for the inspiration on how to get this patched and working locally for now!

FYI - For others who want to test the patch on Windows VSCode, I followed these steps

First confirm that find all references command is actually broken in your local Windows VSCode using Guru

1. Download https://github.com/golang/go/files/1599811/config.zip and unpack it to $GOPATHsrcconfig
2. In VS Code open the file config.go in pkg/config
3. Right click on the function GetConfig and click "Find all references". The only reference you should see is the self-reference in the same file (This is the bug - See screenshot)
   
4. At this point we have confirmed that guru find all references doesn't work as expected in Windows VS Code

Now make the local patch and confirm that find all references now works

1. First back up the broken copy of guru
2. cd $GOPATHbin -> rename guru.exe to guru_old.exe

1. Now let's create patched guru.exe and use it in VS Code
2. cd $GOPATHsrcgolang.orgxtoolscmdguru
3. Open what.go in your favorite text editor and change lines 13 and 206 per the commit here: https://github.com/golang/tools/pull/56/commits/f15f5b603d5a9adfa5eedf9c06de9ac2c625580f
4. Open VS code -> Ctrl +Shift + P. -> Search "Go: Install/Update Tools -> Check the box next to guru -> click ok
5. Console should say Installing golang.org/x/tools/cmd/guru SUCCEEDED
6. In VS Code open the file config.go in pkg/config
7. Right click on the function GetConfig and click "Find all references"

8. VS Code should now correctly display all three references (See screenshot)
   

9. Note here that if you were to rename $GOPATHbinguru_old back to guru and retry find all references, the original problem will re-appear

@jltjohanlindqvist Can you please confirm that these steps work for you?

One important note - When you select GetConfig function in VS Code, don't double click on the function name then click find all references (For some reason double click causes VS code to never return results). Instead hover over the method, then simply right click find all references. Then VS code will actually return references.

[martinrode]

I am on Mac OS 10.14.2 (latest) and the patch for Windows is NOT working for me. I am seeing the exact same issue @eparziale is illustrating in his first screenshot.

Vscode is Version 1.30.2 (1.30.2), Go Extension is 0.8.0. go1.11.2 darwin/amd64.

My project is outside GOPATH and uses GO111MODULES.

This problem is pretty annoying, so any help is greatly appreciated!

[doxxx]

@martinrode It's possible that guru doesn't currently support Go Modules, which is much larger problem. The patch for Windows is purely to fix incorrect slashes in module paths.

[dmitshur]

guru indeed does not have support for modules yet. That's a separate issue and it's being tracked in #24661.

CL 151057 should resolve this issue (and #24699, which is the same as this one).

[gopherbot]

Change https://golang.org/cl/151057 mentions this issue: cmd/guru: fix guessImportPath for Windows