[compiler] First cut at dep inference

[jbrown215]

This is for researching/prototyping, not a feature we are releasing imminently.

Putting up an early version of inferring effect dependencies to get feedback on the approach. We do not plan to ship this as-is, and may not start by going after direct useEffect calls. Until we make that decision, the heuristic I use to detect when to insert effect deps will suffice for testing.

The approach is simple: when we see a useEffect call with no dep array we insert the deps inferred for the lambda passed in. If the first argument is not a lambda then we do not do anything.

This diff is the easy part. I think the harder part will be ensuring that we can infer the deps even when we have to bail out of memoization. We have no other features that must run regardless of rules of react violations. Does anyone foresee any issues using the compiler passes to infer reactive deps when there may be violations?

I have a few questions:

1. Will there ever be more than one instruction in a block containing a useEffect? if no, I can get rid of theaddedInstrs variable that I use to make sure I insert the effect deps array temp creation at the right spot.
2. Are there any cases for resolving the first argument beyond just looking at the lvalue's identifier id that I'll need to take into account? e.g., do I need to recursively resolve certain bindings?

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
react-compiler-playground	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Nov 1, 2024 7:26pm

[josephsavona]

Will there ever be more than one instruction in a block containing a useEffect

Ahh I think what you might be observing is that we create scopes for hook calls, but then flatten them away. And so either you’re looking at the pre-flattened state or you’re looking at a later pass after we flatten to a labeled block. We want to get rid of the labeled block and truly flatten it as if there had never been a scope, though. So I would definitely code as if there could be other instructions in the block w the effect.

[josephsavona]

Are there any cases for resolving the first argument beyond just looking at the lvalue's identifier id

No, that should only happen if there wasn’t an inline function expression.

[josephsavona]

Exciting! A bunch of smaller feedback, we should discuss the strategy (given the need for guaranteed compilation) in our compiler design sync

[jbrown215]

@mofeiZ mentioned that it would be good to promote effect lambdas to their own scope before running PropagateScopeDependencies to get the most precise deps I can

[josephsavona]

Hmmm given that effect lambdas are immediately frozen and also transitively freeze their dependencies, they should already be in their own scope anyway. Do you have a specific example where that isn't the case now?

[jbrown215]

I don't have a specific example, but we were talking about this in the context of a reduced pipeline that may not be running all of the phases. For example, we may not freeze functions in the re-run because it relies on certain Rules of React not to be violated. In that context it seems possible? In any case, it doesn't need to block this PR and I can wait until I produce that issue!

[josephsavona]

Ahhh i see. Yeah, in the reduced pipeline you could just force-creates scopes around the lambdas passed to useEffect and run propagateScopeDeps to get the deps.