@heschik I think this was an unintended consequence of https://go-review.googlesource.com/c/tools/+/248380

I agree I broke this, but I don't know how to fix it.

There are good reasons we don't want to type check every package in full mode: it uses a ton of memory and CPU for code that the user is probably not working on. So our strategy of checking workspace packages in full mode, and others in export-only mode, is useful. But it puts us in a difficult position when dealing with non-workspace packages.

Let's consider Find References on fmt.Printf, as mentioned in the description of 248380. If we use the export-only version of the fmt package, we will successfully find references from the user's code to Println. We won't find references outside the workspace, and we won't even realize an unexported symbol exists. If we use the full version, we can deal with unexported identifiers, and we can find references internal to the package itself. Nothing else will be connected to it.

Fundamentally, we cannot fully support non-workspace packages without fully type checking them, and we can't afford to do that. So the question is what tradeoffs we want to make. Some options:

• Very specifically for Go To Definition, add a fallback to or force full type checking. Since we're only interested in forward references, that will work fine.
• Continue with the current state, where ~no features work outside of the workspace.
• Attempt to work in both modes for all requests, merging the results. In the Printf example, this would allow you to find references in the fmt package and the user's workspace, but not the stdlib generally. I think that might be too confusing.

I think maybe I'm leaning toward a special case for Go To Definition? Possibly it can choose the type checking mode based on the exported-ness of the identifier.

In order of importance to me:

1. If I open a non-workspace file, gopls should type check a package it belongs to so go-to-definition works.
2. Find-references should work within that non-workspace package since that is useful when poking around.
3. Find-references from within the non-workspace package should find references in my workspace.

I think 1) correspond to your first option, and 3) corresponds to your third option.

We sort of already handle same-package-checked-multiple-times for find-references and find-implementations due to test variant packages. We seed the find-references search with all packages the starting file belongs to (e.g. "foo" and "foo [foo.test]" or w/e), and we dedupe results by token.Position. It should work to also throw full and partial versions into the mix.

In conclusion I would like at least 1) and to consider doing 3). I don't find the lack of references across non-workspace packages confusing because I already don't expect that to work. Others may have different expectations.

Test variants aren't totally comparable. The big problem is incoming references, where the type objects won't line up, and test variants don't have any of them.

I'll play around with it.

Change https://golang.org/cl/249120 mentions this issue: internal/lsp/cache: don't always type check in default mode

Change https://golang.org/cl/249637 mentions this issue: internal/lsp/source: fix unexported references of non-workspace packages