cranelift

rust jit wasm webassembly runtime wasi cranelift sandbox wasmtime

Alex Crichton e8f4f86209 Shepherd along type information in lifting/lowering (#6667 ) * Shepherd along type information in lifting/lowering This commit is a large refactor to the component runtime of Wasmtime to shepherd along type information when lifting and lowering values. Previously lifting and lowering would assume type information given context such as "surely lowering a `u32` must lower into the type `InterfaceType::U32`" or "lowering a `Val` works as it knows its own type". This is still true, and this commit isn't changing these features. The rationale for this commit instead stems from the upcoming implementation of resources in Wasmtime. Resources are trickier than all existing types in Wasmtime because what exactly is the type of a resource depends on who you're asking. For example the host might have one type called `http::Headers` but a component could import it as two distinct types: (component (import "headers1" (type $h1 (sub resource))) (import "headers2" (type $h2 (sub resource))) ;; ... ) in the above component the `$h1` and `$h2` types will each get their own table at runtime for managing their state. This means that if the host instantiates the component with `http::Headers` supplied as both types then the same type on the outside maps to two different types inside. This means that the lowering of a host-defined type into the component is now dependent on the "name" that the component has for the type, basically if the function used `$h1` or `$h2`. This overall means that the type that the component assigned for a function is significant as part of lifting and lowering. Hence the rationale for this commit, threading around this type information. The major change in this commit is updates to the `Lift` and `Lower` traits. Previously they took a mishmash of parameters and now they needed to take more parameters, so I've updated them with: * `Lift` operations take a `&LiftContext<'_>` and an `InterfaceType` as contextual information. The context stores the store, the options, and type information. The `InterfaceType` is the type that's being lifted, which would indicate which resource table to load from for example. * `Lower` operations now take a `&mut LowerContext<'_, T>` and an `InterfaceType`. The `LowerContext` is similar to its lift cousin where it stores the store, options, and type information. The different context passed in to `lift` and `load`, for example, is no longer distinguished and both simply take a `&LiftContext<'_>` which simplifies things a bit. This refactoring was pretty far reaching and touches quite a bit of the component model implementation. This is because basically everything deals with type information as types can be recursively nested in one another. I've taken the liberty to make code continue to be ergonomic/understandable where appropriate so some "shapes" of code are now different to continue to accommodate readability and maintainability. Finally it's worth noting that this should not have any actual function impact on components running today (or tomorrow). User-facing APIs haven't changed at all here and it's just the guts that are refactored. One unfortunate aspect, though, is that this is going to be a small perf hit on lifting/lowering due to the fact that type information essentially needs to be "iterated" over during the lifting/lowering process. This iteration involves index lookups in `&ComponentTypes` along with assertions that when you lower `Vec<T>` that the type is `InterfaceType::List(i)`. These assertions should always succeed, and in theory could become some sort of `unreachable_unchecked` in the future, but for now it's all left as safe checks/panics for us to optimize at a later date if necessary. * Fill out a TODO comment * Fill out more comments		1 year ago
..
src	Shepherd along type information in lifting/lowering (#6667)	1 year ago
test-helpers	Disable tests for all proc-macros (#6473)	1 year ago
tests	[wit-bindgen] provide more control over type ownership (#6648)	1 year ago
Cargo.toml	Remove `maintenance` badges from the Cargo.toml files. (#6286)	2 years ago