Introduce wasmtime::ArrayRef and allocating Wasm GC arrays#9145
Introduce wasmtime::ArrayRef and allocating Wasm GC arrays#9145fitzgen merged 4 commits intobytecodealliance:mainfrom
wasmtime::ArrayRef and allocating Wasm GC arrays#9145Conversation
Subscribe to Label Actioncc @fitzgen DetailsThis issue or pull request has been labeled: "wasmtime:api", "wasmtime:ref-types"Thus the following users have been cc'd because of the following labels:
To subscribe or unsubscribe from this label, edit the |
alexcrichton
left a comment
There was a problem hiding this comment.
Just some minor comments 👍
| let offset = usize::try_from(offset).unwrap(); | ||
| let end = offset.checked_add(N).unwrap(); | ||
| let bytes = self.data.get(offset..end).expect("out of bounds field"); |
There was a problem hiding this comment.
Should these propagate Result to avoid panicking on out-of-bounds things?
There was a problem hiding this comment.
I realize this is preexisting but having read/write on arrays not actually return a result above felt a bit weird
There was a problem hiding this comment.
This isn't really a user-visible failure case; the only way it can fail is a bug in the runtime or the GC. Additionally, the non-vm layer is responsible for performing the various type checks and such — everything that is fallible and recoverable from the user — and this layer is just handing out bytes from the GC heap, but also makes sure that everything is in bounds to preserve our memory-safety-in-the-face-of-GC-bugs properties. Given all that, I'm inclined to leave things as they are, although I am happy to update docs if you think the docs at the top of this type aren't detailed enough.
fb14b52 to
f9a2465
Compare
This commit introduces the `wasmtime::ArrayRef` type and support for allocating Wasm GC arrays from the host. This commit does *not* add support for the `array.new` family of Wasm instructions; guests still cannot allocate Wasm GC objects yet, but initial support should be pretty straightforward after this commit lands. The `ArrayRef` type has everything you expect from other value types in the `wasmtime` crate: * A method to get its type or check whether it matches a given type * An implementation of `WasmTy` so that it can be used with `Func::wrap`-style APIs * The ability to upcast it into an `AnyRef` and to do checked downcasts in the opposite direction There are, additionally, methods for getting, setting, and enumerating a `ArrayRef`'s elements. Similar to how allocating a Wasm GC struct requires a `StructRefPre`, allocating a Wasm GC array requires an `ArrayRefPre`, and this is motivated by the same reasons.
6bbaea6 to
9e8e2f5
Compare
This commit introduces the
wasmtime::ArrayReftype and support for allocating Wasm GC arrays from the host. This commit does not add support for thearray.newfamily of Wasm instructions; guests still cannot allocate Wasm GC objects yet, but initial support should be pretty straightforward after this commit lands.The
ArrayReftype has everything you expect from other value types in thewasmtimecrate:A method to get its type or check whether it matches a given type
An implementation of
WasmTyso that it can be used withFunc::wrap-style APIsThe ability to upcast it into an
AnyRefand to do checked downcasts in the opposite directionThere are, additionally, methods for getting, setting, and enumerating a
ArrayRef's elements.Similar to how allocating a Wasm GC struct requires a
StructRefPre, allocating a Wasm GC array requires anArrayRefPre, and this is motivated by the same reasons.