Stream: git-wasmtime

Topic: wasmtime / PR #7888 Support finishing component types wit...


view this post on Zulip Wasmtime GitHub notifications bot (Feb 07 2024 at 19:01):

macovedj opened PR #7888 from macovedj:finish-types-without-reflection to bytecodealliance:main:

<!--
Please make sure you include the following information:

Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.html

Please ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->

As referenced in this PR, the addition of component type reflection support breaks jco's current dependence on wasmtime-environ, and since jco doesn't leverage an Engine, I'm not sure immediately aware of a good way to adapt jco. So this PR just does the simple thing and reintroduces the old finish function the new name finish_sans_reflection, right next to the one that was updated for reflection support, though if there's a way I'm missing to adapt jco, then this could be reconsidered.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 07 2024 at 19:01):

macovedj requested alexcrichton for a review on PR #7888.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 07 2024 at 19:01):

macovedj requested wasmtime-core-reviewers for a review on PR #7888.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 07 2024 at 19:03):

guybedford submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 07 2024 at 19:04):

macovedj edited PR #7888:

<!--
Please make sure you include the following information:

Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.html

Please ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->

As referenced in this PR, the addition of component type reflection support breaks jco's current dependence on wasmtime-environ, and since jco doesn't leverage an Engine, I'm not immediately aware of a good way to adapt jco. So this PR just does the simple thing and reintroduces the old finish function the new name finish_sans_reflection, right next to the one that was updated for reflection support, though if there's a way I'm missing to adapt jco, then this could be reconsidered.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 07 2024 at 19:04):

macovedj edited PR #7888:

<!--
Please make sure you include the following information:

Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.html

Please ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->

As referenced in this PR, the addition of component type reflection support breaks jco's current dependence on wasmtime-environ, and since jco doesn't leverage an Engine, I'm not immediately aware of a good way to adapt jco. So this PR just does the simple thing and reintroduces the old finish function with the new name finish_sans_reflection, right next to the one that was updated for reflection support, though if there's a way I'm missing to adapt jco, then this could be reconsidered.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 07 2024 at 19:56):

guybedford commented on PR #7888:

Can confirm this gets the tests in the JCO upgrade PR to pass on https://github.com/bytecodealliance/jco/pull/368.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 08 2024 at 03:05):

alexcrichton commented on PR #7888:

Thanks! Would it be possible to call finish as-is though? I think passing an empty PrimaryMap and empty iterators should preserve the same behavior for jco?

view this post on Zulip Wasmtime GitHub notifications bot (Feb 08 2024 at 16:13):

macovedj commented on PR #7888:

Thanks! Would it be possible to call finish as-is though? I think passing an empty PrimaryMap and empty iterators should preserve the same behavior for jco?

Yeah it seems you're right. Just pushed to the jco branch and have it pointing at wasmtime main with empty PrimaryMap and iterators.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 08 2024 at 16:19):

macovedj closed without merge PR #7888.


Last updated: Dec 23 2024 at 12:05 UTC