fitzgen requested wasmtime-core-reviewers for a review on PR #9145.
fitzgen requested alexcrichton for a review on PR #9145.
fitzgen opened PR #9145 from fitzgen:host-allocate-gc-arrays
to bytecodealliance:main
:
This commit introduces the
wasmtime::ArrayRef
type and support for allocating Wasm GC arrays from the host. This commit does not add support for thearray.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 thewasmtime
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 withFunc::wrap
-style APIsThe ability to upcast it into an
AnyRef
and 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.<!--
Please make sure you include the following information:
If this work has been discussed elsewhere, please include a link to that
conversation. If it was discussed in an issue, just mention "issue #...".Explain why this change is needed. If the details are in an issue already,
this can be brief.Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.htmlPlease ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->
fitzgen updated PR #9145.
github-actions[bot] commented on PR #9145:
Subscribe to Label Action
cc @fitzgen
<details>
This 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:
- fitzgen: wasmtime:ref-types
To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.
Learn more.
</details>
alexcrichton created PR review comment:
Should these propagate
Result
to avoid panicking on out-of-bounds things?
alexcrichton created PR review comment:
(same for writing below)
alexcrichton created PR review comment:
I realize this is preexisting but having read/write on arrays not actually return a result above felt a bit weird
alexcrichton created PR review comment:
Could this be
std::iter::repeat(..).take(N)
?
alexcrichton submitted PR review:
Just some minor comments :+1:
fitzgen submitted PR review.
fitzgen created PR review 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.
fitzgen submitted PR review.
fitzgen created PR review comment:
Unfortunately not because
std::iter::Take
is only anExactSizeIterator
when its inner iterator is, andstd::iter::Repeat
is not anExactSizeIterator
.
fitzgen updated PR #9145.
fitzgen requested abrown for a review on PR #9145.
fitzgen requested wasmtime-default-reviewers for a review on PR #9145.
fitzgen updated PR #9145.
fitzgen has enabled auto merge for PR #9145.
fitzgen updated PR #9145.
fitzgen updated PR #9145.
fitzgen updated PR #9145.
fitzgen has enabled auto merge for PR #9145.
fitzgen merged PR #9145.
Last updated: Nov 22 2024 at 17:03 UTC