Eli Dowling (Dec 23 2023 at 13:46): Eli Dowling (Dec 23 2023 at 13:46):Now that this PR is looking close to finishing I'd like to give a little summary of my view of the status of the tooling and where we can go to make it better.
I think at this point there isn't a lot more that can be done on the language server end without changes to the compiler.
There are three improvements to the compiler that would facilitate further improvements to tooling, in rough order of their impact they are:
Exposing more information about every module after they are loaded.
That would include:
What each module imports.
What each module exports.
Info about the ast of the header so that we can use those regions to detect where the cursor is for completing imports vs exports etc.
This unblocks:
completion of imported modules and built-ins, completion in import blocks, completion in export blocks. Automatic imports when accepting completions.
Code actions to add a missing import to fix an error.
Recoverable parsing making it so that we can always get type information for completion and hover, and also show diagnostics always.
Incremental output during module loading allowing us to get the most basic info about symbols and positions in a document before parsing.
We currently do some hacky stuff to allow us to get completion for an unparsed document that will break completions in rare edge cases. I tried explaining it here but it's a bit complicated, I can go into it more elsewhere.
I had a poke around trying to see what implementing 1 would look like, but frankly
I don't think I know enough about the vision for how the compiler should be architecture to make a change like that.
Once 1. Is complete I'll happily get to work adding those features I've listed to the language server. Which should be easy given the groundwork I've laid in the existing completion PR
Basically I just wanted to get a dump of all my thoughts to see what people think, and what other people's plans are.
Richard Feldman (Dec 23 2023 at 16:24):1 seems totally uncontroversial to me; if you want to make a PR that does it, I'd say go for it!
Ayaz Hafiz (Dec 27 2023 at 00:55):I think (1) is good. I'd like to also add some way so that the builtin modules are saved on the filesystem and you can actually view them when you go-to-definition; right now an empty buffer is shown.
Ayaz Hafiz (Dec 27 2023 at 00:55):(2) is a lot of work but definitely the most valuable.
Ayaz Hafiz (Dec 27 2023 at 00:58):I like the idea of (3) but we need to be careful. In the short term, I hope the module compiler is fast enough that this is not needed. At some point it will be needed, but I think it will be useful to hook into the event loop for module compilation and pull for changes, rather than the compiler pushing incremental output out.
Ayaz Hafiz (Dec 27 2023 at 00:59):As for (1), I think it's already pretty close. What you'll want to look at is the large file in the path crates/compiler/load_internal/src/file.rs. There's a lot going on there and we've talked for a long time about cleaning it up, but never have. But what will be important for (1) is to add the symbol table, which is a data structure called Scope, to the output objects of the compiler passes.
Ayaz Hafiz (Dec 27 2023 at 01:01):We will need some rework along the lines of (3) soon anyway. The most pressing issue IMO is that the LS has no hook into the event loop, so when a file changes the LS re-compiles the dependencies of that file, which is the wrong direction of what's actually desired.
Eli Dowling (Dec 29 2023 at 11:49):image.png
image.png
First draft of completion for imports, and builtins. Lots of bugs, but i think I've finally got all the data available to complete everything i want to be able to complete
Eli Dowling (Dec 31 2023 at 02:35):One area I'd like to make more progress on is getting docs for the completion and hover. I can see there is an implementation that's used for generating the website documentation that parses the ast but doesn't typecheck stuff properly but it seems pretty limited and I don't think it runs during regular analysis. Is there plans to revamp that?
Richard Feldman (Dec 31 2023 at 06:49):hm, revamp it how?
Richard Feldman (Dec 31 2023 at 06:49):right now it runs in the roc docs command, so it only does what's necessary to generate the .html files
Eli Dowling (Jan 02 2024 at 11:37):To make it generate docs using data from typechecking rather than just parsing the ast and therefore requiring type annotation for anything that needs docs.
Brian Carroll (Jan 02 2024 at 15:25):Hmm I would say if you are exporting something it's part of your public API, and you could argue it's bad practice not to annotate the type. Annotation makes sure the type signature doesn't accidentally get changed without you realising.
Richard Feldman (Jan 02 2024 at 16:15):I don't think we should require type annotations for docs. It's best practice, yes, but if you haven't gotten around to it, I don't see a reason to intentionally block you from having docs generated!
Richard Feldman (Jan 02 2024 at 16:17):I don't follow how requiring annotations would help though - unless I'm misremembering, don't we already do type checking and therefore have access to all the inferred types anyway? :big_smile:
Ayaz Hafiz (Jan 02 2024 at 17:34):I think what Eli might be saying is that right now the types of a function are only generated in the docs if you have an explicit type annotation. If there is no type annotation it won't be generated, and moreover the type annotation won't be checked for correctness. So you are required to annotate values if you want type docs for them.
Ayaz Hafiz (Jan 02 2024 at 17:35):Right now the docs are generated directly from the AST. I agree we should generate them only after type checking.
Richard Feldman (Jan 02 2024 at 17:59):ahh gotcha! Yeah agreed
Eli Dowling (Jan 02 2024 at 19:27):Yup, exactly what @Ayaz Hafiz said.
Eli Dowling (Jan 05 2024 at 04:49):For anyone wanting bleeding edge completion support, I've opened a PR for import /module name completions https://github.com/roc-lang/roc/pull/6347.
It needs some cleanup, but I've been using it and it's working really weel for me. I just got type information for built-ins working properly so this piece is pretty feature complete
At some point I'd like to expand completion to be smart based on region eg: Complete field names inside a record update, tag names inside a pattern match, external module names inside import etc but that's pretty minor I'd say
Last updated: Jul 26 2025 at 12:14 UTC