Skip to content

CI: typed_shape_descriptors::bounded_integer_array_store_omits_layout_note_and_barrier red on main since #4957 (iota-fill idiom collapses the loop) #4985

@proggeramlug

Description

@proggeramlug

cargo-test has been failing on every PR today (#4978, #4979, #4980, #4981 — all admin-merged through it):

thread 'bounded_integer_array_store_omits_layout_note_and_barrier' panicked at crates/perry-codegen/tests/typed_shape_descriptors.rs:430:5:
bounded numeric array store should route through the raw-f64 payload helper

Bisect

Confirmed locally at both commits with cargo test --release -p perry-codegen --test typed_shape_descriptors.

Why

#4957's loop-idiom recognizer in stmt/loops.rs collapses exactly the shape this test builds —

for (let i = 0; i < arr.length; i++) arr[i] = i;

— into a single js_array_fill_f64_iota_len_extend runtime call. The per-element store is never emitted, so all three assertions (js_array_numeric_set_f64_unboxed, js_typed_feedback_numeric_array_index_set_guard, js_typed_feedback_array_index_set_fallback_boxed) can't match. The test predates the recognizer and wasn't updated in #4957.

Suggested fix

Either:

  1. Change the test body so it no longer matches the iota idiom (e.g. store i * 2 or a non-iota RHS) so it keeps covering the guarded per-element raw-f64 path, and add a separate test asserting the new js_array_fill_f64_iota_len_extend emission for the idiom; or
  2. If the recognizer is meant to subsume this shape entirely, rewrite the assertions to the fill helper.

Option 1 preserves coverage of the guard/fallback machinery, which now has no test exercising it.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions