# Rust Code Review

Review {{input}} for correctness, idiomatic style, and best practices.

## Correctness
- Avoid `.unwrap()` and `.expect()` in library or production code; propagate errors with `?`
- Check for integer overflow in arithmetic, especially in index calculations
- Ensure `unsafe` blocks are minimal, well-commented, and provably sound
- Verify that all `Arc<Mutex<T>>` accesses cannot deadlock (lock ordering, no locks held across await)

## Error Handling
- Use a proper error type (`thiserror` crate recommended); avoid `Box<dyn Error>` in public APIs
- Provide useful context in error messages — include relevant values, not just the error kind
- `?` should be used consistently; mixing `match` and `?` without reason adds noise

## Memory and Performance
- Prefer borrowing over cloning; clone only when ownership is genuinely needed
- Avoid unnecessary heap allocations in hot paths (prefer `&str` over `String`, slices over `Vec`)
- Use `Cow<str>` when a function sometimes needs owned and sometimes borrowed data
- Profile before optimising — avoid premature micro-optimisation

## Async (if applicable)
- Do not block the async executor — move CPU-heavy work to `spawn_blocking`
- Ensure futures are `Send` where required by the runtime
- Avoid holding `MutexGuard` across `.await` points

## Code Quality
- Run `cargo clippy -- -D warnings` and fix all lints
- Public items must have doc comments (`///`)
- Tests in `#[cfg(test)]` cover happy path and error paths
- Module structure should reflect domain boundaries, not technical layers

---
List findings as **Critical** (unsoundness/panics/data races) -> **Major** (bugs/error handling gaps) -> **Minor** (style/clippy/performance). Cite each location and suggest the concrete fix.