[compiler] Switch to track setStates by aliasing and id instead of identifier names #34973
Conversation
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
jorge-cab
force-pushed
the
pr34973
branch
2 times, most recently
from
0b7e117 to
8e65f61
Compare
jorge-cab
changed the title
jorge-cab
force-pushed
the
pr34973
branch
4 times, most recently
from
d689084 to
d237545
Compare
jorge-cab
force-pushed
the
pr34973
branch
4 times, most recently
from
a44efd5 to
05025bd
Compare
…d instead update typeOfValue and fix infinite loops
Summary:
With this we are now comparing a snapshot of the derivationCache with the new changes every time we are done recording the derivations happening in the HIR.
We have to do this after recording everything since we still do some mutations on the cache when recording mutations.
Test Plan:
Test the following in playground:
```
// @validateNoDerivedComputationsInEffects_exp
function Component({ value }) {
const [checked, setChecked] = useState('');
useEffect(() => {
setChecked(value === '' ? [] : value.split(','));
}, [value]);
return (
<div>{checked}</div>
)
}
```
This no longer causes an infinite loop.
Added a test case in the next PR in the stack
…or for `no-deriving-state-in-effects` Summary: Revamped the derivationCache graph. This fixes a bunch of bugs where sometimes we fail to track from which props/state we derived values from. Also, it is more intuitive and allows us to easily implement a Data Flow Tree. We can print this tree which gives insight on how the data is derived and should facilitate error resolution in complicated components Test Plan: Added a test case where we were failing to track derivations. Also updated the test cases with the new error containing the data flow tree
…he error instead of throwing Summary: TSIA Simple change to log errors in Pipeline.ts instead of throwing in the validation Test Plan: updated snap tests
…entifier names Summary: This makes the setState usage logic much more robust. We no longer rely on identifierName. Now we track when a setState is loaded into a new promoted identifier variable and track this in a map `setStateLoaded` map. For other types of instructions we consider the setState to be being used. In this case we record its usage into the `setStateUsages` map. Test Plan: We expect no changes in behavior for the current tests
mofeiZ
reviewed
Oct 31, 2025
| context.effectSetStateCache.set(operand.loc.identifierName, [ | ||
| operand, | ||
| ]); | ||
| if (isSetStateType(operand.identifier)) { |
There was a problem hiding this comment.
we should be able to remove this isSetStateType (as discussed)
this will keep the logic cleaner (we rely on just dataflow instead of a hybrid of data-flow and typing)
mofeiZ
reviewed
Oct 31, 2025
| context.setStateCache.get(operand.loc.identifierName)!.push(operand); | ||
| } else { | ||
| context.setStateCache.set(operand.loc.identifierName, [operand]); | ||
| if (isSetStateType(operand.identifier) && isFirstPass) { |
There was a problem hiding this comment.
I think you should be able to remove this as well
mofeiZ
reviewed
Oct 31, 2025
Comment on lines
+312
to
+315
| if (isSetStateType(operand.identifier)) { | ||
| if (instr.value.kind === 'LoadLocal') { | ||
| loads.set(operand.identifier.id, instr.value.place.identifier.id); | ||
| } else { |
There was a problem hiding this comment.
I would move line 312 to line 315:
// invariant: everything in the loads sidemap is a 'valid' setState
if (instr is LoadLocal) {
// check if there is an entry for `instr.value.place...` in the `loads` sidemap
// if there is, insert the loadlocal lvalue into `loads` as well
} else {
// is this a possible "source" of setStates
if (ifSetStateType(...)) {
// this is a root setState
}
}
mofeiZ
approved these changes
Oct 31, 2025
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.
Summary:
This makes the setState usage logic much more robust. We no longer rely on identifierName.
Now we track when a setState is loaded into a new promoted identifier variable and track this in a map
setStateLoadedmap.For other types of instructions we consider the setState to be being used. In this case we record its usage into the
setStateUsagesmap.Test Plan:
We expect no changes in behavior for the current tests
Stack created with Sapling. Best reviewed with ReviewStack.
no-deriving-state-in-effects#34995