`Go to Implementation` in Go should work when `Cmd-Click` on definition of interface method
I am faced with the problem of the broken functionality of the transition to the implementation of the interface in the go code. I've tried a lot of ways to fix this. Starting from all possible actions with gopls, ending with the test of the previous version of Zed. Nothing helped..... I liked your product and I would like to test it by switching to it.
I see the following errors in the logs "[WARN] Generic jsp request to go plus failed: no type definition for METHOD" and "[ERROR] rates/editor/src/editor.rs:7370: no type definition for METHOD".
Same here. Sadly, I cannot use Go to Definition for go projects. (And there is a lot I love about zed!)
Hey! Can someone give me some steps to reproduce? Example file, example go.mod?
Go-to-def works for me in Go projects and for many others, so it's not broken generally, which means we need to figure out why exactly it's broken here.
Thorsten! (Are you the Thorsten that popped in during the Nathans Changelog Interview? :) )
Now it is suddenly working again.. strange. And I cannot get it back to not working anymore.
Thorsten! (Are you the Thorsten that popped in during the Nathans Changelog Interview? :) )
Yes!
If it stops working again, please try to find examples to reproduce.
Does this mean this issue can be closed? Or shall we wait for couple of days to do it?
@manuraj17 I still have it, but I cannot reproduce it in a new project.. :/
As I understand it, Go to Definition works to move from a call to an interface, and Go to implementation from the interface to the implementation.
We get such a scheme
Developers, please confirm if this is the case.
I believe that Go to implementation should work using the combination CMD+LBM(Left button mouse), similar to `Go to Definition'. I also think that transitions should be cyclical so that you can use this keyboard shortcut CMD+LBM to have such a circle
Call-Interface-Func-Call's-Interface...
In vscode, the circle works like this
, it is both convenient and not, it seems to me that the option I described below is more convenient
how do you look at such an implementation?
I see. So this is about interfaces and jumping between the definition and the implementation. I updated the title.
I think this is very related to what @SomeoneToIgnore implemented yesterday to fix https://github.com/zed-industries/zed/issues/5351 here: https://github.com/zed-industries/zed/pull/9243
The difference is that this will fall back to Find all references and what you want is Find all implementations, right?
So this code here would need to do different things depending on whether it's on top of an interface or not.
https://github.com/zed-industries/zed/pull/9243/files#diff-10065bb5e48ea679a7ebc25f37a2c0cb0d3b7e0e9717d744b15436e737076b2bR155-R159
https://github.com/zed-industries/zed/assets/32771/912140cb-4022-4a67-a3a6-f70695c9cc3e
Just to let you know, I just created a quick screen capture. (0.127.1) It is about cmd + left click on a type definition. It does not jump.
But it's really hard to reproduce. It is not about the codebase but rather the state that the editor is in. Any debug logs I can provide?
I am able to reproduce it. And I think I also solved it..
https://github.com/klausbreyer/zed-go-api-test
Context: It is a mono-repo with a react app, where the go project is in a subfolder.
To reproduce the bug, open the root of the repository in zed and navigate to jwt.go -> Jump to definition does not work.
If you open the api folder in zed, so that go.mod etc. is in the root, then Jump to definition works as intended.
@klausbreyer yeah, you need to use go.work files: https://github.com/zed-industries/zed/issues/8460#issuecomment-1971216276
Thanks for the hint, @mrnugget ! But I hope this is just a workaround and eventually there will be universal support?
I'm not sure. It seems like gopls said they won't support it, so that means we'd have to find workarounds and those all seems pretty hacky: we'd have to find go.mod files (what if there isn't one?), we'd have to decide what to do with multiple go.mod files in a single project, manage multiple gopls processes, etc.
I see .. when gpls doesn't support it; then it probably isn't worth doing a dirty hack.
https://github.com/zed-industries/zed/assets/46122307/f5a96c8a-fb9e-4557-b6bc-2aa27145ba4e
Go to Definition i.e cmd + left click is also not working for tsx / jsx / js / ts files as well. I think this is the case for most of the languages, not just go lang.
I'm currently on Zed Version: Zed 0.127.3 – /Applications/Zed.app
I'm having the same issue, just tried https://github.com/zed-industries/zed/issues/8460#issuecomment-1971216276 but it still won't work. Even after opening just the Go subfolder in Zed. It's been broken for a month or so, previously it was working even in with the whole monorepo open and without the go work init + go use..
I'm currently running Zed 0.127.3
It works for me on latest stable.
https://github.com/zed-industries/zed/assets/1185253/18e163a7-b3be-4125-9fe6-1c10482490ca
@nidhey27 your issue is not about Go and not about Go to implementation — correct? Can you create a separate ticket and put in steps to reproduce and language server log output? (debug: open language server logs)
@Czechh Can you also create a new issue, also with the log output, and put information in about how your Go is installed? Also what which gopls returns in your project's folder.
I figured it out, thanks for the response.
For future reference of people hitting this issue, my problem was that I had go installed via homebrew, and which go showed the homebrew path. While gopls was pointing to the user path.
I fixed immediately by brew install gopls. But, I'm not recommending this, it might better to stay away from brew for this and keep native install for go and gopls.
@Czechh I also ran into this issue while using gobrew to manage Go versions. Once I installed gopls through brew as well, this was resolved. Thanks!
I'm going to close this because I believe the underlying cause of the original issue (gopls limitation) is understood. Additionally, an unrelated cause of similar behavior (mixed brew/gobrew installation of go/gopls) was identified (thanks @Czechh).
If this is incorrect and there's still outstanding issue we can open a new issue with a clean description that explains the issue and references the discussion here if appropriate.
Thanks all!