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: vendored modules ignored #55995
Comments
Hi @andig! Thanks for filing an issue. Would you mind sharing the following information about your VS Code related settings? Thanks! What version of Go, VS Code & VS Code Go extension are you using?Version Information
Share the Go related settings you have added/editedRun |
Here we go:
I can probably convert the case into a small repro if that helps. |
Hi @andig, thanks for reporting this bug. Could you clarify what you meant by "drilldown on function"? Is this the go-to-definition operation? I tried downloading a project, adding a dependency on the crypto module, vendoring the dependencies, then jumping to the definition of the crypto symbol whose reference I had inserted, and gopls correctly visited the vendored code. I don't doubt that gopls has several bugs related to vendoring, but I'm not able to reproduce this one yet. Is your project open-source? If so, please share details of specific commands and files and I'll try to reproduce it. If it's not open-source, would you be willing to try creating a reproducible test case using open-source code? As soon as we can reproduce the issue we can attempt a fix. Thanks! |
Never mind! I was able to reproduce it by loading the workspace, then running go mod vendor, and then looking up the symbol: gopls retained the old declaration, incorrectly. (Running go mod vendor before loading the workspace, or restarting gopls, causes it to see the correct declaration in vendor/.) |
I‘m sorry, forgot to close this one. These are modules of the standard library vendored. They do not become part of the build as I‘ve later found out. So |
Reopening as you‘ve found a different issue which might still be tracked here. |
Your example refers to golang.org/x/crypto, which is not part of the standard library. This is indeed a bug, one I can reproduce. |
See https://groups.google.com/g/golang-nuts/c/wlhj5RFXh9g/m/DRCjOLw9AQAJ?utm_medium=email&utm_source=footer where Ian confirmed that vendored x/crypto is not used. |
Change https://go.dev/cl/454315 mentions this issue: |
Change https://go.dev/cl/454637 mentions this issue: |
This change adds a test for golang/go#56169, whose cause and fix were the same as for golang/go#55995, which was fixed in CL 454315. Updates golang/go#55995 Fixes golang/go#56169 Change-Id: I6d2cf964be77606de3e945c2e5ecdee82892ee99 Reviewed-on: https://go-review.googlesource.com/c/tools/+/454637 Reviewed-by: Robert Findley <rfindley@google.com> Run-TryBot: Alan Donovan <adonovan@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> gopls-CI: kokoro <noreply+kokoro@google.com>
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
Using VScode with latest Go plugin. Modules vendored in order to be able to patch x/crypto. During debug session, I can see that the code from the vendored module is executed.
What did you expect to see?
During browsing the code I expect drilldown on function to open vendored file.
What did you see instead?
Instead, file from module cache is opened, i.e. vendored dependencies ignored.
The text was updated successfully, but these errors were encountered: