eval: use published rain-forker instead of the foundry-evm git dep

[thedavidmeister]

Replaces rainlang-eval's foundry-evm git dependency (15 unpublishable crates) with the published rain-forker crate, which provides the same generic forking executor (multi-fork RPC forking, typed calls, call tracing, replay_transaction) on revm 36 + foundry-fork-db + revm-inspectors — all on crates.io.

rainlang-eval keeps only the Rain-specific layer:

• error.rs / fork.rs are thin re-exports of rain_forker (native-only), so downstream paths like rain_interpreter_eval::fork::Forker keep working
• fork_eval / fork_parse become a ForkEvalExt extension trait (Forker is now a foreign type)
• trace.rs reads the CallTraceArena directly (no foundry SparsedTraceArena wrapper)

This removes the foundry-evm git dep from the workspace entirely (0 foundry git refs in the lock), so rainlang-eval can itself be published — unblocking raindex's last git deps (raindex#2593).

The workspace alloy bumps 1.0.12 → 1.8.3 (rain-forker needs ≥1.0.38 via revm-inspectors; foundry-evm had been anchoring it low), which also clears a transitive winnow split. Within alloy 1.x, no source changes needed.

All eval tests pass: native + wasm32 + the 1000-way parallel fork_eval (1.04s, no deadlock).

🤖 Generated with Claude Code

Summary by CodeRabbit

Release Notes

• Chores
  • Refactored internal architecture to consolidate forking capabilities into a dedicated module with improved organization.
  • Reorganized code modules to enhance modularity and maintainability across evaluation and parsing components.
  • Streamlined internal dependencies and code organization for better code structure.
  • Maintained full backward compatibility with existing functionality and interfaces.

[coderabbitai]

Caution

Review failed

Pull request was closed or merged during review

📝 Walkthrough

Walkthrough

This PR extracts the forking executor from the rainlang_eval crate into a published rain-forker crate. Foundry git dependencies are removed from workspace configuration; the eval crate adopts rain-forker as a published dependency. The fork module and error types become re-exports; inherent fork methods on Forker are refactored into a ForkEvalExt extension trait. CLI commands and trace handling are updated to use the new trait.

Changes

Forking Executor Extraction

Layer / File(s)	Summary
Dependency migration and fork module extraction Cargo.toml, crates/eval/Cargo.toml, crates/eval/src/fork.rs, crates/eval/src/error.rs	Workspace foundry dependencies (foundry-evm, foundry-evm-core, foundry-fork-db, foundry-block-explorers, revm) are removed. Eval crate replaces them with rain-forker = "0.1" for non-wasm targets. Fork and error modules become thin re-export shims from rain_forker.
Extension trait refactoring and eval updates crates/eval/src/eval.rs, crates/eval/src/lib.rs	Inherent fork_parse and fork_eval methods on Forker are removed and replaced with public extension trait ForkEvalExt. Implementation provides the same async call flow via trait methods. Lib.rs adds #[cfg(not(target_family = "wasm"))] guard to error module. Test imports and trace handling in eval.rs are simplified.
CLI and trace integration crates/cli/src/commands/eval.rs, crates/cli/src/commands/parse.rs, crates/eval/src/trace.rs	CLI eval and parse commands update imports to include ForkEvalExt alongside existing fork types. Trace module switches to rain_forker::RawCallResult and updates test imports.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related issues

• Publish rainlang-eval + rainlang_test_fixtures to crates.io (unblock raindex's last git deps) #519: Addresses the task to remove git-based foundry-evm and revm workspace dependencies so the rainlang-eval crate can be published by extracting the forking executor into a separate published rain-forker crate.

Poem

A Rabbit's Ode to Extraction 🐰

Forkers once lived in the eval's deep nest,
But now they're extracted and dressed for the best,
Rain-forker published, git deps are gone,
Extension traits guide us to carry on! 🚀

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately summarizes the main change: replacing foundry-evm git dependencies with the published rain-forker crate, which is the core objective of this PR.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch 2026-05-28-eval-foundry-fork-db

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[github-actions]

@coderabbitai assess this PR size classification for the totality of the PR with the following criterias and report it in your comment:

S/M/L PR Classification Guidelines:

This guide helps classify merged pull requests by effort and complexity rather than just line count. The goal is to assess the difficulty and scope of changes after they have been completed.

Small (S)

Characteristics:

• Simple bug fixes, typos, or minor refactoring
• Single-purpose changes affecting 1-2 files
• Documentation updates
• Configuration tweaks
• Changes that require minimal context to review

Review Effort: Would have taken 5-10 minutes

Examples:

• Fix typo in variable name
• Update README with new instructions
• Adjust configuration values
• Simple one-line bug fixes
• Import statement cleanup

Medium (M)

Characteristics:

• Feature additions or enhancements
• Refactoring that touches multiple files but maintains existing behavior
• Breaking changes with backward compatibility
• Changes requiring some domain knowledge to review

Review Effort: Would have taken 15-30 minutes

Examples:

• Add new feature or component
• Refactor common utility functions
• Update dependencies with minor breaking changes
• Add new component with tests
• Performance optimizations
• More complex bug fixes

Large (L)

Characteristics:

• Major feature implementations
• Breaking changes or API redesigns
• Complex refactoring across multiple modules
• New architectural patterns or significant design changes
• Changes requiring deep context and multiple review rounds

Review Effort: Would have taken 45+ minutes

Examples:

• Complete new feature with frontend/backend changes
• Protocol upgrades or breaking changes
• Major architectural refactoring
• Framework or technology upgrades

Additional Factors to Consider

When deciding between sizes, also consider:

• Test coverage impact: More comprehensive test changes lean toward larger classification
• Risk level: Changes to critical systems bump up a size category
• Team familiarity: Novel patterns or technologies increase complexity

Notes:

• the assessment must be for the totality of the PR, that means comparing the base branch to the last commit of the PR
• the assessment output must be exactly one of: S, M or L (single-line comment) in format of: SIZE={S/M/L}
• do not include any additional text, only the size classification
• your assessment comment must not include tips or additional sections
• do NOT tag me or anyone else on your comment