grain
grain copied to clipboard
feat(lsp): Add Inlay types
This pr adds inlay types which closes #1359.
This pr is marked as a draft as there is still some work that needs to be done:
- We probably want to simplify some of the type signatures (i.e function types can get very complex, might be better to just say
Function, and show the return type and param types on the actual lambda) - We probably want to add a config to the vscode extension to toggle inlay types, as you might want inlay hints like the module hints but not the types.
- We should probably decide if we want to enable inlays on
Tuple patterns,record patterns,constructor patterns
Current Demo Below:
This pr should be ready for review now.
Here I'd want us to hide hints for function definitions—they're long and get in the way of the function arguments, which already have hints on them/show much of the same information.
It'd also be cool to have hints on destructures, but that could maybe come in a later PR.
Here I'd want us to hide hints for function definitions—they're long and get in the way of the function arguments, which already have hints on them/show much of the same information.
It'd also be cool to have hints on destructures, but that could maybe come in a later PR.
I made that change, I also implemented a cli flag --disable-inlay-types which can be used to dissable the type hints when we release we can add a setting to the vscode extension that injects the flag.
I think we should leave the destructures for a future pr.
I also plan on coming back and adding type hints on function calls that show the label in a future pr.
@spotandjake can't you just disable inlay hints in the client, and then users can decide if they want them or not? What is the purpose of the flag?
@spotandjake can't you just disable inlay hints in the client, and then users can decide if they want them or not? What is the purpose of the flag?
As we add more inlays, such as parameter hints. and other inlays I can see cases where the user might want to dissable the type hints but keep the others, because of how verbose the type hints are.
After discussion in discord instead of the command line flag it would make more sense to use: https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#initialize but I think we can defer it to a separate pr when we are going to add more inlay hint types.
The final thing this pr needs is test but I don't quite understand how the new lsp tests work yet.
Tests have been added so this should be ready for a review.