Eli Dowling (Jan 07 2024 at 05:19): Eli Dowling (Jan 07 2024 at 05:19):I made an attempt at fixing this. which you can see here: https://github.com/roc-lang/roc/pull/6361
Fixing it within an app was easy, just check to see if any shorthands in imports don't exist in the packages
Fixing it for interfaces is much harder.
The issue is caused by a number of layered things, but most fundamentally, not knowing the path for a module before we load it
When you run "roc check" on an interface with a shorthand qualified module name, we don't know where that shorthand comes from. To find that out we would need to find the place that shorthand is introduced. Some roc file that is a platform, a package or an app.
We need to change our behavior when loading and checking interface files. One option is to search up the file tree until we find a parent that imports the module we are loading and then load at least the header on the parent to get the shorthands for packages it imports into the global shorthands cache. Then proceed with loading the interface module and it's dependencies.
Or we just decide we don't care that much for now and wait for the new package syntax which fixes or simplifies this significantly.
What do we think? Is there any rough plan for when the packaging changes will land?
One other note is that in future it would be useful to build a dependency graph for use in the language server, this would allow us to incrementally recompile our modules and it would also solve this problem, you walk up the graph untill you either find the package import or don't.
Eli Dowling (Jan 07 2024 at 05:26):Also, if we choose not to fix it immediately, It's easy enough to detect the error and stop the hang at least, I've already got code to do that, just not a way to finish the checking.
Ayaz Hafiz (Jan 07 2024 at 06:28):I would wait until the new module changes are in to do the proper fix
Ayaz Hafiz (Jan 07 2024 at 06:28):THe fix for the current model is definitely not trivial, I agree
Last updated: Jul 06 2025 at 12:14 UTC