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: implementations fails on internal/lsp/source #35857

Closed
stamblerre opened this issue Nov 26, 2019 · 3 comments
Closed

x/tools/gopls: implementations fails on internal/lsp/source #35857

stamblerre opened this issue Nov 26, 2019 · 3 comments
Assignees
Labels
Milestone

Comments

@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented Nov 26, 2019

Going to the implementation of a function in an interface in internal/lsp/source/view.go always fails.

@stamblerre
Copy link
Contributor Author

@stamblerre stamblerre commented Dec 2, 2019

@ridersofrohan investigated this issue, and it comes down to the different types.Objects having pointers to different types.Packages. This is a result of the way that we type-check dependencies. In this case, what happens is:

  • The request originates in internal/lsp/source/view.go, which is type-checked in source.ParseFull mode (since it is an open file).
  • The implementation is internal/lsp/cache, which depends on internal/lsp/source. This package is also in the workspace, which means that it has also been type-checked in full mode. All packages check their dependencies in exported mode. internal/lsp/source is a dependency of this package, so it has been checked in source.ParseExported mode. As a result we end up in a situation where we are comparing 2 different types.Packages.

I'm not sure what the best approach is here. We could probably check if the identifier's package is a dependency of the package being investigated and switch the package being compared?

@stamblerre stamblerre modified the milestones: Unreleased, gopls v1.0 Dec 4, 2019
@gopherbot
Copy link

@gopherbot gopherbot commented Dec 4, 2019

Change https://golang.org/cl/209759 mentions this issue: internal/lsp: always ParseFull in-workspace dependencies

@muirdm
Copy link

@muirdm muirdm commented Dec 6, 2019

This still happens for me sometimes. After restarting gopls find-implementations always works, but then later I come back and find-implementations stops working. I would guess the workspace package list is getting out of sync or breaking in some way, but I haven't tracked it down yet.

@stamblerre stamblerre modified the milestones: gopls/v1.0.0, gopls/v0.4.0 Jul 22, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants