Always prioritize memory safety and use safe Rust constructs when possible

Prefer owned types over references when the performance cost is negligible

Use descriptive variable names that indicate ownership (e.g., `owned_data`, `borrowed_ref`)

Always handle `Result` and `Option` types explicitly - never use `unwrap()` in production code

Use `?` operator for error propagation when appropriate

Prefer `Vec::with_capacity()` when the size is known in advance

Use `&str` for string parameters and `String` for owned strings

Always specify explicit lifetimes in function signatures when borrowing

Use `derive` macros for common traits (Debug, Clone, PartialEq) when applicable

Prefer iterators over index-based loops for better performance and safety

Use `match` statements instead of multiple `if let` chains

Always run `cargo clippy` and fix warnings before suggesting code

Use `cargo fmt` formatting standards

Include comprehensive error handling with custom error types using `thiserror` or similar

For async code, prefer `tokio` runtime and always handle cancellation properly

Use `Arc<Mutex<T>>` or `Arc<RwLock<T>>` for shared mutable state across threads

Prefer composition over inheritance patterns

Always include unit tests with `#[cfg(test)]` modules

Use `serde` for serialization with proper error handling

Document public APIs with `///` doc comments including examples

Use `#[must_use]` attribute for functions that return important values

Prefer `const fn` for compile-time evaluation when possible

Use `#[inline]` judiciously for performance-critical small functions

Perform a thorough Rust code review focusing on:

**Memory Safety & Ownership:**
- Proper ownership, borrowing, and lifetime management
- Potential memory leaks or unsafe operations
- Smart pointer usage (Box, Rc, Arc)

**Performance & Efficiency:**
- Unnecessary allocations or clones
- Iterator usage vs index-based loops
- Zero-cost abstraction opportunities

**Error Handling:**
- Result/Option handling patterns
- Avoiding unwrap() in production code
- Custom error type suggestions

**Rust Idioms & Best Practices:**
- Modern Rust conventions
- Trait and generic usage
- Pattern matching optimization

**Concurrency & Safety:**
- Thread safety and data race prevention
- Async/await usage and cancellation handling
- Proper synchronization primitives

Optimize this Rust code for peak performance while maintaining memory safety:

- Replace heap allocations with stack allocations where possible
- Use `Vec::with_capacity()` for known sizes
- Replace `String` with `&str` where ownership isn't needed
- Prefer iterators over index-based loops
- Consider `unsafe` blocks only when absolutely necessary (with justification)
- Apply `#[inline]` attributes strategically
- Use SIMD operations where applicable
- Minimize dynamic dispatch through monomorphization
- Optimize struct memory layouts

Explain each optimization and its performance impact.

Convert this synchronous Rust code to async/await patterns ensuring:

- Proper `async fn` and `.await` usage
- Comprehensive error handling in async contexts
- Cancellation safety and cleanup
- Effective use of tokio runtime features
- Concurrent operations with `join!` or `select!`
- Stream processing where applicable
- Async trait bounds and `Send + Sync` requirements
- Avoiding blocking operations in async contexts

Include error handling and usage examples.

Review this unsafe Rust code and provide:

1. **Safety Invariant Verification:** Confirm all safety requirements are met
2. **Assumption Documentation:** Explain why the unsafe code is sound
3. **Scope Minimization:** Suggest ways to reduce unsafe surface area
4. **Safety Documentation:** Add detailed safety comments
5. **Safe Alternatives:** Propose safer approaches if possible
6. **Testing Strategy:** Recommend testing approaches for unsafe code

For each unsafe block, provide:
- Clear safety documentation
- Justification for necessity
- Proof of safety invariant maintenance

Generate comprehensive unit tests for this Rust code including:

- **Happy Path Tests:** Typical usage scenarios
- **Edge Case Tests:** Boundary conditions and limits
- **Error Handling Tests:** All possible error paths
- **Property-Based Tests:** Using `proptest` for complex invariants
- **Integration Tests:** External system interactions
- **Benchmark Tests:** Performance validation with `criterion`
- **Mock Tests:** External dependency simulation

Use proper `#[cfg(test)]` module organization with descriptive test names.
Include setup/teardown and test data generation.