[Compiler] Fix false positive for setState after await in useEffect#491
Closed
everettbu wants to merge 2 commits into
Closed
[Compiler] Fix false positive for setState after await in useEffect#491everettbu wants to merge 2 commits into
everettbu wants to merge 2 commits into
Conversation
…#34905) The `set-state-in-effect` validation was incorrectly flagging setState calls that appear after an `await` expression inside async functions called from useEffect. After an `await`, execution continues asynchronously in a microtask, so the setState call is not synchronous within the effect body. This fix adds `Await` instruction tracking in `getSetStateCall()`. When an `Await` instruction is encountered in a block, subsequent setState calls in the same block are skipped since they execute asynchronously. Test plan: - allow-setState-in-useEffect-after-await: setState after await via useCallback + useEffect (exact issue repro) - no error - allow-setState-in-useEffect-async-callback: setState after await in nested async function inside useEffect - no error - invalid-setState-in-useEffect-before-await: setState before await is still correctly flagged - error reported Fixes #34905 Co-authored-by: Cursor <cursoragent@cursor.com>
Greptile OverviewGreptile SummaryThis PR adjusts the It also adds three compiler snapshot fixtures that cover (1) Confidence Score: 5/5
Important Files Changed
|
Author
|
Upstream PR was closed or merged. Code is synced via branch mirror. |
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.
Mirror of facebook/react#35732
Original author: basitqayoom
Summary
Fixes #34905
The
set-state-in-effectvalidation (ValidateNoSetStateInEffects) was incorrectly flaggingsetStatecalls that appear after anawaitexpression inside async functions called fromuseEffect.After an
await, execution continues asynchronously in a microtask — meaning thesetStatecall is no longer synchronous within the effect body and should not trigger this lint.Root cause
In
getSetStateCall(), the function walks through the HIR of the effect callback and returns the firstsetStatecall it finds, without distinguishing whether that call appears after anAwaitinstruction.Fix
Added
Awaitinstruction tracking within each block ingetSetStateCall():Awaitinstruction is encountered, aseenAwaitflag is set for the current blocksetStatecall in the same block after anAwaitis skipped (not reported as synchronous)This is a conservative fix scoped to intra-block tracking. Cross-block
awaitdominator analysis can be added as a follow-up if needed.How did you test this change?
Added 3 new test fixtures:
allow-setState-in-useEffect-after-awaitawaitviauseCallback+useEffect(exact issue repro)allow-setState-in-useEffect-async-callbackawaitin nested async function insideuseEffectinvalid-setState-in-useEffect-before-awaitawaitis still correctly flaggedAll existing tests continue to pass: