Repository navigation
An element is stored into once the value is ready - #658
Merged
Merged
Conversation
`a[0] = f()` with `f` growing `a`: the element's address was taken while the left side was read, before the right side ran, and growing moved the elements to a new block - the store went into the one given back. The value was lost under every model, and under rc a freed block was written to (fuzzer #646, 6930). The assignment now takes the element's address again once the value is ready, from the array and the index the left side evaluated first, as JavaScript has it: a right side that assigns the variable itself (`a[1] = (a = [5], 9)`) still stores into the old array. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…er-value # Conflicts: # tslang/test/tester/CMakeLists.txt
…er-value # Conflicts: # tslang/test/tester/CMakeLists.txt
This was referenced Oct 23, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes fuzzer repro 6930 (#646), found in a fresh range past the first 1000 programs. It fails on main as well.
Why
The element's address was taken while the left side was read, before the right side ran. Growing the array moved its elements to a new block, so the store went into the old one, which had been freed. The value was lost under every model, and under rc the program also wrote to a freed block.
Fix
The assignment takes the element's address again once the value is ready. MLIRGen clones the
ts.ElementRefafter the value is computed, from the array and the index the left side already evaluated. That follows JavaScript order: a right side that assigns the variable itself (a[1] = (a = [5], 9)) still stores into the old array.Tests
tests/00element_store_after_value.tscovers:a[0] += grow(a))Verification
ctest -C Release: Windows 5278/5278 with main merged at 149646d (rc: a new array given straight to a call is held across it #649). The later merge of rc: a value stored into a local that owns nothing is not freed under it #652 was not rerun on Windows. Its code is in the combined Linux run below, and CI covers the final head.🤖 Generated with Claude Code