[compiler] Improve impurity/ref validation

[josephsavona]

Summary

note: This implements the idea discussed in https://github.com/reactwg/react/discussions/389#discussioncomment-14252280

This is a large PR that significantly changes our impurity and ref validation to address multiple issues. The goal is to reduce false positives and make the errors we do report more actionable.

Validating Against Impure Values In Render

Currently we create Impure effects for impure functions like Date.now() or Math.random(), and then throw if the effect is reachable during render. However, impurity is a property of the resulting value: if the value isn't accessed during render then it's okay: maybe you're console-logging the time while debugging (fine), or storing the impure value into a ref and only accessing it in an effect or event handler (totally ok).

This PR updates to validate that impure values are not transitively consumed during render, building on the new effects system: rather than look at instruction types, we use effects like Capture a -> b, Impure a, and Render b to determine how impure values are introduced and where they flow through the program. We're intentionally conservative, and do not propagate impurity through MaybeCapture effects, which is used for functions we don't have signatures for. This means that things like identity(performance.now()) drop the impurity. This feels like a good compromise since it means we have very high confidence in the errors that we report and can always add increased strictness later as our confidence increases.

An example error:

Error: Cannot access impure value during render

Calling an impure function can produce unstable results that update unpredictably when the component happens to re-render. (https://react.dev/reference/rules/components-and-hooks-must-be-pure#components-and-hooks-must-be-idempotent).

error.invalid-impure-value-in-render-helper.ts:5:17
  3 |   const now = () => Date.now();
  4 |   const render = () => {
> 5 |     return <div>{now()}</div>;
    |                  ^^^^^ Cannot access impure value during render
  6 |   };
  7 |   return <div>{render()}</div>;
  8 | }

error.invalid-impure-value-in-render-helper.ts:3:20
  1 | // @validateNoImpureFunctionsInRender
  2 | function Component() {
> 3 |   const now = () => Date.now();
    |                     ^^^^^^^^^^ `Date.now` is an impure function.
  4 |   const render = () => {
  5 |     return <div>{now()}</div>;
  6 |   };

Impure values are allowed to flow into refs, meaning that we now allow useRef(Date.now()) or useRef(localFunctionThatReturnsMathDotRandom()) which would have errored previously. The next PR reuses this improved impurity tracking to validate ref access in render as well.

Refs Now Treated As Impure Values in Render

Reading a ref now produces an Impure effect, and reading refs in render is validated using the above validation against impure values in render. The error category and message is customized for refs, we're just reusing the validation implementation. This means you get consistent results for performance.now() as for ref.current. A nice consistency win.

Simplified writing-ref validation

Now that reading a ref in render is validated using the impure values infra, I also dramatically simplified ValidateNoRefAccessInRender to focus solely on validation against writing refs during render. It was harder to use the new effects infra for this since we intentionally do not record ref mutations as a Mutate effect. So for now, the pass switches on InstructionValue variants. We continue to support the if (ref.current == null) { ref.current = <init> } pattern and reasonable variants of it. We're conservative about what we consider to be a write of a ref - foo(ref) now assumes you're not mutating rather than the inverse.

Takeaways

• Impure-values-in-render logic is more conservative about what it considers an error (ie to users it appears more persmissive). We follow clearly identifiable (and if we wanted traceable/explainable) paths from impure sources through to where they are rendered. We allow many more cases than before, notably x = foo(ref) optimistically assumes you don't read the ref. Concretely, this follows from not tracking impure values across MaybeCapture effects.
• No-writing-refs-in-render is also more conservative about what it counts as a write, appearing to users as allowing more cases. We look for very direct evidence of writing to refs, ie ref.current = <value> or ref.current.property = <value>, and allow potential writes through eg writeToRef(ref, value).

---

Stack created with Sapling. Best reviewed with ReviewStack.

• [compiler] Improve snap workflow for debugging errors #35539
• [compiler] Improve snap usability #35537
• [compiler] Claude file/settings #35523
• -> [compiler] Improve impurity/ref validation #35298

[josephsavona]

This case is a great example of the improvement. The previous error didn't point to anything that obviously had a ref, while the new error points to the source and usage of the ref in JSX.