fix: catch parameter alias handling and snapshot updates for noBackwardRangeExtension

[everettbu]

Mirror of facebook/react#35934
Original author: fresh3nough

---

Summary

Fixes failing compiler snapshot tests introduced by the noBackwardRangeExtension changes for method call receivers.

Problem

The noBackwardRangeExtension heuristic in InferMutationAliasingRanges.ts walks backward through alias edges to detect function call results (identified by having maybeAliases). However, catch parameters are aliased to call results in try blocks via terminal Alias effects. This caused the heuristic to incorrectly treat catch parameters as independently-memoizable function call results, preventing backward range extension and causing:

• 4 compiler crashes (Invariant: Expected a break target) when try-catch blocks got split across reactive scopes
• 1 snapshot regression where catch-aliased values were incorrectly scoped separately

Fix

Track catch handler binding identifiers in AliasingState.catchParams. During the backward-alias walk in mutate(), stop traversal when a catch parameter is encountered. This prevents the heuristic from walking through catch parameter aliases to reach call results with maybeAliases.

Changes

• InferMutationAliasingRanges.ts: Added catchParams: Set<Identifier> to AliasingState, populated from maybe-throw terminal Alias effects, and checked during the backward-alias heuristic walk
• 8 snapshot updates: Updated .expect.md files for tests where the noBackwardRangeExtension change produces different but functionally correct memoization output (all eval outputs remain correct)

Tests fixed

• try-catch-try-value-modified-in-catch (and propagate-scope-deps-hir-fork variant)
• try-catch-try-value-modified-in-catch-escaping (and propagate-scope-deps-hir-fork variant)
• try-catch-alias-try-values

Closes react/react#35902

[greptile-apps]

Greptile Summary

This PR combines two changes: (1) a fix for the noBackwardRangeExtension heuristic in the React compiler that was incorrectly treating catch parameters as independently-memoizable function call results, causing 4 compiler crashes and 1 snapshot regression in try-catch blocks, and (2) support for detecting HOF-wrapped components (const MyComponent = wrap(() => {})) in both the compiler's getFunctionName and the ESLint plugin's checkTopLevelNode heuristic.

• Catch parameter fix: Adds catchParams: Set<Identifier> to AliasingState populated from maybe-throw terminal Alias effects, and stops the backward-alias walk when a catch parameter is encountered. This is a well-targeted fix that prevents scope boundary violations in try-catch blocks.
• HOF-wrapped component detection: Extends getFunctionName in Program.ts to recognize functions passed as arguments to call expressions assigned to variables, and broadens the ESLint pre-filter to include CallExpression init types. New test coverage for both immutability and set-state-in-effect rules.
• 8 snapshot updates reflect the improved memoization granularity from the noBackwardRangeExtension changes — function call results (e.g., makeArray(), new Highlight(), fbt._()) are now independently memoized rather than being merged into larger reactive scopes.

Confidence Score: 4/5

• This PR is safe to merge — the core fix is well-reasoned with thorough comments, and all snapshot updates reflect expected behavior changes.
• The catch parameter handling logic is correct: effect.into is the catch binding, only maybe-throw terminals produce Alias effects, and the backward-alias walk guard prevents the identified class of crashes. The HOF detection changes are structurally sound. The snapshot changes consistently show improved memoization granularity. Score reflects the complexity of the aliasing state machine changes and the importance of the scope boundary fix.
• Pay close attention to InferMutationAliasingRanges.ts — it contains the core fix with the most complex logic changes around the backward-alias walk and skipRangeExtension propagation.

Important Files Changed

