When using gopls, Find All References fails

[josh-tepper]

Issue Type: Bug

This follows up on #2914 submitted by another user. I'm experiencing the same behavior: Find all references only resolves references within the symbol's package, but not in other packages.

However, I'm using a version of gopls that supposedly includes the fix for this (per the discussion on the ticket):

$ gopls version
golang.org/x/tools/gopls v0.3.4
    golang.org/x/tools/gopls@v0.3.4 h1:4GC7q/pXQ/tsxHBGVdsMdlB4gCxVC06m/7rIXg1Px4E=

Reverting the vscode config to not use gopls fixes the issue.

Similarly invoking guru and gopls on the command line reveals the same disparity (guru includes references from other packages, gopls does not).

Please let me know what you need to debug

Extension version: 0.13.1
VS Code version: Code 1.43.2 (0ba0ca52957102ca3527cf479571617f0de6ed50, 2020-03-24T07:34:57.037Z)
OS version: Darwin x64 18.7.0

System Info

Item	Value
CPUs	Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz (8 x 2800)
GPU Status	2d_canvas: enabled flash_3d: enabled flash_stage3d: enabled flash_stage3d_baseline: enabled gpu_compositing: enabled metal: disabled_off multiple_raster_threads: enabled_on oop_rasterization: disabled_off protected_video_decode: unavailable_off rasterization: enabled skia_renderer: disabled_off_ok video_decode: enabled viz_display_compositor: enabled_on viz_hit_test_surface_layer: disabled_off_ok webgl: enabled webgl2: enabled
Load (avg)	4, 3, 2
Memory (System)	16.00GB (0.06GB free)
Process Argv
Screen Reader	no
VM	0%

[stamblerre]

@josh-tepper: Are you using modules or GOPATH?

[josh-tepper]

I am.

After looking at this comment on the gopls issue, I thought that this might have to do with the workspace root. My workspace root is a parent of the relevant go/src dir (an artifact of our mono-repo setup). I tried opening the child go/src directory as the root, and this resolved the issue.

However this is frustrating. Given our monorepo setup, I don't want to have to restrict to the child directory. Actually, I have two $GOPATH entries that are both children of my workspace root (as well as other non-go code).

[josh-tepper]

Even lacking a fix for the "multiple GOPATH entries as children" issue, it would still be helpful if it could handle the case when ONE of the children is go/src (in my case, the second is just an experimental dir for playing with non-production code -- and I could exclude it if that would help).

[stamblerre]

You can add additional folders to your VS Code workspace to have a multi-project workspace (File > Add Project to Workspace). We don't currently support searching across multiple folders in a project (unless you open their common parent directory), but we will be adding support for that in gopls/v0.5.0.

[josh-tepper]

I am talking about opening a common parent directory. Consider the following directory structure:

/a/
 | - go/     <-- GOPATH
      |- src/
          | - b/...
          | - c/...

I tested three cases:

1. Workspace root set to /a/: Does NOT work. Each symbol only finds references within its own package. This is my preferred setup.
2. Workspace root set to /a/go/src/: Works. Symbols find references anywhere in /a/go/src/..
3. Workspace root set to /a/go/src/b/: Works. Symbols find references anywhere in /a/go/src/b/.. (even outside of their own package), but correctly does not find references from /a/go/src/c/..

When I mentioned two directories before, I was just saying that in my initial setup when I first reported the failure I had two directories in my GOPATH, both under the workspace root -- In the structure above, imagine an additional path /a/experimental/go (again, with the workspace root set to /a/). However, since it also fails in the simpler case where there is only one child dir in the go path (ie case 1 above), I don't mind if we ignore the two GOPATH setup for now since that's less important to me.

[stamblerre]

Thank you for the clarification! I just filed golang/go#38078 to track this upstream.