Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/tools/gopls: consider indexing workspace symbols in all dependencies #53004

Open
findleyr opened this issue May 19, 2022 · 2 comments
Open
Labels
FeatureRequest gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Milestone

Comments

@findleyr
Copy link
Contributor

As noted in #37537 (comment), workspace symbols is a useful index for "available symbols" in a project. But right now, we only index files in the transitive closure of workspace packages. This means that symbols in unimported packages (including stdlib packages) are not reachable. FWIW I don't usually notice this, but it can be surprising if one is trying to jump to a standard library symbol that happens not to be reachable. As an API it's not great because the user can't be expected to remember which packages are imported, and which are not.

The good news is that the workspace symbol index is out-of-band of our package graph, and symbols are somewhat efficiently stored (if needed, we can further optimize their storage). We should be able to index all files in modules reachable from the workspace.

To start, we can do this for std.

CC @marwan-at-work @hyangah

@findleyr findleyr added this to the gopls/later milestone May 19, 2022
@gopherbot gopherbot added Tools This label describes issues relating to any tools in the x/tools repository. gopls Issues related to the Go language server, gopls. labels May 19, 2022
@marwan-at-work
Copy link
Contributor

@findleyr thank you for creating the issue 🙏🏼 would this (unrelated) CL be of help in any way since it adds the idea of fetching all standard library packages/imports at start up? https://go-review.googlesource.com/c/tools/+/351650

I looked into how that would work for the case of symbols but I'm not sure yet how gopls can parse the std lib from go/packages and turn them into cashed objects/files in the snapshot. I'd be happy to contribute but would probably need guidance.

Thanks!

@findleyr
Copy link
Contributor Author

@marwan-at-work first of all, sorry that review dropped off. If you're game, let's revisit it -- though I think we should rethink the problem.

The consistency of package metadata is a big concern for gopls, and I'd prefer not to have another source of metadata that could go out of sync. I think we should aim to have our metadata graph hold all possible package information that we could need. If this is our model, then both this workspace symbol problem and the known packages problem become easy to solve.

I suspect that go/packages is fast enough for this, provided we are selective about our queries. We already load metadata through go/packages at startup (our initial workspace load), and loading all necessary metadata for kubernetes takes ~4s.

We just need to have a good mechanism for loading non-critical metadata asynchronously, and merging it into our metadata graph. I'm working on this problem this month, as part of some optimization work, and I'll see what it would take to load all necessary metadata.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
FeatureRequest gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Projects
None yet
Development

No branches or pull requests

4 participants