[compiler] Fix false positive memo validation (alternative)

[mofeiZ]

Alternative to #34276

---

(Summary taken from @josephsavona 's #34276)
Partial fix for #34262. Consider this example:

function useInputValue(input) {
  const object = React.useMemo(() => {
    const {value} = transform(input);
    return {value};
  }, [input]);
  return object;
}

React Compiler breaks this code into two reactive scopes:

• One for transform(input)
• One for {value}

When we run ValidatePreserveExistingMemo, we see that the scope for {value} has the dependency value, whereas the original memoization had the dependency input, and throw an error that the dependencies didn't match.

In other words, we're flagging the fact that memoized better than the user as a problem. The more complete solution would be to validate that there is a subgraph of reactive scopes with a single input and output node, where the input node has the same dependencies as the original useMemo, and the output has the same outputs. That is true in this case, with the subgraph being the two consecutive scopes mentioned above.

But that's complicated. As a shortcut, this PR checks for any dependencies that are defined after the start of the original useMemo. If we find one, we know that it's a case where we were able to memoize more precisely than the original, and we don't report an error on the dependency. We still check that the original output value is able to be memoized, though. So if the scope of object were extended, eg with a call to mutate(object), then we'd still correctly report an error that we couldn't preserve memoization.

[josephsavona]

hmm this just means dep will be the last property of the destructure, this should be collecting all of deps, right?

[mofeiZ]

Yeah, this is eventually used by recordTemporaries which maps whatever this function returns to the Instruction lvalue. In the destructure case, I think we want to return the dep of source since x = {a, b} = source has the semantic of assigning source to x

<promoted>t1 = Destructure target={x, y} source=$0

[josephsavona]

nit: above we could refine on lvalue != null and then use lvalue here without as

[josephsavona]

makes sense, nice!