Fixed-length lists, host side by cpetig · Pull Request #12315 · bytecodealliance/wasmtime

cpetig · 2026-01-11T21:12:20Z

Replace the todo's with proper code and add a host side test case.

Implements #12279

~~Includes all the commits on #10619 , so that one should be merged first.~~

github-actions · 2026-01-11T22:47:07Z

Subscribe to Label Action

cc @fitzgen

Details

This issue or pull request has been labeled: "fuzzing", "wasmtime:api", "wasmtime:c-api", "wasmtime:config"

Thus the following users have been cc'd because of the following labels:

fitzgen: fuzzing

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

Learn more.

github-actions · 2026-01-11T23:46:50Z

Label Messager: wasmtime:config

It looks like you are changing Wasmtime's configuration options. Make sure to
complete this check list:

If you added a new Config method, you wrote extensive documentation for
it.

Details

Our documentation should be of the following form:

Short, simple summary sentence.

More details. These details can be multiple paragraphs. There should be
information about not just the method, but its parameters and results as
well.

Is this method fallible? If so, when can it return an error?

Can this method panic? If so, when does it panic?

# Example

Optional example here.

If you added a new Config method, or modified an existing one, you
ensured that this configuration is exercised by the fuzz targets.

Details

For example, if you expose a new strategy for allocating the next instance
slot inside the pooling allocator, you should ensure that at least one of our
fuzz targets exercises that new strategy.

Often, all that is required of you is to ensure that there is a knob for this
configuration option in wasmtime_fuzzing::Config (or one
of its nested structs).

Rarely, this may require authoring a new fuzz target to specifically test this
configuration. See our docs on fuzzing for more details.
If you are enabling a configuration option by default, make sure that it
has been fuzzed for at least two weeks before turning it on by default.

Details

To modify this label's message, edit the .github/label-messager/wasmtime-config.md file.

To add new label messages or remove existing label messages, edit the
.github/label-messager.json configuration file.

Learn more.

cpetig · 2026-01-13T21:45:59Z

TODO: Check whether the standard name fixed-length lists is used over fixed size lists.

AlbertMarashi · 2026-02-05T04:59:23Z

What's remaining for this?

cpetig · 2026-02-06T14:37:09Z

What's remaining for this?

I didn't find the time to add a proper test case. And I (non-blockingly) wait for a new wasm-tools release to do the renaming in one row.

cpetig

I am not sure whether the O(n) constraint applies to the host side as the user always controls the data types (and dimensions) added on the host side, but if so I will gladly investigate into a different solution.

cpetig · 2026-06-14T16:21:41Z

@Felix-El

alexcrichton · 2026-06-16T21:45:35Z

+    /// Returns the abi for a fixed length list
+    pub const fn fixed_length_list_static(
+        element: &CanonicalAbiInfo,
+        count: u32,
+    ) -> CanonicalAbiInfo {
+        CanonicalAbiInfo {
+            size32: element.size32 * count,
+            align32: element.align32,
+            size64: element.size64 * count,
+            align64: element.align64,
+            flat_count: match element.flat_count {
+                None => None,
+                Some(c) => Some(c.saturating_mul(if count > 255 { 255u8 } else { count as u8 })),
+            },
+        }
+    }


I've got some miscellaneous concerns about this function, so I'm going to list them here:

This is more-or-less duplicated with new_fixed_length_list_type in types_builder.rs. Could that call this function (or a similar signature?)

I'm worried about the unchecked multiplication here because the host could declare [SomeBigStruct; HUGE_NUMBER] which exceeds 4GiB of data, and I'd want that to be a panic/error/something as opposed to the silent wrap here.

I think the saturating_mul here should be checked_mul, and I also don't think the conversion here to u8 is right. If c is 1 and count is 256 then flat_count should be None, not Some(255).

I'm a little worried that in Rust below we've got N: usize where the parameter count: u32 has a different type here. Could there be a separate entrypoint which takes count: usize and performs a fallible/panicking conversion asserting that the count is less than u32::MAX?

