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 · 2 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

This comment has been minimized.

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

This comment has been minimized.

Copy link

@gopherbot gopherbot commented Dec 4, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.