Add importize method to Resolve #1784
Conversation
This commit extends the `Resolve::assert_valid` function with more assertions about the structure of worlds notably to guarantee they are "elaborated" meaning that they always list all dependencies of imports. This is required by bindings generators and encoding. This property is already upheld internally and is intended to reflect a preexisting property with dynamic assertion checks. The underlying motivation for this is to assist in the development and fuzzing of bytecodealliance#1784.
alexcrichton
force-pushed
the
component_importize
branch
from
60b52a9
to
053e8d7
Compare
This commit extends the `Resolve::assert_valid` function with more assertions about the structure of worlds notably to guarantee they are "elaborated" meaning that they always list all dependencies of imports. This is required by bindings generators and encoding. This property is already upheld internally and is intended to reflect a preexisting property with dynamic assertion checks. The underlying motivation for this is to assist in the development and fuzzing of bytecodealliance#1784.
|
I've rebased this on #1785 and #1782 to get better assertions as well as better testing utilities. With that I've added an "Updates to importize" commit which updates the method of doing this slightly and adds a few more tests as well. My hope is that it's a bit more robust to conditionally preserve imports instead of throwing them all away and recreating them. I've then also hooked this up to fuzzing. @karthik2804 one thing I'm not certain of is that the design currently is to mutate the world in-place. I updated this to rename the world by adding |
|
I do not have strong opinions here but I think the name of the world should not matter too much. |
|
Ok in that case let's leave this as-is and see how it works out. Given that this is co-authored by me and @karthik2804 I'd prefer to not approve-and-merge, so @dicej I'm going to tag you in for a third set of eyes on this to make sure nothing looks too awry. |
This commit extends the `Resolve::assert_valid` function with more assertions about the structure of worlds notably to guarantee they are "elaborated" meaning that they always list all dependencies of imports. This is required by bindings generators and encoding. This property is already upheld internally and is intended to reflect a preexisting property with dynamic assertion checks. The underlying motivation for this is to assist in the development and fuzzing of #1784.
A new method `importize` is added to the Resolve. This is to allow to mutate the Resolve to state where it would resemble what a consuming component would expect to see during composition. Signed-off-by: karthik2804 <[email protected]>
* Update the CLI to have `--importize` and `--importize-world` * Rewrite the test to use these flags and have multiple tests in one file, each with a smaller world. * Update the implementation to preserve allow-listed imports instead of removing all imports and recreating what needs to be preserved.
alexcrichton
force-pushed
the
component_importize
branch
from
053e8d7
to
01cc0b0
Compare
A new method
importizeis added to the Resolve. This is to allow to mutate the Resolve to state where it would resemble what a consuming component would expect to see during composition.