Skip to content
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: include function literals as outgoing callhierarchy calls #43438

Closed
leitzler opened this issue Dec 30, 2020 · 3 comments
Closed
Labels
FeatureRequest FrozenDueToAge gopls Issues related to the Go language server, gopls. help wanted Tools This label describes issues relating to any tools in the x/tools repository.
Milestone

Comments

@leitzler
Copy link
Contributor

What version of Go are you using (go version)?

$ go version
go version devel +6d2b3351f6 Thu Dec 10 18:34:40 2020 +0000 darwin/amd64
x/tools: 929a8494

What did you do?

Called callHierarchy/outgoingCalls from func fn():

package foo
func fn() { // Listing Outgoing calls at "fn" here returns none
	func() {
		fn2()
	}()
}
func fn2() {}

What did you expect to see?

I expected to get one result; the function literal at the line below.
The main reason is for consistency, since calling callHierarchy/incomingCalls from func fn2() will return the function literal.

What did you see instead?

No outgoing calls from fn().

@gopherbot gopherbot added Tools This label describes issues relating to any tools in the x/tools repository. gopls Issues related to the Go language server, gopls. labels Dec 30, 2020
@gopherbot gopherbot added this to the Unreleased milestone Dec 30, 2020
@KarthikNayak
Copy link
Contributor

I'm interested to pick this up!

@KarthikNayak
Copy link
Contributor

I did some investigation here and see that the problem lies here:

https://github.com/golang/tools/blob/4061312594fc4c553ddda40109133239c66553b2/internal/lsp/source/call_hierarchy.go#L218-L234

We skip going into the child nodes when the type is ast.FuncLit. So potentially:

  1. We could change the default case to return true, that way even if that type is not marked as an outgoing function call, we still check it's children to see if there is an outgoing function call
  2. We could add a case for ast.FuncLit which would return true.

I prefer 1, but I'm not sure if there are implications which can arise due to this change. Please advice!

KarthikNayak added a commit to KarthikNayak/tools that referenced this issue May 31, 2021
Currently we don't consider function literals in outgoing call hierarchy,
because we only consider expressions of type `ast.SelectorExpr` and `ast.Ident`.
So function literals are skipped. Fix this by ensuring we traverse through other
types even if we don't add the type itself as a outgoing call hierarchy.

This fixes the issue: golang/go#43438

Signed-off-by: Karthik Nayak <karthik.188@gmail.com>
KarthikNayak added a commit to KarthikNayak/tools that referenced this issue Jun 1, 2021
Currently we don't consider function literals in outgoing call hierarchy,
because we only consider expressions of type `ast.SelectorExpr` and `ast.Ident`.
So function literals are skipped. Fix this by ensuring we traverse through
'ast.FuncLit' and obtaining outgoing calls within.

Fixes golang/go#43438

Signed-off-by: Karthik Nayak <karthik.188@gmail.com>
@gopherbot
Copy link

Change https://golang.org/cl/323809 mentions this issue: internal/lsp: include function literals in outgoing call hierarchy

@golang golang locked and limited conversation to collaborators Jun 1, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FeatureRequest FrozenDueToAge gopls Issues related to the Go language server, gopls. help wanted Tools This label describes issues relating to any tools in the x/tools repository.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants