- The paper introduces RustPrint, a documentation-centered multi-agent pipeline that plans, translates, refines, tests, and integrates entire C repositories as Rust crates.
- RustPrint compiled all eight evaluated repositories and achieved 93.26–97.76% feature coverage, outperforming Claude Code by more than 40 percentage points.
- The paper reports 95.17–98.70% cross-suite test pass rates and up to 99.41% API-level safety, while noting limits involving FFI, concurrency, build diversity, cost, and verification guarantees.
Motivation and problem statement
Legacy C repositories remain the substrate of systems software, but their pointer-centric memory model continues to produce critical vulnerabilities. Rust offers memory safety without sacrificing low-level control, yet manual migration of mature C codebases is expensive, and prior automated translators operate at the granularity of functions, files, or dependency-graph scaffolds. The authors argue that this unit-level framing misses what actually determines migration fidelity at scale: architectural intent, cross-file invariants, module boundaries, and behavioral contracts that cannot be recovered from isolated translation units. Their central proposal is to treat automatically generated repository-level documentation as an intermediate representation for the entire migration.
The RustPrint framework
RustPrint is a multi-agent pipeline with three stages grounded in a shared documentation artifact:
- Documentation-guided translation. A DocGen module (adapted from CodeWiki-style hierarchical documentation) clusters the source repository at the file level, lifts clusters into component abstractions, and produces feature-oriented documentation Sdoc​ emphasizing behavior to be preserved rather than C implementation details. Each high-level feature maps to a Rust crate. A Planner agent resolves API details from documentation and source, emitting an
IMPLEMENTATION_PLAN.md; a Translator implements each crate, iterating with cargo_check until compilation succeeds and using detect_unsafe to revise unsafe regions; a Synthesizer integrates crates, aligns interfaces, and writes the repository README.
- Requirement-driven refinement. DocGen runs again on the translated repository to yield Tdoc​, and functional preservation is approximated by documentation equivalence: CodeEquiv(S,T)≈DocEquiv(Sdoc​,Tdoc​), scored via CodeWikiBench with LLM-as-judge protocols. A RequirementRefiner agent repairs mismatches — recovering omitted features and misaligned APIs that compile cleanly but are absent or underspecified.
- Execution-aware revision. Because documentation comparison cannot expose runtime defects, a TestTranslator converts maintainer test suites into Rust, and an ExecutionRevisor debugs failing tests one by one with
cargo_single_test, modifying only translated code, never tests.
The refinement loop is explicitly an approximation: documentation equivalence is a proxy for semantic equivalence, not a guarantee, which is precisely why the execution-aware stage exists.
Evaluation setup
The benchmark comprises eight real-world GitHub C repositories from 11.4K to 83.7K LoC (libplist, check, stb, klib, libcbor, Monocypher, libfixmath, libyaml), each with a tests/ directory — a substantial step beyond prior benchmarks dominated by sub-1K-LoC repositories. Metrics are project compilability (cargo check), feature preservation via a weighted leaf-requirement coverage score (FCV), test pass rate (TPR), and safe rate at API level SR(A) and file level SR(F). Baselines are C2Rust, Self-Repair, EvoC2Rust, and Claude Code; backbones are Kimi-K2-Instruct (open-weight) and GPT-5.4.
A methodological point worth noting: the authors observe self-alignment bias when each system is evaluated only on its own generated tests, since TestTranslator agents tend to skip tests for features their own output failed to preserve. They therefore introduce a cross-test protocol in which a GPT-5.4-backed agent adapts every test function from one system's suite onto the other system's repository, preserving test logic while adapting APIs.
Results
Compilability. RustPrint produces fully buildable Cargo projects on all eight repositories under both backbones, as does Claude Code and C2Rust (the latter via unsafe syntactic transpilation). Self-Repair and EvoC2Rust fail to compile any repository end-to-end under either backbone — a stark result indicating that their coordination mechanisms do not scale past roughly 10K LoC.
Feature preservation. RustPrint attains average FCV of 93.26% (Kimi-K2-Instruct) and 97.76% (GPT-5.4), versus 52.52% and 48.87% for Claude Code — a gap exceeding 40 percentage points despite Claude Code's consistent compilability. Refinement curves show most gains materialize within the first one or two documentation-guided iterations before stabilizing, suggesting diminishing returns beyond early refinement rounds.
Functional correctness. Under cross-evaluation across all 16 repository × test-suite cells, RustPrint averages 95.17% TPR with Kimi-K2-Instruct and 98.70% with GPT-5.4, against 79.85% for Claude Code. Claude Code degrades sharply on RustPrint-authored suites — e.g., 35.71% on stb, 45.07% on libfixmath, 61.29% on libyaml — corroborating that its deficit stems from unpreserved functionality rather than test-suite idiosyncrasy.
Safety. With GPT-5.4, RustPrint achieves 99.41% SR(A) and 98.47% SR(F), the highest among all methods, and yields the largest number of fully safe projects; C2Rust scores 0.00 on both metrics while remaining buildable. Under Kimi-K2-Instruct, RustPrint reaches 96.23%/96.19%, competitive with LLM baselines.
The aggregate picture supports the paper's central claim: repository-scale migration is less a raw generation problem than a coordination problem, and documentation serves as an operational guide for refinement rather than mere context.
Limitations and open questions
The authors are candid about scope. Each configuration is evaluated in a single run, so no error bars or significance testing are reported — repeating the full multi-agent pipeline across seeds is cost-prohibitive. The benchmark, while realistic, does not cover heavy FFI usage, non-standardized build pipelines, or concurrency-heavy systems, so generalization to those regimes remains unverified. Documentation equivalence remains a proxy signal that works best when paired with compilation and translated tests; whether it suffices for safety-critical behaviors is open. The evaluation also omits wall-clock time, tool-usage counts, and monetary cost in the main text, though an appendix provides per-stage USD cost breakdowns. Finally, the framework assumes Cargo-based builds and per-repository test suites, both of which constrain applicability to heterogeneous industrial codebases.
Conclusion
RustPrint reframes repository-level C-to-Rust migration as a documentation-centered agentic workflow spanning planning, translation, requirement-driven refinement, and execution-aware repair. On eight repositories up to 83.7K LoC it compiles every target where recent LLM baselines fail entirely, exceeds an agentic Claude Code baseline by over 40 points on feature preservation and roughly 15 points on cross-suite TPR even with an open-weight backbone, and achieves the best safety profile among evaluated methods. The results establish documentation-guided coordination as a viable mechanism for scaling LLM-based translation, while leaving open how the approach extends to mixed-language repositories, deeper external dependencies, and stronger verification signals such as differential and property-based testing.