You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 15, 2023. It is now read-only.
After tested some third-party packages, I've found some third-party packages fail to go to definition(github.com/spf13/cobra), and some work very slow (github.com/spf13/viper). Results can be seen in my repo.
As the readme says,
when you are outside the mod directory (for example, workspace dir), godef will fail on some cases
godef works much slower than expected
Reason:
Current vscode-go extension misused the new godef, now always run godef on workspace dir.
Because new godef relays on packages to find definitions.
A quick example for verifying this => gopackages
So the new godef working with go mod, it should run inside the mod project, otherwise it will fallback to the old version.
Example code and some tests:
https://github.com/sunliver/mod-test
After tested some third-party packages, I've found some third-party packages fail to
go to definition
(github.com/spf13/cobra), and some work very slow (github.com/spf13/viper). Results can be seen in my repo.As the readme says,
godef
will fail on some casesgodef
works much slower than expectedReason:
Current vscode-go extension misused the new
godef
, now always rungodef
on workspace dir.Because new
godef
relays on packages to find definitions.A quick example for verifying this => gopackages
So the new godef working with
go mod
, it should run inside the mod project, otherwise it will fallback to the old version.How to fix
I've fixed this on this PR, or may other ways.
The text was updated successfully, but these errors were encountered: