Wasmtime GitHub notifications bot (Apr 07 2026 at 14:20): Wasmtime GitHub notifications bot (Apr 07 2026 at 14:20):arjunr2 opened PR #12981 from arjunr2:main to bytecodealliance:main:
This provides methods to compute the exact core wasm ABI encoding of param/result interface types for precise recording/replaying.
Wasmtime GitHub notifications bot (Apr 07 2026 at 14:20):arjunr2 requested dicej for a review on PR #12981.
Wasmtime GitHub notifications bot (Apr 07 2026 at 14:20):arjunr2 requested wasmtime-core-reviewers for a review on PR #12981.
Wasmtime GitHub notifications bot (Apr 07 2026 at 20:40):alexcrichton submitted PR review:
I think that the code here will end up duplicating some functionality elsewhere already in Wasmtime, especially around handling per-type flat ABIs. An example is that
crates/environ/src/fact/signature.rscontains a lot of flattening already for function signatures, although not of the exact same shape and form of here. Notably as wellTypeInformationalready has various helpers and such to push in more flat information. Would it be possible to reuse/refactor the existing implementations instead of adding another?
Wasmtime GitHub notifications bot (Apr 09 2026 at 19:02):arjunr2 commented on PR #12981:
I think
TypeInformationcould be refactored to share the implementation for this. I'll give that a shot
Wasmtime GitHub notifications bot (Apr 13 2026 at 16:40):arjunr2 updated PR #12981.
Wasmtime GitHub notifications bot (Apr 13 2026 at 16:45):arjunr2 updated PR #12981.
Wasmtime GitHub notifications bot (Apr 13 2026 at 17:01):arjunr2 commented on PR #12981:
@alexcrichton I've merged this computation with the one used for
TypeInformationnow. Let me know if this looks good
Wasmtime GitHub notifications bot (Apr 15 2026 at 21:24):alexcrichton submitted PR review:
Sorry for the delay here, but would it be possible to use the preexisting functionality instead? I'm not entirely sure what the new functions here do that the previous functions didn't, and from a subjective code-organization point of view I feel it's better to having things split up by type rather than lumped into a single function with a large
match.One part that I don't quite fully see here is how this is going to be used which is ok but also makes it a bit difficult to see. For example would it be possible to add a helper to
TypeInformationthat takes in an&InterfaceTypeand dispatches internally to calculate the right info? Or would that not make sense in this particular situation? Put another way, what's the high-level need of the record/replay that necessitates a new implementation on the side that replaces the previous implementation?
Wasmtime GitHub notifications bot (Apr 16 2026 at 16:28):arjunr2 commented on PR #12981:
The current
TypeInformationis designed only for build/compile time, and relies on cached information inComponentTypeBuilderfor non-primitive/string types. This is thrown away after compile time whenComponentTypesis formed, and thetype_informationmethod is unusable.My first thought was that we could just store these additional flat type information in the
ComponentTypes, but our earlier discussion precluded that due to unnecessary memory overhead.Thus what I've done now is refactored the internal parts of TypeInformation to pull out the core flat type computation into separate methods that can be used at build time and runtime through a
ComponentTypemethod helper.
If the worry is a single largematch, that is already being done inComponentTypesBuilder::type_information--- this is just the runtime-equivalent version.
Wasmtime GitHub notifications bot (Apr 16 2026 at 16:29):arjunr2 edited a comment on PR #12981:
The current
TypeInformationis designed only for build/compile time, and relies on cached information inComponentTypeBuilderfor non-primitive/string types. This is thrown away after compile time whenComponentTypesis formed, and thetype_informationmethod is unusable.My first thought was that we could just store these additional flat type information in the
ComponentTypes, but our earlier discussion precluded that due to unnecessary memory overhead.Thus what I've done now is refactored the internal parts of TypeInformation to pull out the core flat type computation into separate methods that can be used at build time and runtime through a
ComponentTypesmethod helper. The new methods are just extracted subsets of logic from the old methods.
If the worry is a single largematch, that is already being done inComponentTypesBuilder::type_information--- this is just the runtime-equivalent version.
Wasmtime GitHub notifications bot (Apr 16 2026 at 16:29):arjunr2 edited a comment on PR #12981:
The current
TypeInformationis designed only for build/compile time, and relies on cached information inComponentTypeBuilderfor non-primitive/string types. This is thrown away after compile time whenComponentTypesis formed, and thetype_informationmethod is unusable.My first thought was that we could just store these additional flat type information in the
ComponentTypes, but our earlier discussion precluded that due to unnecessary memory overhead.Thus what I've done now is refactored the internal parts of TypeInformation to pull out the core flat type computation into separate methods that can be used at build time and runtime through a
ComponentTypesmethod helper. The new methods are just extracted subsets of logic from the old methods.
If the worry is a single largematch, that is already being done anyway even now inComponentTypesBuilder::type_information--- this is just the runtime-equivalent version.
Last updated: May 03 2026 at 23:15 UTC