Lsp/inlay hints on pipe

[ascandone]

edit: in addition to the inlay hints on pipelines, this PR also implements inlay hints for functions' parameter types (via the gleam.inlayHints.parameterTypes option) and for functions' return type (via the gleam.inlayHints.returnTypes option)

---

Implements #3291

This PR shows inlay hints with the type of a pipeline step (only for pipeline expressions that span across multiple lines). Hints won't be shown for literal values (ints, floats, strings, bitstrings
The functionality is toggled via the gleam.inlayHints.pipelines client config option

The PR is meant to be read as a whole (not commit by commit - however the config functionality is implemented in a single commit: 9e12629)

Here's the vscode client PR: gleam-lang/vscode-gleam#82

How to activate hints

Vscode

Once the vscode client pr is merged, it will be possible to toggle the option via the vscode settings

Sublime text

The user will need to enable the functionality in the settings of the LSP sublime extension:

{
  "clients": {
    "gleam": {
      "settings": {
        "gleam.inlayHints.pipelines": true
      }
    }
  },
}

Nvim

The user will need to enable the functionality in the init.lua file:

require'lspconfig'.gleam.setup{
  settings = {
    gleam = {
      inlayHints = {
        pipelines = true,
      },
    },
  },
}

Future development

• handle hover on inlay hints (e.g. show type doc)
• handle click on inlay hints (e.g. goto definition or add annotations)
• other possible inlay hints:
  • function calls args, e.g. my_fn(/*param_name*/0, /* other_param*/ 100)
  • local let bindings, e.g. let x/*: Int*/ = my_fn(). Same for use bindings
  • bindings of case patterns

Credits

The part of the pr about config is partially based upon this previous pr #2393

[ascandone]

Hi @lpil the PR is almost ready for review.
Is it ok for it to implement the feature without including a switch in the config (for now)?

If not, could we consider merging the PR (once it's reviewed) as dead code? (e.g. setting the inlay_hint_provider option as false in the capabilities config)
This would decrease the risk of having conflicts while I try to implement the config part (that would also involve a PR on the client)

[lpil]

Is it ok for it to implement the feature without including a switch in the config (for now)?

How would the programmer turn it on in this case? I think they need to be able to turn it on and add as needed in a straightforward fashion.

[ascandone]

Is it ok for it to implement the feature without including a switch in the config (for now)?

How would the programmer turn it on in this case? I think they need to be able to turn it on and add as needed in a straightforward fashion.

It wouldn't be possible. What I was proposing was either:

1. To just implement the feature without allowing to turn it off (for now)
2. To merge the feature as dead code, and then right after try to implement another PR to create the option in the config. This would just reduce the odds of having git conflicts in case I take too much time implementing the config part

Otherwise I can just try to implement the config part in this PR

[ascandone]

@lpil I think that should be it 🙂
(sorry for the ping, I didn't know if marking the PR as ready already sends you a notification)

[ascandone]

@lpil I've updated the PR with the description of how to turn the feature on. In general, it requires setting to true the gleam.inlayHints.pipelines client config option, but every editor has it's way to do that

Depending on the editor, there could be ways to turn it on momentarily (e.g. with a keyboard shortcut)
E.g. this (untested) config (took from here)

if client and client.server_capabilities.inlayHintProvider and vim.lsp.inlay_hint then
    map('<leader>th', function()
        vim.lsp.inlay_hint.enable(not vim.lsp.inlay_hint.is_enabled())
    end, '[T]oggle Inlay [H]ints')
end

[lpil]

Great stuff! Thank you very much for waiting too, I've nearly got through all the compiler PRs 😅

[lpil]

snake_case please, we never use camelCase

[ascandone]

update: I noticed that for a better integration with vscode, it's better to use camelCase instead
you can take a look at how it is rendered in the client side pr: gleam-lang/vscode-gleam#82

[lpil]

Shouldn't this be an error?

[lpil]

When would it be valid for there to be a response that we don't have a handler for? Or there being a handler but no result in the response?

[ascandone]

Sorry for keeping it open for a long time; I had less time recently but I might able to make it to the finish line in the following days

[lpil]

Hello! Sorry, just catch up after my holiday. Is this ready for review?

[ascandone]

Hello! Sorry, just catch up after my holiday. Is this ready for review?

Hi Louis, sorry about the wait - I have been a little busy too. There are still a couple of things missing but I should be able to take care of them this week

[ascandone]

Hey @lpil everything should be good to go, except for this couple of bits where I am not sure how to handle error within MessageBuffer handlers

gleam/compiler-core/src/language_server/messages.rs

Lines 253 to 257 in 8b63e33

	fn configuration_update_received(&mut self, result: serde_json::Value) -> Next {
	let parsed_update_items: Result<(Configuration,), _> = serde_json::from_value(result);
	let Ok((parsed_config,)) = parsed_update_items else {
	return Next::MorePlease;
	};

gleam/compiler-core/src/language_server/messages.rs

Lines 271 to 280 in 8b63e33

	fn response(&mut self, response: lsp_server::Response) -> Next {
	if let Some(handler) = self.response_handlers.remove(&response.id) {
	if let Some(result) = response.result {
	return self.handle_response(handler, result);
	}
	}
	// We do not use or expect responses from the client currently.
	Next::MorePlease
	}

Should I add a new variant to the Next enum? Or return Next::Stop ?

[giacomocavalieri]

Hello! The CI deps validation problem should be solved on main, it should go away if you rebase on main :)