haskell
Support `textDocument/typeHierarchy` request
New feature in LSP 3.17: https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_prepareTypeHierarchy
Looks like something we gotta have.
Feels like a bit of shoehorning but I'm probably misunderstanding. It seems to mean supertype and subtype as in inheritance, no?
How is it gonna map to Haskell? I assume supertype of foo . bar will show composition type (isn't there another request for that already?) but what subtype will show?
Right, I didn't read it carefully enough, I suppose the only case where super- and subtype have any meaning is with type classes.
Personally, I inferred this command to give me the same thing as the call hierarchy but for types, so finding all types that reference the type A, or showing all types that are referenced by A, allowing you to expand this type reference graph.
Perhaps we can shoehorn this behaviour into the existing CallHierarchy, or TypeHierarchy is kind of/maybe still fine for such an operation?
Perhaps we can shoehorn this behaviour into the existing CallHierarchy, or TypeHierarchy is kind of/maybe still fine for such an operation?
I believe shoehorning it into TypeHierarchy would be ok (maybe add a note in readme/docs about that behaviour). Hacky, but LSP seems to be mostly tailored for OOP languages so I guess it's fine if the hack is consistent in HLS even if it's not strictly what spec implied.
I'd prefer if it (all types that reference the type A, or showing all types that are referenced by A) was implemented as TypeHierarchy rather than be a part of CallHierarchy. Technically a type constructor may be a function that creates a value of a type but I prefer to think of constructors as part of type definition hence TypeHierarchy rather than CallHierarchy. Also, if (I think it's already is?) put into CallHierarchy makes CallHierarchy too bloated.
The type hierarchy stuff pretty explicitly refers to sub- and super-types, so I think it would be a bit odd to use it for the "reference hierarchy" use case. We've generally been mapping the sub-/super-type stuff onto typeclasses indeed.
I actually think it could make sense to include type references in "call hierarchy", because types appear in values. So in some ways it would make sense to have the type reference hierarchy join up with the value reference hierarchy!
