fix(arrays): a spread inside an associative literal is no longer discarded by the parser

[Guikingone]

$idx = [3, 4];
$a = [...$idx, "c" => 8];
count($a);          // PHP: 3   was: 1 — the spread's entries were gone, silently

The spread never reached the AST

The issue points at lower_hash_spread_into_hash_from_value's Op::ArrayToHash promotion. That
helper is never called for this shape: --emit-ir shows hash_new capacity=1 and no
hash_spread at all.

ExprKind::ArrayLiteralAssoc is a list of key/value pairs and a spread has no key, so the parser
dropped it — in two places. The ellipsis arm pushes only if !is_assoc, and
promote_indexed_array_items_to_assoc — which runs when a => turns an indexed literal
associative — continues on a Spread element. The second is how [...$idx, "c" => 8] loses it.

So the issue's perimeter is too narrow. It reports an indexed source; every source kind was
dropped, including an associative one that skips the promotion entirely:

[...["a" => 1, "b" => 2], "c" => 8]     // was 1,  PHP 3
[...[5 => 7], "c" => 8]                 // was 1,  PHP 2
[...["x", "y"], "c" => "z"]             // was 1,  PHP 3

A spread is now carried as a pair whose both halves are the Spread marker.
ArrayLiteralAssoc keeps its shape, because giving it an item enum is a 145-reference refactor
across ~110 files — and Spread is an ordinary ExprKind that every generic key/value walker
already meets inside an indexed literal, so none of them needs a new arm and the duplication only
makes such a walker visit the source twice, which is conservative.

A key computed at parse time cannot follow a spread

How many keys a spread contributes is a runtime fact, so an automatic key assigned to an unkeyed
element after one is always a guess:

[1, ...[3, 4], 5, "c" => 8]     // was 4 entries: the 5 took key 1 and overwrote the spread's 3

Such an element is now spread as a one-element array, which asks the runtime for the same
next-free-integer key PHP uses. That is the only place the number is known.

A consuming conversion, handed a borrowed source

Op::ArrayToHash consumes its source — the conversion routes an indexed array through
__rt_array_hash_union and then __rt_decref_arrays the input, which the emitted assembly shows
plainly. Right where the promotion replaces a local's own value; wrong for a spread. Once the
spread actually ran, the source was freed under the caller: count($idx) answered 0.

So the promotion gets a reference of its own — but only when the source is read out of storage that
keeps its own reference. That takes two facts, and all three reviewers found the first cut
short of one or both:

the fact	the shape that proves it	what went wrong
the slot's kind, not just the op	[...($c ? [1, 2] : [3, 4]), "c" => 8]	take_owned_temp loads a hidden OwnedTemp and clears it without releasing, so it hands over the only reference; acquiring another leaked one array per evaluation — 40 live blocks over 40 iterations
the op list must be complete	[...C::$stat, "c" => 8]	a static property is read with no retain and the symbol goes on owning it — the same shape as LoadStaticLocal under another name — so omitting LoadStaticProperty freed the class's array, and spreading it twice was a double free

value_is_owning_temporary cannot make this call either way: it answers TRUE for a plain
load_local of an array by design, as a provisional owner whose release the builder prunes later
if the slot stays concrete. That machinery exists to make a release safe, not an acquire.

Both shapes were reproduced against host PHP before the fix and after it, and both are now
regression tests.

Two reviewer findings did not reproduce, recorded because the reasoning was sound: a typed
instance-property source ([...$o->items, "c" => 8]) and a nested-literal source
([...[...$idx, "k" => 1], "c" => 8]) both match host PHP and are heap-clean. Both reviewers
flagged their own confidence as medium or low and named the emitter they had not read; the property
read does materialize an owned value.

Verification

19 shapes measured against host PHP 8.5.10, aarch64. PHP's renumbering is matched rather than
approximated: [...[5 => 7], "c" => 8] answers at key 0, and array_keys() gives [0, 'c'] on
both sides.

Unchanged: an indexed spread into an indexed literal, and an associative spread into one — both
already worked and take different helpers.

All thirteen suites green on this commit, 6848 tests:

