RR #3:Flat type computation for interface types for RR

[arjunr2]

This provides methods to compute the exact core wasm ABI encoding of param/result interface types for precise recording/replaying.

[alexcrichton]

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.rs contains a lot of flattening already for function signatures, although not of the exact same shape and form of here. Notably as well TypeInformation already 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?

[arjunr2]

I think TypeInformation could be refactored to share the implementation for this. I'll give that a shot

[arjunr2]

@alexcrichton I've merged this computation with the one used for TypeInformation now. Let me know if this looks good

[alexcrichton]

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 TypeInformation that takes in an &InterfaceType and 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?

[arjunr2]

The current TypeInformation is designed only for build/compile time, and relies on cached information in ComponentTypeBuilder for non-primitive/string types. This is thrown away after compile time when ComponentTypes is formed, and the type_information method 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 ComponentTypes method helper. The new methods are just extracted subsets of logic from the old methods.
If the worry is a single large match, that is already being done anyway even now in ComponentTypesBuilder::type_information --- this is just the runtime-equivalent version.