Stream: git-wasmtime

Topic: wasmtime / issue #4501 Add initial support for fused adap...

Wasmtime GitHub notifications bot (Jul 21 2022 at 19:35):

github-actions[bot] commented on issue #4501:

Subscribe to Label Action

cc @peterhuene

<details>
This issue or pull request has been labeled: "cranelift", "wasmtime:api"

Thus the following users have been cc'd because of the following labels:

• peterhuene: wasmtime:api

To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.

Learn more.
</details>

Wasmtime GitHub notifications bot (Jul 21 2022 at 19:43):

alexcrichton commented on issue #4501:

One thing perhaps worth mentioning here as well is the rationale for the current organization. As-is this PR adds a wasmtime_environ::fact module meaning the entire adapter compiler will be located in the wasmtime-environ crate. I chose to do this for a few reasons:

• The compiler depends on type information for components currently defined in wasmtime-environ.
• The compiler also depends on CoreDef and other definitions already defined in wasmtime-environ.
• As a standalone crate I could not come up with either a use case or an effective testing strategy. Using this requires identifying adapter module partitionings which is itself not trivial and testing felt much easier just running the whole gamut instead of trying to test individual pieces.

While it theoretically could be split out it felt like it would drag most of the component model support in wasmtime-environ with it for little benefit. I ended up concluding that it's not worth it at this time.

Eventually I think we want to refactor the wasmtime-environ crate to better suit a "wasmtime build without Cranelift" better. Right now there's lots of translation/compiler support in wasmtime-environ that is dead code if Wasmtime can't use Cranelift. I think this would be better suited as a Cargo feature, or better yet, a separate crate. My current thinking for a hypothetical "future ideal" is:

• Split out all type-level information from wasmtime-environ to.... somewhere. The wasmtime-types crate is already taken and depended on by cranelift-wasm, so some other name.
• Rename wasmtime-environ to something like wasmtime-translate. Make the wasmtime crate's dependency on wasmtime-translate conditional on the cranelift feature

That way we would still have all the shared type information in a crate for everyone to share but at compile time omitting Cranelift would also automatically omit all other compilation support.

Last updated: Dec 23 2024 at 12:05 UTC