feat(lsp): complete variables

[saiintbrisson]

Adds a naive implementation of variable name completion for the current scope. Please judge! This was put together in about 1 hour of getting to know the codebase, I have no idea if it is correct.

[saiintbrisson]

Next step is probably some sort of sorting of completions based on the expected type. Better leave it to another PR

[saiintbrisson]

r-a has deeper access to information regarding the local variables, like Environment.scope has, but I gather the Gleam LS can't access an Environment?

I wasn't able to make arguments to an anon function work :(

[lpil]

Aye, the environment is an internal detail of the analysis code, by this point it does not exist. I think we would implement this by building and then inspecting a call graph.

[saiintbrisson]

@lpil I think I got it working in almost all cases (or at least those I can think of).

But here's the thing, I went with a recursive approach descending all expressions surrounding the cursor, shouldn't be a problem in most cases, but can be inefficient with complex expression chains and long statements. We can build the call graph and than keep it in memory as long as the source is valid, but I don't really know where to start and what it should look like.

Another thing bugging me is that engine.rs will eventually become a mess. Should we relocate completions to something like engine/completions.rs?

Lemme know if the current way of doing things is acceptable for now, or if you prefer we hold the idea until we have a clearer idea of how to implement it.

[lpil]

Hello! The way to implement this is to build a call graph during compilation and persist that, and then perform a lookup on that graph to get what's currently in scope.

Hold off on splitting any modules for now 👍

[lpil]

Closing due to inactivity. Please feel free to reopen! Thank you