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

Wrong documentation when there are multiple functions with the same name #2107

Closed
segevfiner opened this issue Nov 8, 2018 · 5 comments · Fixed by mdempsky/gocode#100
Closed

Comments

@segevfiner
Copy link
Contributor

While Go doesn't support function overloading, you can still have multiple functions with the same name but with a different receiver. For example: testing has the Run function.

It seems that gocode and godef don't supply us with the receiver. But go doc does support receiving it, like so go doc testing T.Run.

Steps to Reproduce:

  1. Save as foo_test.go:
package footest

import "testing"

func TestBla(t *testing.T) {
	t.Ru
}
  1. Try to complete t.Ru.
  2. You will get the documentation for testing.B.Run instead of testing.T.Run.

Run: gocode -f=json -builtin -in=foo_test.go autocomplete 74 | python -m json.tool to see what gocode gives us, go doc testing Run to see what we get from go doc, and go doc testing T.Run for what we would have liked to get.

vscode-go v0.7.0

@ramya-rao-a
Copy link
Contributor

@segevfiner Thanks for reporting!

This is a hard problem to solve...

We cant use go doc testing T.Run because there is no way to know that we should use T.Run and not Run. We dont get that information from gocode

gocode does give the function signature which I thought I could use to get the right info from go doc testing Run which gives docs for all 3 Run() implementations.

But this wouldnt work as gocode gives us the signature as func(name string, f func(t *testing.T)) bool where as go doc testing Run returns func (t *T) Run(name string, f func(t *T)) bool

i.e since T is qualified with the package name in the gocode output but not the one from go doc, its hard to get a match.

You will get the documentation for testing.B.Run instead of testing.T.Run.

Actually the documentation for all the 3 Run() are shown (without the signature)

cc @segevfiner

@ramya-rao-a ramya-rao-a added the bug label Nov 9, 2018
@segevfiner
Copy link
Contributor Author

As I said, we will need to extend gocode and godef so that the also supply us with the receiver. Keeping backwards compatibility in mind, so we might have to add a flag so that they only print the receiver when asked.

@segevfiner
Copy link
Contributor Author

In the godef case, it's also possible to parse the function signature by our self, based on the position godef gives us, in order to figure out it's receiver, if any.

segevfiner added a commit to segevfiner/vscode-go that referenced this issue Dec 26, 2018
segevfiner added a commit to segevfiner/vscode-go that referenced this issue Dec 31, 2018
segevfiner added a commit to segevfiner/vscode-go that referenced this issue Jan 8, 2019
segevfiner added a commit to segevfiner/vscode-go that referenced this issue Jan 9, 2019
ramya-rao-a pushed a commit that referenced this issue Jan 9, 2019
…umentation (#2223)

* Use the newly added receiver output from godef to get the correct documentation

See rogpeppe/godef#105

Part of #2107

* Review fixes
@ramya-rao-a
Copy link
Contributor

Based on the current state, the problem for when using gocode was fixed with #2215

This leaves the docs that appear on hover.

@segevfiner Does this problem occur when using the language server as well?
If not, then I am inclined to close this issue in favor of using the language server

cc @stamblerre

@stamblerre
Copy link
Contributor

The language server does not have this problem, so I think we can close this issue.

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

Successfully merging a pull request may close this issue.

3 participants