John Doty
ab477cd783
This is simpler because we don't "discover" functions to compile as we go, we just compile all the ones we can find, and functions have pre-defined exports. This is good and useful to us as we can now refer to functions in different modules by known indices, but it *does* make me wonder what we're going to do for compiling generic specializations. The previous technique was better for that sort of thing. This is all predicated on the idea that I want to have partially-compiled modules, which I can't really say why I want it. If I'm happy to just compile things cross module in the same kind of space then it's much easier to go back to the function key way of working.
6 lines
No EOL
498 B
Text
6 lines
No EOL
498 B
Text
- The Export enum is stupid I think, for runtime modules. Why do we even have them? We should just put all the names in, like Declaration {} but for runtime.
|
|
|
|
- Module IDs must be globally resolvable from within a given semantics object
|
|
- When adding PANIC instructions, push a diagnostic that I find if I can find one instead of a hard-coded string.
|
|
|
|
- runtime should have `new` with 0 args and `with_loader<T : ModuleLoader>` that does the boxing, and `new` should just make the standard one |