Skip to content

ci: cargo-test (required) is red on main since 83a6767ff — 33 perry-runtime typed_feedback/proxy lib tests fail; #6939 merged with the same 33 failing #6957

Closed

Description

@proggeramlug

cargo-test is a required check and it is failing on main's current HEAD 83a6767ff ("GC memory: shape-key typed layouts (#6893) + major-GC pacing; don't link CoreFoundation in every binary (#6939)"). 33 perry-runtime lib tests fail — 32 in typed_feedback::tests plus proxy::tests::object_array_numeric_write_guard_requires_complete_uniform_proof.

It came in with #6939, which merged red

PR #6939's own cargo-test run failed with exactly this set — 33/33 identical after sorting both lists. It was merged anyway. (Its lint was red too; that side is #6956.)

Reproduced on an unrelated PR that changes zero .rs files (#6954: shell script, TS test file, two text manifests, a workflow edit, docs). git diff origin/main...HEAD -- '*.rs' Cargo.toml Cargo.lock is empty there, so the failures are wholly inherited from main:

test result: FAILED. 1456 passed; 33 failed; 3 ignored; 0 measured; 0 filtered out

Sample assertions:

---- proxy::tests::object_array_numeric_write_guard_requires_complete_uniform_proof ----
panicked at crates/perry-runtime/src/proxy.rs:2052:9:
assertion `left == right` failed: finite numbers are valid in verified ordinary JSValue typed slots

---- typed_feedback::tests::typed_feedback_class_field_get_guard_requires_raw_f64_layout_when_requested ----
panicked at crates/perry-runtime/src/typed_feedback/tests.rs:1660:5:
assertion `left == right` failed

Full list (sorted): proxy::tests::object_array_numeric_write_guard_requires_complete_uniform_proof, and typed_feedback::tests:: — typed_feedback_class_field_get_guard_requires_raw_f64_layout_when_requested, typed_feedback_class_field_set_guard_fails_for_frozen_object, typed_feedback_class_field_set_guard_falls_back_for_class_setter, typed_feedback_class_field_set_guard_requires_raw_f64_value_and_layout, typed_feedback_closure_direct_guard_passes_and_rejects_bound_sentinel, typed_feedback_helper_return_guard_failure_returns_original_value, typed_feedback_helper_return_keys_use_shape_facts_not_sample_identity, typed_feedback_invalidation_counters_are_site_attributed, typed_feedback_method_direct_guard_fails_after_megamorphic_site, typed_feedback_method_direct_guard_fails_for_native_receiver, typed_feedback_method_direct_guard_fails_for_own_method_replacement, typed_feedback_method_direct_guard_fails_for_prototype_method_registration, typed_feedback_method_direct_guard_passes_for_exact_registered_method, typed_feedback_non_bounded_array_set_guard_failure_uses_jsvalue_object_fallback, typed_feedback_numeric_array_get_guard_requires_numeric_layout, typed_feedback_numeric_array_guards_reject_registered_class_ref_bits, typed_feedback_numeric_array_push_guard_rejects_mutability_restricted_arrays, typed_feedback_numeric_array_push_guard_requires_room_numeric_value_and_layout, typed_feedback_numeric_array_set_guard_requires_numeric_value_and_layout, typed_feedback_object_set_fast_falls_back_for_uncached_dynamic_key, typed_feedback_object_set_fast_hits_learned_dynamic_key_transition, typed_feedback_packed_i32_loop_guard_rejects_fractional_numeric_layout, typed_feedback_packed_u32_loop_guard_rejects_signed_fractional_and_overflow_layouts, typed_feedback_property_and_method_keys_ignore_receiver_identity, typed_feedback_registers_source_attribution, typed_feedback_roots_rewrite_shape_observations, typed_feedback_state_transitions_to_megamorphic, typed_feedback_trace_dump_honors_env_paths, typed_feedback_trace_json_includes_observed_kinds, typed_feedback_trace_json_reports_counts, typed_feedback_tracks_all_site_categories, typed_feedback_unboxed_numeric_write_falls_back_for_string_values.

Why it will keep hurting

Any PR whose ci_test_scope.py scope includes perry-runtime — which includes PRs that only add a test-files/*.ts gap test — now goes red for reasons unrelated to its diff. Combined with #6956 (lint red on the same commit) that is two of the required checks broken repo-wide.

The failing invocation is the scoped per-PR one, RUST_TEST_THREADS=1 cargo test --lib -p perry-runtime. Worth checking whether the full-workspace invocation (cargo test -p perry-runtime, all targets) still passes: if it does, feature unification across targets is masking these, and the nightly full run structurally cannot see the failure — which is how it would stay broken.

Given 83a6767ff reworked typed-shape/shape-key GC layouts and typed_feedback guards read layout bits, the guard tests asserting on raw_f64 / numeric layout are the plausible blast radius rather than a test-harness artifact.

Related: #6956 (lint red on the same commit), #6893, #6939.

Activity

  1. proggeramlug commented on Jul 29, 2026

    @proggeramlug
    ContributorAuthor

    Narrowed it on an arm64 macOS box at 83a6767ff (identical result to CI: 1456 passed; 33 failed, so this is not Linux-specific). The 33 are two different defects, and my original "feature unification" guess in the issue body was wrong:

    1. One genuine failure — proxy::tests::object_array_numeric_write_guard_requires_complete_uniform_proof. Fails standalone:

    $ RUST_TEST_THREADS=1 cargo test --lib -p perry-runtime -- --exact \
        proxy::tests::object_array_numeric_write_guard_requires_complete_uniform_proof
    test result: FAILED. 0 passed; 1 failed; ... 1491 filtered out
    panicked at crates/perry-runtime/src/proxy.rs:2052:9:
    assertion `left == right` failed: finite numbers are valid in verified ordinary JSValue typed slots
    

    This one is a real regression, and the assertion is about typed-slot layout validity — squarely in 83a6767ff's (#6893 shape-key typed layouts) blast radius.

    2. The other 32 are a test-isolation defect inside typed_feedback::tests. Each passes alone but the module fails as a group:

    invocation result
    single test, --exact (e.g. typed_feedback_registers_source_attribution) ok, 1 passed
    single test, --exact (typed_feedback_state_transitions_to_megamorphic) ok, 1 passed
    cargo test --lib -p perry-runtime typed_feedback:: (49 tests, RUST_TEST_THREADS=1) FAILED, 17 passed / 32 failed
    full lib suite, RUST_TEST_THREADS=1 FAILED, 1456 / 33
    full lib suite, default parallel threads FAILED, 1454 / 35

    So it is not cross-module pollution and not the proxy failure cascading — skipping the proxy test leaves exactly 32 failures. It is the typed-feedback registry being process-global and not reset between tests in the module. RUST_TEST_THREADS=1 does not help, because sequential execution still shares the process; and the parallel run failing more (35) is the usual signature of shared mutable global state.

    Practical consequence: these are order/population-dependent, so a filtered run can look green. Anyone bisecting this should use the full --lib invocation, not a filtered one.

  2. proggeramlug commented on Jul 29, 2026

    @proggeramlug
    ContributorAuthor

    Corroborating A/B from #6948, which tripped over this: I ran cargo test --lib -p perry-runtime at 83a6767ff in a clean worktree on an idle machine, and at a branch head whose diff does not touch typed_feedback.rs at all. Both report 33 failed, and the extracted failure lists match — 28 typed_feedback::tests::* plus proxy::tests::object_array_numeric_write_guard_requires_complete_uniform_proof.

    So this reproduces off CI, on a quiet host, with no parallelism in play — it is not a runner-contention flake.

    Caveat on my own numbers: my name-extraction regex had no digit class, so it compared 29 of the 33 by name (the packed_i32/packed_u32 family and two others were dropped on both sides equally). The 33 failed totals are from the summary lines and are directly comparable.

  3. added a commit that references this issue on Jul 29, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions