Hi, is anyone already working on a language server? I would really like one, because I'm using roc in WSL2 all the time, can't have a GUI there and I also probably would want to use my default editor with all my settings, keybindings etc. If no one is working on one, I'd like to give it a go (also to learn more about the parser and compiler :nerd: )
Ayaz made a simple language server, it's available here. We don't plan on officially supporting one because we're making our own editor where we can connect with the compiler without the restrictions or the latency of the language server protocol.
Oh, that's cool, thank you for the hint :-)
As Anton mentioned it's quite naive, but if you are interested in learning more about the compiler of Roc, it could be interesting to add another feature you find valuable to it. Or, if you just want to learn more about and/or play with the compiler, we would be happy to find a project that would be interesting to work on!
On linux and on windows I get these kind of errors:
error[E0512]: cannot transmute between types of different sizes, or dependently-sized types
--> /home/itmuckel/.cargo/git/checkouts/roc-f2007fde281427d6/52fa78a/crates/compiler/mono/src/ir.rs:75:1
|
75 | roc_error_macros::assert_sizeof_non_wasm!(Expr, 9 * 8);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: source type: `ir::Expr<'_>` (640 bits)
= note: target type: `[u8; 72]` (576 bits)
= note: this error originates in the macro `static_assertions::assert_eq_size` which comes from the expansion of the macro `roc_error_macros::assert_sizeof_non_wasm` (in Nightly builds, run with -Z macro-backtrace for more info)
error[E0512]: cannot transmute between types of different sizes, or dependently-sized types
--> /home/itmuckel/.cargo/git/checkouts/roc-f2007fde281427d6/52fa78a/crates/compiler/mono/src/ir.rs:76:1
|
76 | roc_error_macros::assert_sizeof_non_wasm!(Stmt, 12 * 8);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: source type: `Stmt<'_>` (832 bits)
= note: target type: `[u8; 96]` (768 bits)
= note: this error originates in the macro `static_assertions::assert_eq_size` which comes from the expansion of the macro `roc_error_macros::assert_sizeof_non_wasm` (in Nightly builds, run with -Z macro-backtrace for more info)
any idea where they could come from?
compiling only with nix develop fixed it. :-/
Ah yes, that can occur when you tried to build with a different rust version
Just updated the language server and now I am getting unused variable warning where I don't think I was before. In the screenshot below you can see that I am using calcNextHistory
in the expect
but for some reason it is reporting this warning.
Screenshot-2023-12-09-at-19.06.16.png
Also I have noticed messages like this occurring (though I don't think this is a recent change or anything), I suspect it has been running on repeat in the background and crashing. Is there a way to have it only run on file save?
Screenshot-2023-12-09-at-19.10.13.png
Figured out where the errors are logged, this is what I see
Screenshot-2023-12-09-at-19.14.03.png
The program was in a known bad state (mid writing a function) when this occurred
This might be more of a @Ivan Demchenko VS code extension issue than language server?
Logged Issue #6227 for the unhandled parse issue.
I guess there is no way for VS Code to recover here. If the language server instantly panics all it can do it try again?
I was thinking maybe we could try once. But then wait until the file is saved before trying to restart the server? OTOH maybe this is a great way to find issues?
I've noticed I frequently need to restart the server in helix (luckily the server is so fast it is not a hassle)
The language server runs in the normal compile mode, not with expects turned on. That's an easy fix though if anyone wants to do it.
I'm pretty sure there is no way to configure a language server to only update documents on save. There might be a VSCode-specific setting but in general I think the answer is to fix the panics
No worries. Well, now that I've seen the issue I'm going to watch the server like a hawk and try to catch and fix everything that crashes it, which also has the benefit of helpong roc provide better errors. I just hadn't noticed the notification before, and wasn't sure what to do about it.
Anton said:
Ayaz made a simple language server, it's available here. We don't plan on officially supporting one because we're making our own editor where we can connect with the compiler without the restrictions or the latency of the language server protocol.
Is this information still accurate? It seems to me that LSP is basically a standard at this point, and having an officially "blessed" one would make it much easier to get people up and working in Roc with whatever editor they already have.
Is this information still accurate?
No, a language server is now included with the nightly release :)
Anton said:
Is this information still accurate?
No, a language server is now included with the nightly release :)
Great, I am going to try and get it working with Neovim and contribute the configuration upstream so future new users can have an easy setup.
Last updated: Jul 05 2025 at 12:14 UTC