-
Notifications
You must be signed in to change notification settings - Fork 122
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement module linker #113
Conversation
What happens when you |
Thanks for the suggestion. That would be the ideal inside something like webpack for sure, but there some complications. I don't always want to depend on bundlers either because there should be a way to do this in vanilla node as well :) (bundler related work would need to happen in the loader) I think the problem gets much more complicated when there are implicit dependencies between the two modules. Specifically the memory layout each module expects and static data sections. Each module is pre-compiled in isolation which makes this a problem. I have some ideas on how to tackle that but it seems to be pushing me more into the approach where all the Walt Program ASTs are merged and compiled together, and imports are basically hoisted onto a single module. Nowhere near implementing that though, but it'll be interesting once I do. The whole thing is kind of bumming me out because I have no idea how multiple different source languages are supposed to play nice together because of memory issues 🤔 . Kind of seems like that is unlikely to happen until maybe there are multiple memories allowed in WASM. Either way, I need to implement a couple of ideas and see how it shakes out before all the tradeoffs are known. |
Yes indeed, that makes a lot of sense. As far as I know bundlers will be a separate target in Emscripten.
For JavaScript is pretty obvious (ImportObject). For other languages it's more complicated; compiling + shared library with PIC should work or multiple modules/unmanaged closure. |
Parse all imports without compiling and collect all syntax trees in one place.
Iterate over all asts and combine statics into a global statics object.
Correctly build cross-module data sections. This also fixes cases when a non-memory/data module is imported as part of the program
Cover that memory can is not required in a module even if the rest of the program may use it
- Something is wrong with validation. Off for now in linker
- DX + 1,000,000
- Add DI compiler to the linker for diagnostics/debugging - Fix type inference where an imported method has arity > 1 - Add validation spec to cover un-patched type inferences
- Fix a bug in error generator - Add basic compiling of .wasm files to cli
- Output .wasm files - JS Wrapping to happen later
- Types must be exported before use - Add warning to linker if they are not - Syntax is still valid if not used in another module - Fix a typo in filename passed in linker validation -
Implement module imports.
It is difficult to go beyond toy examples without breaking the application into modules.
.
For example,import { a: i32 } from "./a.walt";
.Basic.
TODO:
export type
syntax supportOut of scope:
The change set here is large enough already that these features would need to be fleshed out in another set of PRs.