Stream: git-wasmtime

Topic: wasmtime / PR #9145 Introduce `wasmtime::ArrayRef` and al...


view this post on Zulip Wasmtime GitHub notifications bot (Aug 19 2024 at 22:06):

fitzgen requested wasmtime-core-reviewers for a review on PR #9145.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 19 2024 at 22:06):

fitzgen requested alexcrichton for a review on PR #9145.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 19 2024 at 22:06):

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 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:

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.

<!--
Please make sure you include the following information:

Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.html

Please ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->

view this post on Zulip Wasmtime GitHub notifications bot (Aug 19 2024 at 22:19):

fitzgen updated PR #9145.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 20 2024 at 01:04):

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:

To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.

Learn more.
</details>

view this post on Zulip Wasmtime GitHub notifications bot (Aug 20 2024 at 15:09):

alexcrichton created PR review comment:

Should these propagate Result to avoid panicking on out-of-bounds things?

view this post on Zulip Wasmtime GitHub notifications bot (Aug 20 2024 at 15:09):

alexcrichton created PR review comment:

(same for writing below)

view this post on Zulip Wasmtime GitHub notifications bot (Aug 20 2024 at 15:09):

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

view this post on Zulip Wasmtime GitHub notifications bot (Aug 20 2024 at 15:09):

alexcrichton created PR review comment:

Could this be std::iter::repeat(..).take(N)?

view this post on Zulip Wasmtime GitHub notifications bot (Aug 20 2024 at 15:09):

alexcrichton submitted PR review:

Just some minor comments :+1:

view this post on Zulip Wasmtime GitHub notifications bot (Aug 20 2024 at 15:18):

fitzgen submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 20 2024 at 15:18):

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.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 20 2024 at 15:20):

fitzgen submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 20 2024 at 15:20):

fitzgen created PR review comment:

Unfortunately not because std::iter::Take is only an ExactSizeIterator when its inner iterator is, and std::iter::Repeat is not an ExactSizeIterator.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 20 2024 at 15:24):

fitzgen updated PR #9145.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 20 2024 at 16:38):

fitzgen requested abrown for a review on PR #9145.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 20 2024 at 16:38):

fitzgen requested wasmtime-default-reviewers for a review on PR #9145.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 20 2024 at 16:38):

fitzgen updated PR #9145.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 20 2024 at 16:39):

fitzgen has enabled auto merge for PR #9145.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 20 2024 at 17:35):

fitzgen updated PR #9145.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 20 2024 at 18:24):

fitzgen updated PR #9145.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 20 2024 at 19:25):

fitzgen updated PR #9145.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 20 2024 at 19:25):

fitzgen has enabled auto merge for PR #9145.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 20 2024 at 19:54):

fitzgen merged PR #9145.


Last updated: Oct 23 2024 at 20:03 UTC