[compiler] Phase 8: Add multi-error test fixture and update plan

[everettbu]

Mirror of facebook/react#35845
Original author: josephsavona

---

Add test fixture demonstrating fault tolerance: the compiler now reports
both a mutation error and a ref access error in the same function, where
previously only one would be reported before bailing out.

Update plan doc to mark all phases as complete.

---

Stack created with Sapling. Best reviewed with ReviewStack.

• #35853
• #35852
• #35851
• #35850
• #35849
• #35848
• #35847
• -> #35845
• #35844
• #35843
• #35842
• #35841
• #35840

[greptile-apps]

Greptile Summary

This PR implements fault tolerance for the React Compiler (Phases 1, 2, 4-8 of the plan), enabling the compiler to continue past errors and report all compilation issues at once rather than bailing out at the first error.

• Adds error accumulation infrastructure to Environment (recordError, tryRecord, hasErrors, aggregateErrors) that catches non-invariant CompilerErrors and records them for aggregated reporting
• Changes Pipeline.ts to wrap all pass invocations in env.tryRecord(), converting the pipeline from fail-fast to fault-tolerant; return type changes from CodegenFunction to Result<CodegenFunction, CompilerError>
• Updates all 12+ validation passes to record errors on env instead of returning Result or throwing, removing .unwrap() calls throughout the pipeline
• Updates inference passes (inferMutationAliasingEffects, inferMutationAliasingRanges) and codegen to record errors instead of returning Results
• Adds a new test fixture (error.fault-tolerance-reports-multiple-errors) demonstrating that both a mutation error and a ref-access error are reported from the same function
• Updates ~26 existing test fixture expectations to reflect additional errors that are now surfaced (previously masked by early bailout)
• Adds comprehensive plan document (fault-tolerance-overview.md) marking all phases complete with key learnings

Phase 3 (updating BuildHIR/lower to always produce HIR) is not included in this PR and remains for future work.

Confidence Score: 4/5

• This PR is a well-structured refactor with comprehensive test coverage updates; the main risks are edge cases in fault-tolerant pass ordering.
• The changes follow a clear, systematic pattern across all passes. The test fixture updates demonstrate the new behavior works as expected. Two minor concerns prevent a 5: (1) the definite assignment assertion on reactiveFunction could cause confusing runtime crashes if buildReactiveFunction fails, and (2) duplicate error logging via recordError + handleError may be unintentional. Both are unlikely to cause production issues given the existing invariant safety nets.
• Pay close attention to Pipeline.ts (definite assignment assertion pattern for reactiveFunction) and Environment.ts (duplicate logging in recordError)

Important Files Changed

