[compiler] transform fire calls

[jbrown215]

This is the diff with the meaningful changes. The approach is:

1. Collect fire callees and remove fire() calls, create a new binding for the useFire result
2. Update LoadLocals for captured callees to point to the useFire result
3. Update function context to reference useFire results
4. Insert useFire calls after getting to the component scope

This approach aims to minimize the amount of new bindings we introduce for the function expressions
to minimize bookkeeping for dependency arrays. We keep all of the LoadLocals leading up to function
calls as they are and insert new instructions to load the originally captured function, call useFire,
and store the result in a new promoted temporary. The lvalues that referenced the original callee are
changed to point to the new useFire result.

This is the minimal diff to implement the expected behavior (up to importing the useFire call, next diff)
and further stacked diffs implement error handling. The rules for fire are:

1. If you use fire for a callee in the effect once you must use it for every time you call it in that effect
2. You can only use fire in a useEffect lambda/functions defined inside the useEffect lambda

There is still more work to do here, like updating the effect dependency array and handling object methods

--

Stack created with Sapling. Best reviewed with ReviewStack.

• [compiler] Rewrite effect dep arrays that use fire #31811
• [compile] Error on fire outside of effects and ensure correct compilation #31798
• [compiler] add fire imports #31797
• -> [compiler] transform fire calls #31796
• [compiler] Add fire to known React APIs #31795
• [compiler] Add option for firing effect functions #31794

[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	Dec 17, 2024 7:22pm

[josephsavona]

Exciting!!!! I'm still wrapping my head around this, sharing some early feedback

[josephsavona]

the pattern we usually use for this is a nullable nextInstructions array, initialized by slicing up to the point where you need to start making edits. then after that you push instructions to keep/add, don't push instructions you want to delete

[jbrown215]

that's an inconvenient approach for this pass specifically.

We insert the useFire calls before the load of the useEffect. If we were to wait until the point at which we know to generate them to insert, which is at the useEffect call, then we have to keep track of the index of the useEffect load index and insert the instructions there. This is easy to do with the InstructionIds because adding new instructions to the mapping does not shift the index of another useEffect load that occurs in the same block. If we push to the array, we'll need to additionally keep track of the number of added instructions so that we can account for the shifted offset in the nextInstructions array at which we should insert the useFire calls. If we naively insert the useFire calls right before the useEffect call then we introduce something like:

const effectLambda = () => {
  fireFunction();
}
const fireFunction = useFire(aFunction);
useEffect(effectLambda);

This code is legit, but the HIR representation for this is not as simple (requires a DeclareContext HoistedConst). It doesn't cause any of the tests to fail, but I'm not sure if that's really saying much.

[josephsavona]

can we be more precise and use the BuiltInFireId type?

[jbrown215]

BuiltInFireId is for fire, not useFire- is there a benefit to also introducing a useFire built in type?