Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
x/tools/gopls: lsp features not working in std lib package #40809
On master (9882f1d1823da58283ff91ebbec3f7c0cc27cddc), after go-to-definitioning into a standard library package, code navigation features no longer work inside the standard library package. Attached is a log where I jumped to "fmt.Println" and then tried to jump to the definition of "newPrinter".
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
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:
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:
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.
qualifiedObjsAtProtocolPos returned too early. Have it keep looking in the rest of the candidate packages. This changes the returned error slightly but AFAICT nobody cares. Updates golang/go#40809. Change-Id: Ic8199a484f0abcaa48cb6a3bcdd782195802d670 Reviewed-on: https://go-review.googlesource.com/c/tools/+/249637 Run-TryBot: Heschi Kreinick <email@example.com> Reviewed-by: Robert Findley <firstname.lastname@example.org> TryBot-Result: Gobot Gobot <email@example.com>