jfecher / ante

A safe, easy systems language
http://antelang.org
MIT License
1.9k stars 80 forks source link

Basic LSP implementation  #182

Closed ehllie closed 9 months ago

ehllie commented 9 months ago

179

I've set up the language server as a workspace for now since it makes working on the codebase easier that way. I did not copy the entire boilerplate project, but rather am just using them as reference and copying and pasting when necessary.

So far I've managed to get parsing errors displayed, and it was surprisingly straightforward

image

ehllie commented 9 months ago

I haven't done any work to make this a valid vscode extension like the template project does. Not sure if it would be in scope for the initial pr, but it would definitely make testing the server easier for people that do use it as their primary editor.

Other than that, I might need to change some String to Arc<str> since things like the Ast, and the references to paths it has, need to outlive the request parameters, and it's a little tricky to do currently with those things only being borrowed.

ehllie commented 9 months ago

This should do be a good first step. Doing a massive rewrite and removing the lifetime parameters from Location and as a result Ast as well would probably be best left for a separate PR

jfecher commented 9 months ago

@ehllie I wonder if we need to get rid of those lifetime parameters or if we can instead keep them and avoid storing the Ast in the language server. E.g. I was hoping for errors we'd just call the compiler to check the codebase and it'd return a list of errors. Currently they're printed directly, so this will be another compiler change that is needed. For jumping to locations, we'd need to find the closest item from the Ast, then jump to its definition/declaration. I don't think either of these should require storing the Ast/Locations so my hope is that we can keep the lifetime parameters and won't need too many changes on that front.

I haven't done any work to make this a valid vscode extension like the template project does.

That's fine, I think a vscode extension should be a separate repo from the language server anyway. We also don't need to worry about other users testing until we get the basics down first. Since it sounds like we both use (neo)vim we can just focus on that for the moment.