I agree, lambdas should ideally not be treated specially. However, the call hierarchy implementation assumes that the position supplied in the query is that of a function name, and then it finds all references to that name (which needn't actually be in function calls).

To support lambdas, it would need to detect that the specified position is a lambda not a name, and then find "references" to the anonymous function, which could be of two forms. In the first, the lambda is bound to a name:

 f = func(...) { ... } // <-- f becomes the unofficial name of this lambda

 f() // <-- this reference to f counts as a call of the lambda

In the second, it is called directly:

defer func() { ... } () // the final "()" counts as a call of the lambda

In other cases, when the connection between the lambda and its call is too hard to detect, gopls would continue to return void results like the one you reported:

ForEach(func(x int) { ... }) // we can't find any calls of this lambda.

In that case, it might be better to ignore the lambda entirely and treat its body just like part of the enclosing function.

In that case, it might be better to ignore the lambda entirely and treat its body just like part of the enclosing function.

That sounds reasonable to me.

In that case, it might be better to ignore the lambda entirely and treat its body just like part of the enclosing function.

That sounds reasonable to me.

The quoted line was intended as just the residual part of a larger plan, but your comment made me realize that--without much more complex analysis--we can't identify calls to lambdas other than from their enclosing function, so there's no reason to distinguish them at all. That's a nice simplification. In other words, Call Hierarchy is about FuncDecls, and FuncLits are just more statements.

Change https://go.dev/cl/546736 mentions this issue: gopls/internal/lsp/source: ignore lambdas in call hierarchy