[compiler] Count loop reassignments as the enclosing scope reassigning the variable#36732
Merged
Merged
Conversation
mofeiZ
reviewed
Jun 15, 2026
| function sequence(props) { | ||
| const $ = _c(2); | ||
| let t0; | ||
| const $ = _c(1); |
Contributor
There was a problem hiding this comment.
makes sense that we should produce a single memo for x, merging the reassignment
mofeiZ
approved these changes
Jun 16, 2026
mofeiZ
left a comment
Contributor
There was a problem hiding this comment.
Ran this on 100k+ files internally to validate there are no unintended side effects. Looks great, let's land this
…f output A counter declared before a reactive scope and incremented inside the scope's loop is currently treated as a scope dependency: the memo block compares the counter at its pre-loop value (constant every render) but stores its post-loop value, so the comparison never matches and the scope re-executes on every render. The counter is reassigned by the scope, so it should instead be one of the scope's outputs. Repro for react#34971; the expect file documents today's incorrect output.
…g the variable A variable declared before a reactive scope and reassigned inside the scope's loop (a counter incremented via `a++` or `a = a + 1`) was emitted as a scope dependency: the memo block compared the variable at its pre-loop value but cached its post-loop value, so the comparison could never match and the scope re-executed on every render. The root cause is in InferReactiveScopeVariables: the phi-union rule only fired for phis whose value is mutated after creation, which never holds for primitive reassignments, so the counter's SSA versions were never unioned into a scope. Fix by also unioning a phi with its operands and declaration when an operand is defined at or after the phi's block, i.e. when the value is reassigned around a loop back-edge; the variable then becomes a value produced by the scope rather than a dependency. The same rule is mirrored in the Rust port's infer_reactive_scope_variables pass. Fixes react#34971. Updated for-in/sequence-expression fixtures pick up the same shape: values reassigned in loops become memoized scope outputs instead of recomputing on every render; eval outputs are unchanged.
0144c65 to
f54f582
Compare
Collaborator
Author
|
sorry, needed to rebase |
mofeiZ
approved these changes
Jun 17, 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
2 participants
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.
A counter initialized before a memo scope and incremented inside it (
a++ora = a + 1in aforbody) was emitted as a scope dependency, compared at its pre-loop value (constant every render) while the cache stored its post-loop value. The memo could never hit, so the scope recomputed on every render.Root cause: the phi-union rule in
InferReactiveScopeVariables.findDisjointMutableValuesonly unioned a phi into the scope when the phi value was mutated after creation, which range-extension only does for object mutation. Primitive reassignments around a loop back-edge never extend ranges, so the counter's SSA versions stayed outside the scope and downstream dependency propagation classified the pre-loop read as a dep.The fix unions a phi with its operands and declaration when any operand is defined at or after the phi's block, i.e. the value is reassigned around a loop back-edge. This matches the shape the compiler already produced for non-primitive loop reassignment (
x = [...x, i]). Implemented identically in the TypeScript compiler and the Rust port.Both
a++anda = a + 1variants are pinned by fixtures; the first commit documents the previously-wrong codegen, the second fixes it (counter becomes a scope output, dep oncountonly).Corpus delta beyond the new fixtures is 4 fixtures, all strict improvements with byte-identical eval output:
for-in-statement-break,for-in-statement-continue,for-in-statement-type-inference(loops previously re-ran every render, now memoized), andsequence-expression(two memo blocks collapse into one).Known limitation, unchanged from before: conditional reassignment in a loop (
for (...) { if (c) a++; }) routes through a join phi that this rule cannot see; that shape behaves as it did before this change.Verification: TS snap 1806/1806, Rust snap 1806/1806, cargo workspace green, scoped TS-vs-Rust HIR parity harness green.
Closes #34971