Filename	Overview
compiler/packages/babel-plugin-react-compiler/src/HIR/Environment.ts	Adds error accumulation infrastructure (#errors field, recordError, recordErrors, hasErrors, aggregateErrors, tryRecord). Core foundation for fault tolerance. The recordError method logs with fnLoc: null which causes duplicate logging when errors are also logged by the caller.
compiler/packages/babel-plugin-react-compiler/src/Entrypoint/Pipeline.ts	Changes return type to Result, wraps all pass calls in env.tryRecord(), removes .unwrap() calls, and adds final error check. Uses definite assignment assertions for value-producing passes wrapped in tryRecord.
compiler/packages/babel-plugin-react-compiler/src/Entrypoint/Program.ts	Updates tryCompileFunction to handle Result from compileFn instead of relying solely on try/catch. Clean adaptation to the new API.
compiler/packages/babel-plugin-react-compiler/src/ReactiveScopes/CodegenReactiveFunction.ts	Changes codegenFunction and codegenReactiveFunction to return CodegenFunction directly instead of Result, recording errors on env. Records errors from emitInstrumentForget assertion failure.
compiler/packages/babel-plugin-react-compiler/src/Inference/InferMutationAliasingEffects.ts	Changes return type from Result to void — errors are now recorded on env by callers or internally. Simple signature change.
compiler/packages/babel-plugin-react-compiler/src/Inference/InferMutationAliasingRanges.ts	Changes return type from Result to Array, records errors on env when enableValidations is true. Always returns the function effects array.
compiler/packages/babel-plugin-react-compiler/src/Validation/ValidateContextVariableLValues.ts	Changes from throwing CompilerError to recording errors on env via recordError. Returns early after recording Todo errors to avoid hitting invariant.
compiler/packages/babel-plugin-react-compiler/src/Validation/ValidateNoRefAccessInRender.ts	Returns void instead of Result. Uses a separate innerErrors object for function expressions to determine ref-access effects without propagating inner errors to the outer scope.
compiler/packages/babel-plugin-react-compiler/src/Validation/ValidateLocalsNotReassignedAfterRender.ts	Records errors on env instead of constructing and throwing CompilerError. Returns null after recording async reassignment error to avoid propagating a stale reassignment marker.
compiler/fault-tolerance-overview.md	New comprehensive plan document describing all 8 phases of fault tolerance implementation. All phases marked complete with key learnings documented.
compiler/packages/babel-plugin-react-compiler/src/tests/fixtures/compiler/error.fault-tolerance-reports-multiple-errors.js	New test fixture demonstrating fault tolerance: a component with both ref access during render and mutation of frozen props, verifying both errors are reported.

_{Last reviewed commit: cd20708}

[greptile-apps]

_{50 files reviewed, 2 comments}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

Duplicate error logging with fnLoc: null

recordError logs each error to the logger with fnLoc: null. However, after compilation completes, Program.ts calls handleError/logError on the aggregated CompilerError, which logs each error again with the actual fnLoc. This causes duplicate log entries, as visible in the dynamic-gating-bailout-nopanic test fixture where the same PreserveManualMemo error now appears twice in the Logs section — once with "fnLoc":null and once with the real fnLoc.

This may be intentional (the early log provides immediate feedback during compilation, while the later one has the function location), but it's worth confirming this is the desired behavior, especially since consumers of the logger may not expect duplicates.

Prompt To Fix With AI

This is a comment left during a code review.
Path: compiler/packages/babel-plugin-react-compiler/src/HIR/Environment.ts
Line: 744-750

Comment:
**Duplicate error logging with `fnLoc: null`**

`recordError` logs each error to the logger with `fnLoc: null`. However, after compilation completes, `Program.ts` calls `handleError`/`logError` on the aggregated `CompilerError`, which logs each error *again* with the actual `fnLoc`. This causes duplicate log entries, as visible in the `dynamic-gating-bailout-nopanic` test fixture where the same `PreserveManualMemo` error now appears twice in the Logs section — once with `"fnLoc":null` and once with the real `fnLoc`.

This may be intentional (the early log provides immediate feedback during compilation, while the later one has the function location), but it's worth confirming this is the desired behavior, especially since consumers of the logger may not expect duplicates.

How can I resolve this? If you propose a fix, please make it concise.

[greptile-apps]

Definite assignment assertion may mask runtime errors

let reactiveFunction!: ReactiveFunction uses a definite assignment assertion (!), which tells TypeScript to trust that this variable will be assigned before use. If buildReactiveFunction throws a non-invariant CompilerError (caught by tryRecord), reactiveFunction remains undefined at runtime, but all subsequent code — including assertWellFormedBreakTargets(reactiveFunction), pruneUnusedLabels(reactiveFunction), and codegenFunction(reactiveFunction, ...) — will proceed with undefined, likely causing a confusing invariant or runtime crash rather than a clear error message.

The same pattern applies to fbtOperands and uniqueIdentifiers earlier in the function, though those use safe empty defaults (new Set()). Consider using a similar fallback pattern here, or checking if reactiveFunction is defined before proceeding with the reactive-function passes.

Prompt To Fix With AI

This is a comment left during a code review.
Path: compiler/packages/babel-plugin-react-compiler/src/Entrypoint/Pipeline.ts
Line: 461-471

Comment:
**Definite assignment assertion may mask runtime errors**

`let reactiveFunction!: ReactiveFunction` uses a definite assignment assertion (`!`), which tells TypeScript to trust that this variable will be assigned before use. If `buildReactiveFunction` throws a non-invariant `CompilerError` (caught by `tryRecord`), `reactiveFunction` remains `undefined` at runtime, but all subsequent code — including `assertWellFormedBreakTargets(reactiveFunction)`, `pruneUnusedLabels(reactiveFunction)`, and `codegenFunction(reactiveFunction, ...)` — will proceed with `undefined`, likely causing a confusing invariant or runtime crash rather than a clear error message.

The same pattern applies to `fbtOperands` and `uniqueIdentifiers` earlier in the function, though those use safe empty defaults (`new Set()`). Consider using a similar fallback pattern here, or checking if `reactiveFunction` is defined before proceeding with the reactive-function passes.

How can I resolve this? If you propose a fix, please make it concise.

[everettbu]

Upstream PR was closed or merged. Code is synced via branch mirror.