[compiler] fix: preserve-manual-memoization validation should not require stable (non-reactive) values in deps

[sleitor]

Summary

validatePreservedManualMemoization (run when validatePreserveExistingMemoizationGuarantees is enabled) was incorrectly requiring state setters, dispatch functions, and other stable values to appear in the manual dependency array of useCallback/useMemo calls.

The Rules of React explicitly state that stable values (state setters returned by useState, dispatch returned by useReducer, startTransition, refs, etc.) do not need to be listed in dependency arrays — they are guaranteed to never change identity across renders. The eslint-plugin-react-hooks/exhaustive-deps rule already implements this exemption.

Root cause

ValidatePreservedManualMemoization.validateInferredDep checked ALL inferred scope dependencies against the user-provided source deps list, with no exemption for stable values. When the compiler inferred that a state setter like setImages was a dependency of the memoized scope, it would produce:

Compilation Skipped: Existing memoization could not be preserved
The inferred dependency was `setImages`, but the source dependencies were [].

This caused the compiler to bail out on components that correctly omitted state setters from their useCallback / useMemo deps arrays.

Fix

Add an early return in validateInferredDep when !dep.reactive && isStableType(dep.identifier):

• The !dep.reactive guard ensures we still validate reactive identifiers that happen to have a stable type — e.g. const ref = cond ? ref1 : ref2 (where the identity changes reactively).
• isStableType covers SetState, SetActionState, dispatch, useRef, startTransition, and setOptimistic.

This mirrors the logic in ValidateExhaustiveDependencies.isOptionalDependency which already applies the same exemption.

How did you test this change?

• Added new test fixture: preserve-memo-validation/useCallback-state-setter-stable-dep which exercises a component using setProcessed and setCount (state setters) inside useCallback with an empty deps array.
• Verified the existing test preserve-memo-validation/error.preserve-use-memo-ref-missing-reactive (reactive conditional ref still required in deps) continues to fail as expected.
• All 1720 compiler tests pass.

Fixes #36384

[laug]

Thank you for contributing this PR. As the reporter of the bug, please allow me to share my understanding of this fix in relation to the reported bug. I apologize if any of the below is incorrect, if so please feel free to correct any inaccuracy.

The current version of the compiler (without this PR applied) currently does not generally infer state setters etc. as dependencies, except in the very narrow edge case demonstrated in #36384, which requires multiple specific unrelated lines of code to trigger the compiler error.

So the bug reported in #36384 is that the state setter is being inferred as a dependency in that narrow edge case, even though it should not.

This PR does not address the fact the state setter is being inferred to be a dependency, instead it simply ignores any inferred dependency which happens to be a state setter (or other stable value). I.e. it is dealing with this bug after the fact rather than addressing its root cause.

Note that the test case added with this PR does NOT fail in the current version of the compiler (without this PR applied), as can be seen here, meaning that it doesn't test what is being fixed by this PR. Ideally the test case would fail in the current version of the compiler but pass with this PR applied.

[sleitor]

@laug Thank you for the careful analysis — you're completely right, and I apologize for submitting an incomplete regression test.

My added test (useCallback-state-setter-stable-dep.ts) uses direct useState calls in a pattern that doesn't trigger the compiler to include setters in the inferred scope deps. As you noted, the compiler already handles that case correctly without this PR, so the test passes trivially and doesn't validate what the fix is actually doing.

What the fix does: When validateInferredDep IS called with a state setter (or other stable value) as the inferred dep — because the compiler incorrectly included it in the scope's deps — the fix adds a guard: if the dep is non-reactive AND has a stable type (BuiltInSetState, etc.), skip the validation check rather than raising a compilation-skipped error. This is defensive: even if the scope analysis later produces a setter in inferred deps, the validation won't reject valid user code.

What's missing: An error fixture that replicates the narrow edge case from issue #36384 — where the compiler actually does infer setImages as a dep. Without that fixture, there's no test that would fail without this PR and pass with it.

I'll work on creating that fixture. The issue's playground shows the exact triggering pattern involves a custom hook returning a state setter + specific surrounding code. If you or the original reporter can share the minimal reproduction that I can convert directly into an error.preserve-memo-* fixture (one that expects compilation to skip without the fix), I'll update the PR. Alternatively, I'll try to derive it from the playground URLs in #36384.

I'll update the PR shortly with a proper regression test.

[laug]

The issue's playground is already the smallest repro I was able to come up with, so please use that

[sleitor]

@laug Thank you for clarifying! I'll use the playground directly as the basis for the regression fixture — that's the most faithful way to capture the exact code pattern that triggers the narrow edge case. Will add a proper error fixture shortly.

[sleitor]

@laug Done — added a proper regression fixture based on the exact playground code: useCallback-state-setter-inferred-dep-issue-36384.ts.

This uses the specific pattern from the issue playground (external getValue() + JSON.parse as initial state + useCallback with [] deps using setImages) that actually triggers the compiler to infer setImages as a required dependency. Without the fix in the first commit, this fixture produces:

Compilation Skipped: Existing memoization could not be preserved. The inferred dependency was setImages, but the source dependencies were [].

With the fix applied, it compiles successfully. The previous test (useCallback-state-setter-stable-dep.ts) is kept as a complementary case but wasn't a proper regression test — this new fixture is.

[laug]

Thanks.

As state setter functions should not be inferred as dependencies in the first place, are you able to investigate and fix the code such that even in that test case, the setImages state setter function does not get inferred by the compiler as a dependency?