Support for function call hierarchy

[jneira]

(From https://github.com/mpickering/ghcide/issues/18)

• It is a feature common in other ides like eclipse or intellij
• It shows the graph of all transitive calls of a function, in a tree:
  • The nodes are selectable (shows info in the right pane) and navigable with ctrl+click
  • In the right pane other info like the possible multiple calls in the same funcion, with the line number (also navigables to the concrete line)

• It could use @wz1000 HieDB, like the recent find references implementation
• It is supported in lsp 3.16:
  • https://microsoft.github.io/language-server-protocol/specifications/specification-3-16/
  • https://github.com/microsoft/language-server-protocol/issues/468

[wz1000]

LSP 3.16 is not out yet

[alanz]

LSP 3.16 is not out yet

It is now.

[July541]

To whom it may concern, I'm tackling this feature as my GSoC 2021 works. I make this comment to avoid duplication:)

[July541]

Hello all, currently I am focusing on extract kind and span info from HieAST, and some details baffled me.

1. the record field has two components, and the RecField is about Int, and another out target a is relevant to ValBind. see https://github.com/July541/haskell-language-server/blob/7a8979d7576e1e5d39e2f32f09511b1090925881/plugins/hls-call-hierarchy-plugin/test/Main.hs#L48
2. type family and data family are all under FamDec, the span for type family is the whole expression like type family A, but the span for data family for example data family A is just the keyword data family without A. see https://github.com/July541/haskell-language-server/blob/7a8979d7576e1e5d39e2f32f09511b1090925881/plugins/hls-call-hierarchy-plugin/test/Main.hs#L103

   ---

   @wz1000, it'd be appreciated if you have time to take a look at it.

[July541]

The original reachable query in HieDb is for the whole graph, which not satisfy the call hierarchy that only requires one-hop vertexes. So I wrote some additional queries in my plugin, it has initial workability but still needs a deeper query to distinguish multi type with the same name like typeclass.

---

I still take much time to differentiate the behaviors between FOIs(file of interest) and non-FOIs, it seems FOIs can not extract HieAst from Shake, which cause it must require HieDb result.

By the way, VSCode implemented call hierarchy support but ignored the data field, not know why.https://github.com/microsoft/vscode/issues/127853

[pepeiborra]

The original reachable query in HieDb is for the whole graph, which not satisfy the call hierarchy that only requires one-hop vertexes. So I wrote some additional queries in my plugin, it has initial workability but still needs a deeper query to distinguish multi type with the same name like typeclass.

Would it be better to move this discussion to the #1955 PR? I think that @wz1000 suggested the use of hiedb there.

I still take much time to differentiate the behaviors between FOIs(file of interest) and non-FOIs, it seems FOIs can not extract HieAst from Shake, which cause it must require HieDb result.

Can you clarify this remark? Both FOIs and non-FOIs are able to request HieAst via use GetHieAst. It's only during startup that the hiedb is used to locate the hie file for non FOIs.

[July541]

Both FOIs and non-FOIs are able to request HieAst via use GetHieAst.

@pepeiborra Can I understand this as GetHieAst has the same result for both FOIs and non-FOIs?

For HieDb discussion, I'll push some code later as support.

[pepeiborra]

Both FOIs and non-FOIs are able to request HieAst via use GetHieAst.

@pepeiborra Can I understand this as GetHieAst has the same result for both FOIs and non-FOIs?

Yes, as far as I can tell.

[July541]

To whom it may concern, the call hierarchy has basic functions.🚀🚀🚀

[jneira]

Many, mant thanks @July541 for implementing this long time awaited feature. It has been really welcomed by users. So closing this with a big :tada: