-
Notifications
You must be signed in to change notification settings - Fork 47k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[compiler][repro] False positives for ValidatePreserveMemo #30629
Conversation
[ghstack-poisoned]
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
* of its scope (but after its mutable range ends). | ||
*/ | ||
|
||
function useFoo(a, b) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the only false positive not fixed by #30630 and unrelated to #30603. Included since it shows a use-case for an identifier's original mutable range (instead of the currently used scope range).
Currently, forget (incorrectly) infers that x
is potentially mutated after StartMemoize deps=[x, ...]
useIdentity(2); | ||
mutate(x); | ||
|
||
return useCallback(() => [x, []], [x]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a false positive because the input wasn't memoized in source, right? Just making sure i'm interpreting this the same way you are.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep exactly! I added this fixture to show changes from #30630
* We currently bail out because `a` has a scope and is not transitively memoized | ||
* (as its scope is pruned due to a hook call) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting - looks like we are grouping the argument destructuring into a scope? that seems wrong, a
and b
aren't mutable so they shouldn't be getting added into any scopes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My understanding is that this is because x
is a context variable, and since our understanding of mutable context variables is imprecise, x
and all potential aliases get marked as mutable. I might be incorrect though -- can look into this more
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These are great fixtures, fine to land. See comments, i wonder if the fix might be different for some of these than is suggested by the code comments
ghstack-source-id: 7fa94fea867371f3d77737dad80a321094f10600 Pull Request resolved: #30629
Stack from ghstack (oldest at bottom):
Found when syncing changes from #30603 to meta codebase, see fixture comments for explanations