-
Notifications
You must be signed in to change notification settings - Fork 262
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
A few small wasm-smith
index space refactorings
#617
A few small wasm-smith
index space refactorings
#617
Conversation
Rather than represent the functions index space for components as an indirect `(nth_section, nth_enty_in_section)` pair, just store the function type directly. Eventually, this will split into a components function index space and a core function index space, and this change will make that easier.
Rather than an indirect list of `(nth_section, nth_entry_in_section)` pairs. Its more direct, and easier to work with.
…ypes Rather than an indirect list of `(nth_section, nth_entry_in_section)` pairs. This is easier to work with and more direct.
First of all, this just makes working with these types easier, and isn't an issue because they are immutable and we've already decided to generate them as is. Second, this helps us avoid issues where an aliased compound type will reference other types by index and that index is in a different types index space than where it is aliased from, and therefore it is easy to look up types in the wrong index space. An alternative would be to keep track of which index space we are talking about, but that is harder to work with than just having a reference to the type itself on hand.
This percolates down to some `wasm-encoder` types as well.
FYI, we probably need to coordinate our upcoming changes as I'm fixing up what's currently in It'll definitely impact the alias and instance sections that you're currently implementing too (specifically, different index spaces and sections for core vs. component items). I can put up a draft PR to show you what the changes currently look like. I'll review this PR shortly as this looks easy enough to rebase my work on. |
Yeah that's part of my motivation with splitting these things out from my bigger WIP PR: it should make the total amount of effort put into rebasing easier. It also makes very clear in a few places where things will become two different index spaces (see the |
Sneak peak of my spec update changes are here. That's just I'm now working on updating |
I'm going to go ahead and merge this PR, and then hold off on subsequent PRs until after your index space split stuff has landed. |
Trying to split things out of my big WIP patch that adds support for instantiating modules and components in
wasm-smith
.There will be some more things along these lines soon, but they will also involve things like recursively copying a type definition into a new index space (needed for getting
InstanceType
s andComponentType
s of instantiations and components we generate) and are a bit more involved so I figured this was a good check point.