Filename	Overview
compiler/packages/babel-plugin-react-compiler/src/Inference/InferMutationAliasingRanges.ts	Core fix: adds catchParams tracking to AliasingState and a backward-alias walk guard to prevent catch parameters from being incorrectly identified as function call results. Also threads noBackwardRangeExtension and skipRangeExtension through the mutation traversal. Logic is sound and well-commented.
compiler/packages/babel-plugin-react-compiler/src/Inference/InferMutationAliasingEffects.ts	Sets noBackwardRangeExtension for method call receivers (where receiver !== function) in the default Apply handler. Clean, targeted change.
compiler/packages/babel-plugin-react-compiler/src/Inference/AliasingEffects.ts	Adds optional noBackwardRangeExtension field to MutateTransitiveConditionally effect type. Minimal, backward-compatible type change.
compiler/packages/babel-plugin-react-compiler/src/Entrypoint/Program.ts	Adds CallExpression parent detection in getFunctionName for HOF-wrapped components (e.g., const MyComponent = wrap(() => {})). Previous review flagged IIFE concern but the AST path check is structurally correct for the argument position.
packages/eslint-plugin-react-hooks/src/shared/RunReactCompiler.ts	Adds CallExpression to the heuristic init type check in checkTopLevelNode for HOF-wrapped components. Slightly broadens the pre-filter heuristic (matches IIFEs too) but acceptable for a pre-compilation gate.
packages/eslint-plugin-react-hooks/tests/ReactCompilerRuleTypescript-test.ts	Adds test coverage for HOF-wrapped components: immutability rule (prop mutation) and set-state-in-effect rule detection. Tests are well-structured and cover both valid and invalid cases.

_{Last reviewed commit: 99d6d02}

[greptile-apps]

_{14 files reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

IIFE incorrectly matched by CallExpression branch

This new branch matches any function whose parent is a CallExpression assigned to a variable, but it doesn't distinguish whether the function is an argument (HOF pattern: wrap(() => {})) or the callee (IIFE pattern: (() => {})()).

For const Items = (() => { ... })(), the arrow function is the callee of the CallExpression. The AST path is identical — parent.isCallExpression() is true, parent.parentPath.isVariableDeclarator() is true — so getFunctionName would return Items. Since Items starts with uppercase, getComponentOrHookLike would then incorrectly classify this IIFE as a component.

Consider adding a guard to ensure the function is an argument, not the callee:

Suggested change

	} else if (
	parent.isCallExpression() &&
	parent.parentPath.isVariableDeclarator() &&
	parent.parentPath.get('init').node === parent.node
	) {
	// const MyComponent = wrap(() => {});
	id = parent.parentPath.get('id');
	} else if (
	parent.isCallExpression() &&
	parent.get('callee').node !== path.node &&
	parent.parentPath.isVariableDeclarator() &&
	parent.parentPath.get('init').node === parent.node
	) {
	// const MyComponent = wrap(() => {});
	id = parent.parentPath.get('id');

Prompt To Fix With AI

This is a comment left during a code review.
Path: compiler/packages/babel-plugin-react-compiler/src/Entrypoint/Program.ts
Line: 1327-1333

Comment:
**IIFE incorrectly matched by `CallExpression` branch**

This new branch matches any function whose parent is a `CallExpression` assigned to a variable, but it doesn't distinguish whether the function is an **argument** (HOF pattern: `wrap(() => {})`) or the **callee** (IIFE pattern: `(() => {})()`).

For `const Items = (() => { ... })()`, the arrow function is the `callee` of the `CallExpression`. The AST path is identical — `parent.isCallExpression()` is true, `parent.parentPath.isVariableDeclarator()` is true — so `getFunctionName` would return `Items`. Since `Items` starts with uppercase, `getComponentOrHookLike` would then incorrectly classify this IIFE as a component.

Consider adding a guard to ensure the function is an argument, not the callee:

```suggestion
  } else if (
    parent.isCallExpression() &&
    parent.get('callee').node !== path.node &&
    parent.parentPath.isVariableDeclarator() &&
    parent.parentPath.get('init').node === parent.node
  ) {
    // const MyComponent = wrap(() => {});
    id = parent.parentPath.get('id');
```

How can I resolve this? If you propose a fix, please make it concise.

[everettbu]

Upstream PR was closed or merged. Code is synced via branch mirror.