I thought about how to remove the duplication but this gets more difficult because one of the functions is const (this also makes the implementation less elegant as traits (and_then, try_from) don't work) and I didn't identify an obvious common dependency which is not core but component model specific.

I think I addressed all other concerns.

alexcrichton · 2026-06-16T22:05:56Z

+// this is a reimplementation of array::try_from_fn, replace once that became stable
+fn array_try_from_fn<E, F, T, const N: usize>(mut cb: F) -> Result<[T; N], E>
+where
+    F: FnMut(usize) -> Result<T, E>,
+{
+    let mut valid = 0;
+    let mut result: [MaybeUninit<T>; N] = [const { MaybeUninit::uninit() }; N];
+    let mut error: Option<E> = None;
+    for n in 0..N {
+        match cb(n) {
+            Ok(v) => {
+                result[valid].write(v);
+                valid += 1;
+            }
+            Err(e) => {
+                error = Some(e);
+                // continue to consume all input
+            }
+        }
+    }
+    if let Some(e) = error {
+        // on error drop all valid elements
+        for n in 0..valid {
+            unsafe {
+                result[n].assume_init_drop();
+            }
+        }
+        return Err(e);
+    }
+    assert!(valid == N);
+    // this is a copy of array_assume_init from stdlib to avoid requiring nightly
+    Ok(unsafe { (&result as *const _ as *const [T; N]).read() })
+}


Could this be moved to crates/core/src/array.rs so this could get miri-testing there, and additionally enable adding #[test] for this? Additionally, this doesn't currently handle panics of cb (leaks intermediate results) and a few more casts than I think are necessary.

I sketched out what I'm thinking here and feel free to copy that into this PR

Sadly that implementation is only possible with 1.95 up (AsMut on Uninit array, see https://doc.rust-lang.org/beta/core/mem/union.MaybeUninit.html#impl-AsMut%3C%5BMaybeUninit%3CT%3E%5D%3E-for-MaybeUninit%3C%5BT;+N%5D%3E )
🤔

I found a way which still feels sound to me, hopefully you agree ...

…odealliance#12315)

cpetig mentioned this pull request Jan 11, 2026

Minimal implementation of fixed-length lists to enable wit-bindgen runtime tests #10619

Merged

github-actions Bot added fuzzing Issues related to our fuzzing infrastructure wasmtime:api Related to the API of the `wasmtime` crate itself wasmtime:c-api Issues pertaining to the C API. wasmtime:config Issues related to the configuration of Wasmtime labels Jan 11, 2026

cpetig commented Jan 12, 2026

View reviewed changes

Comment thread crates/wasmtime/src/runtime/component/func/typed.rs Outdated

cpetig changed the title ~~Fixed size list, host side~~ Fixed-length lists, host side Jan 13, 2026

alexcrichton added this to Implement WIT Fixed-Length-Lists Jan 14, 2026

github-project-automation Bot moved this to Todo in Implement WIT Fixed-Length-Lists Jan 14, 2026

cpetig force-pushed the fixed-size-list-host branch from 8d18537 to 9157634 Compare June 11, 2026 22:38

cpetig commented Jun 13, 2026

View reviewed changes

Comment thread crates/environ/src/component/types.rs Outdated

Comment thread tests/all/component_model/fixed_length_list.rs Outdated

Comment thread tests/all/component_model/fixed_length_list.rs Outdated

Comment thread crates/wasmtime/src/runtime/component/types.rs Outdated

cpetig marked this pull request as ready for review June 14, 2026 00:20

cpetig requested review from a team as code owners June 14, 2026 00:20

cpetig requested review from fitzgen and removed request for a team June 14, 2026 00:20

cpetig self-assigned this Jun 14, 2026

cpetig moved this from Todo to In Progress in Implement WIT Fixed-Length-Lists Jun 14, 2026

cpetig commented Jun 14, 2026

View reviewed changes

Comment thread crates/wasmtime/src/runtime/component/values.rs Outdated

Comment thread crates/fuzzing/src/oracles/component_api.rs

Comment thread crates/wasmtime/src/runtime/component/values.rs Outdated

fitzgen requested review from alexcrichton and removed request for a team and fitzgen June 15, 2026 16:29

alexcrichton reviewed Jun 16, 2026

View reviewed changes

implement fixed size lists host side

1b386f7

cpetig added 15 commits June 20, 2026 09:59

fix compilation

86a1b6f

add enough implementation to make wasmtime compile

813abde

rustfmt

4445c7f

fixed_(size is now length)_list

fb86170

fix clippy and other tests

fb37bea

fixed length list test

f41a2f9

correct code for test

20745f0

separate the functionality which should become core

d20a9b9

replace multiplication by addition

ee41603

use length instead of size consistently

2110c2c

fix clippy

7ee491e

prefer checked multiplication and conversion

3299f62

checked multiplication

ac1467b

move array_try_from_fn to core crate

c6cfe75

use Alex' implementation and the matching tests (see comment on bytec…

be79c14

…odealliance#12315)

cpetig force-pushed the fixed-size-list-host branch from 7e7faa7 to be79c14 Compare June 20, 2026 23:05

cpetig added 3 commits June 21, 2026 01:26

add missing docs and correct crate path

07ccf91

fix the MSRV by working around missing MaybeUninit methods

175e9b7

fix the doctest (facepalm)

c8a031d

Conversation

cpetig commented Jan 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions Bot commented Jan 11, 2026

Subscribe to Label Action

Uh oh!

github-actions Bot commented Jan 11, 2026

Label Messager: wasmtime:config

Uh oh!

Uh oh!

cpetig commented Jan 13, 2026

Uh oh!

AlbertMarashi commented Feb 5, 2026

Uh oh!

cpetig commented Feb 6, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

cpetig left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

cpetig commented Jun 14, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

alexcrichton Jun 16, 2026

Choose a reason for hiding this comment

Uh oh!

cpetig Jun 20, 2026

Choose a reason for hiding this comment

Uh oh!

alexcrichton Jun 16, 2026

Choose a reason for hiding this comment

Uh oh!

cpetig Jun 20, 2026

Choose a reason for hiding this comment

Uh oh!

cpetig Jun 21, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

cpetig commented Jan 11, 2026 •

edited

Loading