Skip to content
This repository has been archived by the owner on Jul 15, 2023. It is now read-only.

go to declaration not working sometimes (ie f12, editor.action.goToDeclaration) #702

Closed
josh-tepper opened this issue Jan 2, 2017 · 17 comments
Labels

Comments

@josh-tepper
Copy link

josh-tepper commented Jan 2, 2017

Go to declaration/definition is in some cases not working. It's not clear to me when it does and does not work.

When it doesn't work, nothing happens when I press f12. It always seems to happen when I want to jump to a function in another package, but in some cases this does work. In the cases where it works, it always works, and in the cases where it doesn't, it never seems to work.

This seems to have started happening in the last couple of months.

What debug information is needed to diagnose this?

@ramya-rao-a
Copy link
Contributor

In such cases what do you see when you do a Peek Definition or when you hover on the function ?
Behind the scenes the extension runs the same code and returns the same data for both Goto and Peek Definition back to VS Code.

If the Peek Definition/Hover just says "Loading" and never shows anything, it might be because the operation to find the definition and docs never completed.

Add "go.docsTool": "gogetdoc" in your settings and try again. This will make the Goto/Peek definition and Hover features to use the gogetdoc tool instead of godef tool.

You can also try running the godef tool from the command line and see if it returns anything.

@josh-tepper
Copy link
Author

josh-tepper commented Jan 3, 2017

Thanks for getting back to me. In response to your questions:

  • When I peek the definition or hover, it actually just doesn't do anything. There's no error message; the ui literally does nothing.
  • Setting "go.docsTool": "gogetdoc" seems to solve the problem, but jump to declaration/peek/etc are much slower (but now work for everything)
  • When I run godef for the symbol, it just says "no declaration found". See below. First as a proof of proper configuration, here is an example of an expression that does work:
$ godef -f api/main.go environment.SetFromString
<PATH REDACTED>/environment.go:41:6

Here is an example of one of the offending expressions:

$ godef -f api/main.go state.Init
godef: no declaration found for state.Init

Finally, running the failed godef command with gogetdoc yields the proper results:

$ gogetdoc -pos api/main.go:#870
import "clarifai/state"

func Init()

Undocumented.

What is the best way to proceed? Should I file an issue against godef? Are there other debugging steps that I can take?

@ramya-rao-a
Copy link
Contributor

Thanks for the clarification @josh-tepper
In this case, the right thing to do is to file an issue with godef with sample code.

@josh-tepper
Copy link
Author

@ramya-rao-a,
I filed a godef issue (linked above), and I pinged it again last week. I haven't gotten a response. Do you guys have any godef contacts that you can reach out to about this issue? I would love to see this fixed -- setting the docsTool to godef gives me a way snappier experience than setting it to gogetdoc.

Thank you in advance!

@ramya-rao-a
Copy link
Contributor

@josh-tepper Can you share a sample code?

We did have issues with godef and structs and certain packages.

Do you see this issue for all code? Say a simple fmt.Println . Are you able to use go to definition on this one?

Unfortunately, I don't have any godef contact.

But adding sample code in the issue you created in godef should help as well.

Also, do try updating your godef. Sometimes, they ship some fixes which might (or might not :) ) help.

@jwendel
Copy link

jwendel commented Jan 24, 2017

@ramya-rao-a I dug into this a little as it was affecting me as well.

It looks like godef has 2 current problems (one has an outstanding pull request).

  1. import "C" causes godef to break. See: [master] Special treatment for "C" package. rogpeppe/godef#44
  2. At least on windows import "golang_org/x/net/route" from the net package breaks godef. Specifically it seems since all the files within the x/net/route import have a // +build header on all the go files for OSes other than Windows, Go complains there are no buildable sources files in the import and causes godef to break.

@ramya-rao-a
Copy link
Contributor

@jwendel Your second note on the net packages is interesting. Do we know why the // +build header is missing for Windows? Is there any documentation or issue for that?

@jwendel
Copy link

jwendel commented Jan 24, 2017

This is the code error:
C:\go\src\net\interface_bsd.go:12:2: cannot find identifier for package "golang_org/x/net/route": no buildable Go source files in C:\go\src\vendor\golang_org\x\net\route 2017/01/23 21:33:57 } -> <nil>

Notice it's an import in interface_bsd to the package: https://github.com/golang/net/tree/master/route
And everything in that package is bsd specific implementations. So really, godef probably needs to be changed to not follow imports in files that aren't supported on the current platform. (That's at least my guess)

@bruparel
Copy link

bruparel commented Feb 5, 2017

@ramya-rao-a This is a generic problem with VSCode and not confined to the just the Go lang. This is happening to me in the Angular 2 Typescript code. So I would alert the VSCode team of this problem. Initially upon loading, it works a few times, and then it starts displaying 'Loading.' message.

@ramya-rao-a
Copy link
Contributor

@bruparel

Typescript and javascript support comes out of the box in VS Code. Therefore, please do log an issue in the VS Code repo https://github.com/Microsoft/vscode for the issue you are seeing for the typescript code.

For all other languages, features like Peek definition and Hover are implemented via extensions. The "loading.." is shown when the extension doesnt get back to VS Code in time with data for Hover or Peek Definition feature.

@ramya-rao-a
Copy link
Contributor

Closing this issue, as multiple have been logged against godef.
Using gogetdoc is an alternative.

We are looking at other options for implementing the features that depend on godef.
Will update this thread once we have something new to share.

@kuncevic
Copy link

kuncevic commented Mar 8, 2017

Same thing here, F12 always stopping working after some time and intellisense stopped working as well. Right click Go to Definition, Peek Definition - all the same. Had to restart vscode to get it back.

I am on latest vscode 1.10.2 using typescript 2.0.10
Node global version 6.9.2
Node vscode version 6.5.0

@ramya-rao-a
Copy link
Contributor

@kuncevic Can you try using the new language server feature? Set "go.useLanguageServer": true in your settings.

@ramya-rao-a
Copy link
Contributor

@kuncevic What version of the Go extension are you using?

@josh-tepper
Copy link
Author

josh-tepper commented Mar 10, 2017

I saw the same issue -- that go to def, find refs, etc. stop working after some period of time, and this behavior started when I switched go.useLanguageServer to true. Unlike kuncevic, I did not experience it beforehand (I was previously using gogetdoc). Restarting resolves, but this happens consistently and often.

I'm running the 0.6.55 version of the extension on vscode 1.10.2.

Let me know if there is anything else you need. The lang server was significantly faster than gogetdoc which I used because godef is broken. Nonetheless, when useLanguageServer is true, the tooling stops working after only 30min so I can't really use this configuration.

@ramya-rao-a
Copy link
Contributor

Thanks for reporting @josh-tepper , we will track this in a separate issue #853

@kuncevic
Copy link

kuncevic commented Mar 10, 2017

@ramya-rao-a ahhh, and I am not using the go extension, I have same issue with the typescript as I did mentioned in my first comment, sorry if it was not clear enough.
Issues microsoft/vscode#20605 and microsoft/vscode#20686 quite related here. Sounds like it is not an issue with vscode-go extension itself.

@vscodebot vscodebot bot locked and limited conversation to collaborators Jan 23, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

5 participants