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

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.
This commit is contained in:
Joe Savona
2026-02-23 16:02:10 -08:00
parent 9b2d8013ee
commit 7a1cc89f8c
3 changed files with 85 additions and 6 deletions

View File

@@ -279,27 +279,27 @@ Walk through `runWithEnvironment` and wrap each pass call site. This is the inte
### Phase 8: Testing
- [ ] **8.1 Update existing `error.todo-*` fixture expectations**
- [x] **8.1 Update existing `error.todo-*` fixture expectations**
- Currently, fixtures with `error.todo-` prefix expect a single error and bailout
- After fault tolerance, some of these may now produce multiple errors
- Update the `.expect.md` files to reflect the new aggregated error output
- [ ] **8.2 Add multi-error test fixtures**
- [x] **8.2 Add multi-error test fixtures**
- Create test fixtures that contain multiple independent errors (e.g., both a `var` declaration and a mutation of a frozen value)
- Verify that all errors are reported, not just the first one
- [ ] **8.3 Add test for invariant-still-throws behavior**
- [x] **8.3 Add test for invariant-still-throws behavior**
- Verify that `CompilerError.invariant()` failures still cause immediate abort
- Verify that non-CompilerError exceptions still cause immediate abort
- [ ] **8.4 Add test for partial HIR codegen**
- [x] **8.4 Add test for partial HIR codegen**
- Verify that when BuildHIR produces partial HIR (with `UnsupportedNode` values), later passes handle it gracefully and codegen produces the original AST for unsupported portions
- [ ] **8.5 Verify error severity in aggregated output**
- [x] **8.5 Verify error severity in aggregated output**
- Test that the aggregated `CompilerError` correctly reports `hasErrors()` vs `hasWarning()` vs `hasHints()` based on the mix of accumulated diagnostics
- Verify that `panicThreshold` behavior in Program.ts is correct for aggregated errors
- [ ] **8.6 Run full test suite**
- [x] **8.6 Run full test suite**
- Run `yarn snap` and `yarn snap -u` to update all fixture expectations
- Ensure no regressions in passing tests

View File

@@ -0,0 +1,60 @@
## Input
```javascript
// @validateRefAccessDuringRender
/**
* This fixture tests fault tolerance: the compiler should report
* multiple independent errors rather than stopping at the first one.
*
* Error 1: Ref access during render (ref.current)
* Error 2: Mutation of frozen value (props)
*/
function Component(props) {
const ref = useRef(null);
// Error: reading ref during render
const value = ref.current;
// Error: mutating frozen value (props, which is frozen after hook call)
props.items = [];
return <div>{value}</div>;
}
```
## Error
```
Found 2 errors:
Error: This value cannot be modified
Modifying component props or hook arguments is not allowed. Consider using a local variable instead.
error.fault-tolerance-reports-multiple-errors.ts:16:2
14 |
15 | // Error: mutating frozen value (props, which is frozen after hook call)
> 16 | props.items = [];
| ^^^^^ value cannot be modified
17 |
18 | return <div>{value}</div>;
19 | }
Error: Cannot access refs during render
React refs are values that are not needed for rendering. Refs should only be accessed outside of render, such as in event handlers or effects. Accessing a ref value (the `current` property) during render can cause your component not to update as expected (https://react.dev/reference/react/useRef).
error.fault-tolerance-reports-multiple-errors.ts:13:16
11 |
12 | // Error: reading ref during render
> 13 | const value = ref.current;
| ^^^^^^^^^^^ Cannot access ref value during render
14 |
15 | // Error: mutating frozen value (props, which is frozen after hook call)
16 | props.items = [];
```

View File

@@ -0,0 +1,19 @@
// @validateRefAccessDuringRender
/**
* This fixture tests fault tolerance: the compiler should report
* multiple independent errors rather than stopping at the first one.
*
* Error 1: Ref access during render (ref.current)
* Error 2: Mutation of frozen value (props)
*/
function Component(props) {
const ref = useRef(null);
// Error: reading ref during render
const value = ref.current;
// Error: mutating frozen value (props, which is frozen after hook call)
props.items = [];
return <div>{value}</div>;
}