KtorZ fbe2f82582 Thread down environment module from cli down to the type-checker ... We simply provide a flag with a free-form output which acts as the module to lookup in the 'env' folder. The strategy is to replace the environment module name on-the-fly when a user tries to import 'env'. If the environment isn't found, an 'UnknownModule' error is raised (which I will slightly adjust in a following commits to something more related to environment) There are few important consequences to this design which may not seem immediately obvious: 1. We parse and type-check every env modules, even if they aren't used. This ensures that code doesn't break with a compilation error simply because people forgot to type-check a given env. Note that compilation could still fail because the env module itself could provide an invalid API. So it only prevents each modules to be independently wrong when taken in isolation. 2. Technically, this also means that one can import env modules in other env modules by their names. I don't know if it's a good or bad idea at this point but it doesn't really do any wrong; dependencies and cycles are handlded all-the-same.		2024-08-04 10:27:32 +02:00
..
lsp_project.rs	Thread down environment module from cli down to the type-checker	2024-08-04 10:27:32 +02:00
telemetry.rs	feat(lsp): enable compiling a project	2023-02-20 15:30:25 -05:00