cpetig edited PR #12315.
cpetig commented on PR #12315:
TODO: Check whether the standard name fixed-length lists is used over fixed size lists.
AlbertMarashi commented on PR #12315:
What's remaining for this?
cpetig commented on PR #12315:
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 updated PR #12315.
cpetig updated PR #12315.
cpetig updated PR #12315.
:memo: cpetig submitted PR review.
:speech_balloon: cpetig created PR review comment:
I found a last "size" which should be "length"
:speech_balloon: cpetig created PR review comment:
another "size" left over
:speech_balloon: cpetig created PR review comment:
should this become len() like Vec?
:speech_balloon: cpetig created PR review comment:
dito
cpetig updated PR #12315.
cpetig updated PR #12315.
cpetig has marked PR #12315 as ready for review.
cpetig requested fitzgen for a review on PR #12315.
cpetig requested wasmtime-fuzz-reviewers for a review on PR #12315.
cpetig requested wasmtime-core-reviewers for a review on PR #12315.
cpetig edited PR #12315:
Replace the todo's with proper code and add a host side test case.
Implements https://github.com/bytecodealliance/wasmtime/issues/12279
Includes all the commits on https://github.com/bytecodealliance/wasmtime/pull/10619 , so that one should be merged first.
cpetig assigned cpetig to PR #12315.
:memo: cpetig submitted PR review:
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.
:speech_balloon: cpetig created PR review comment:
I am not sure whether Alex doubt about O(n) at https://github.com/bytecodealliance/wasmtime/pull/10619#discussion_r2052556773 is applicable here. But it is worth linking the context here.
:speech_balloon: cpetig created PR review comment:
I am not sure whether Alex doubt about O(n) at https://github.com/bytecodealliance/wasmtime/pull/10619#discussion_r2052556773 is applicable here. But it is worth linking the context here.
:speech_balloon: cpetig created PR review comment:
I am not sure whether Alex doubt about O(n) at https://github.com/bytecodealliance/wasmtime/pull/10619#discussion_r2052556773 is applicable here. But it is worth linking the context here.
cpetig commented on PR #12315:
@Felix-El
fitzgen unassigned fitzgen from PR #12315 Fixed-length lists, host side.
fitzgen requested alexcrichton for a review on PR #12315.
:memo: alexcrichton submitted PR review.
:speech_balloon: alexcrichton created PR review comment:
Could this be moved to
crates/core/src/array.rsso this could get miri-testing there, and additionally enable adding#[test]for this? Additionally, this doesn't currently handle panics ofcb(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
:speech_balloon: alexcrichton created PR review comment:
This is fine yeah, it's proportional to what the guest has already done. Before this loop is done, though, can this call
consume_fuel_arrayin the same manner as lists?
:speech_balloon: alexcrichton created PR review comment:
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_typeintypes_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_mulhere should bechecked_mul, and I also don't think the conversion here tou8is right. Ifcis 1 andcountis 256 thenflat_countshould beNone, notSome(255).- I'm a little worried that in Rust below we've got
N: usizewhere the parametercount: u32has a different type here. Could there be a separate entrypoint which takescount: usizeand performs a fallible/panicking conversion asserting that thecountis less thanu32::MAX?
:speech_balloon: alexcrichton created PR review comment:
Nah this is fine, this is where there's basically no other option.
:speech_balloon: alexcrichton created PR review comment:
This is fine yeah, but similar to above can this use
consume_fuel_arraybeforehand?
cpetig updated PR #12315 (assigned to cpetig).
:memo: cpetig submitted PR review.
:speech_balloon: cpetig created PR review comment:
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.
cpetig updated PR #12315 (assigned to cpetig).
:memo: cpetig submitted PR review.
:speech_balloon: cpetig created PR review comment:
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 )
:thinking:
cpetig updated PR #12315 (assigned to cpetig).
:memo: cpetig submitted PR review.
:speech_balloon: cpetig created PR review comment:
I found a way which still feels sound to me, hopefully you agree ...
cpetig updated PR #12315 (assigned to cpetig).
cpetig updated PR #12315 (assigned to cpetig).
cpetig commented on PR #12315:
@alexcrichton would you please take another look at my latest fixes?
:thumbs_up: alexcrichton submitted PR review:
Two minor thoughts from me but otherwise looks great, thanks!
:speech_balloon: alexcrichton created PR review comment:
I realize that the likelihood of getting this wrong is pretty low, but this
asstill worries me. Couldfixed_length_list_statictake ausizeparameter directly? Either that or could this caluclation here double-check thatNfits inu32? For example:const ABI: CanonicalAbiInfo = { if N > u32::MAX as usize { panic!() } CanonicalAbiInfo::fixed_length_list_static(&T::ABI, N as u32) };I basically just don't want to have to think about the "what if
asis lossy" even if it's a niche case that may never show up in practice
:speech_balloon: alexcrichton created PR review comment:
Could
new_fixed_length_list_typebe updated to call this function? I agree that the preexisting implementation ofnew_fixed_length_list_typeis much easier to read but we'll need to have thisconst-compatible implementation anyway, so I'd prefer everything to funnel through the same function so there's still just one function to keep correct.
cpetig updated PR #12315 (assigned to cpetig).
:memo: cpetig submitted PR review.
:speech_balloon: cpetig created PR review comment:
Now a usize (at the cost of +10 lines of unlikely used error handling)
:memo: cpetig submitted PR review.
:speech_balloon: cpetig created PR review comment:
Now implemented as using the const function (which I upgraded to a usize argument).
:thumbs_up: alexcrichton submitted PR review.
alexcrichton added PR #12315 Fixed-length lists, host side to the merge queue.
github-merge-queue[bot] removed PR #12315 Fixed-length lists, host side from the merge queue.
cpetig updated PR #12315 (assigned to cpetig).
alexcrichton added PR #12315 Fixed-length lists, host side to the merge queue.
:check: alexcrichton merged PR #12315.
alexcrichton removed PR #12315 Fixed-length lists, host side from the merge queue.
Last updated: Jul 29 2026 at 05:03 UTC