suite	result
assoc_literal_spreads	15 passed, 0 failed
arrays::	753 passed, 0 failed, 1 ignored
callables::	575 passed, 0 failed
oop::	621 passed, 0 failed
runtime_gc::	307 passed, 0 failed
strings::	394 passed, 0 failed
regressions::	520 passed, 0 failed
closures::	98 passed, 0 failed
generators::	85 passed, 0 failed
spl::	258 passed, 0 failed
eval	1280 passed, 0 failed
error_tests	1544 passed, 0 failed
parser_tests	398 passed, 0 failed

Nine behaviour tests in tests/codegen/arrays/assoc_literal_spreads.rs, six heap-debug tests in
tests/codegen/runtime_gc/assoc_literal_spreads.rs — the source kinds separately, because they sit
on opposite sides of the retain gate.

Known not fixed, reported on the issue

The issue's second symptom — new $k(...$intkeyed, ...$idx) — does not compile on this base at
all: EIR validation failed: OperandTypeMismatch { expected: "Heap(Array)", actual: Heap(Hash) },
with the identical InstId before and after this change. I verified that by reverting the whole
patch, rebuilding and re-running. The issue reports a segfault there, so that shape changed between
c59e49b5de and 89a923f4b4 for unrelated reasons.

Closes #1049.

🤖 Generated with Claude Code

https://claude.ai/code/session_01KSAAWPyNBq6dP2b5puN3wr

[greptile-apps]

Confidence Score: 4/5

The PR is not safe to merge until automatic key assignment is corrected for unkeyed elements following a spread in an already-associative literal.

Findings

1.  Trailing elements overwrite spreads ▶

Fix with agent prompt

### Issue 1
src/parser/expr/prefix.rs:529-540
When a spread appears after the literal has already become associative, a following unkeyed element still receives the parser's static `next_auto_key`. For `["c" => 8, ...[3, 4], 5]`, the spread inserts runtime keys `0` and `1`, but the trailing `5` is then stored at key `0`, overwriting `3`. The result has three entries instead of PHP's four. Unkeyed elements parsed after an associative-position spread need runtime key assignment, as the promotion path already does for earlier positional elements.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

This PR preserves spreads inside associative array literals, adds spread-aware type inference and lowering, and balances ownership around the consuming indexed-array-to-hash conversion. It also adds broad behavior and heap-debug regression coverage.

• Retains spread operands when parsing or promoting an associative literal.
• Lowers retained spreads through the existing hash-spread runtime path.
• Adds checker and EIR storage typing for spread-contributed keys and values.
• Retains borrowed indexed-array sources before their consuming promotion.
• Adds end-to-end output and ownership tests across source forms.
• One automatic-key path remains incorrect for unkeyed elements appearing after a spread in an already-associative literal.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
    A[Parse array literal] --> B{Keyed entry seen?}
    B -- No --> C[Indexed items]
    B -- Yes --> D[Associative key/value pairs]
    C --> E[Promote earlier items]
    E --> D
    D --> F{Pair is spread marker?}
    F -- Yes --> G[Lower source through HashSpread]
    F -- No --> H[Lower key and value through HashSet]
    G --> I[Runtime assigns next integer keys]
    H --> J[Parser-assigned key]
    I --> K[Resulting hash]
    J --> K

Loading

_{Reviews (1) · Last reviewed commit: "fix(arrays): a spread inside an associat..."}

[greptile-apps]

Trailing elements overwrite spreads

When a spread appears after the literal has already become associative, a following unkeyed element still receives the parser's static next_auto_key. For ["c" => 8, ...[3, 4], 5], the spread inserts runtime keys 0 and 1, but the trailing 5 is then stored at key 0, overwriting 3. The result has three entries instead of PHP's four. Unkeyed elements parsed after an associative-position spread need runtime key assignment, as the promotion path already does for earlier positional elements.

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/parser/expr/prefix.rs
Line: 529-540

Comment:
**Trailing elements overwrite spreads**

When a spread appears after the literal has already become associative, a following unkeyed element still receives the parser's static `next_auto_key`. For `["c" => 8, ...[3, 4], 5]`, the spread inserts runtime keys `0` and `1`, but the trailing `5` is then stored at key `0`, overwriting `3`. The result has three entries instead of PHP's four. Unkeyed elements parsed after an associative-position spread need runtime key assignment, as the promotion path already does for earlier positional elements.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.