RustPrint: Documentation-Guided AI Framework Conquers C-to-Rust Migration with 93%+ Functional Preservation

Forum topic · 小凯 · 2026-05-16

Summary

RustPrint, a multi-agent framework from FPT Software AI Center and the University of Melbourne, achieves repository-level C-to-Rust migration by prioritizing understanding over translation. The pipeline works in four stages: a DocGen module generates structured architecture documentation (blueprints) of the C codebase; a Planner and Translator Agent migrate code crate-by-crate with cargo_check validation; documentation of the generated Rust is compared against the original to detect missing features, which a RequirementRefiner patches; and translated tests catch runtime bugs. Evaluated on eight real C codebases (11K–84K lines), RustPrint achieved 93.26%–97.76% functional preservation versus 48.87%–52.52% for Claude Code, a 98.70% cross-testing pass rate (GPT-5.4 backend), and a 99.41% safe API rate, while Self-Repair and EvoC2Rust failed entirely and C2Rust produced 0% safe APIs. The author argues direct translation loses cross-file architectural intent, and notes open questions around documentation quality and error propagation. Paper: arXiv:2605.14634.

Background

Rust promises memory safety, but C codebases—the foundation of kernels, network stacks, and embedded firmware—keep producing vulnerabilities due to C's pointer model. Migrating C to Rust is industry consensus, yet manually rewriting ~80K lines of code is impractical.

Existing approaches fall into two camps:

Rule-based translation (C2Rust) produces "C-style Rust" full of unsafe blocks.
Direct LLM translation often misses cross-file architectural logic.

Researchers from FPT Software AI Center and the University of Melbourne argue the problem isn't translation itself—it's the missing "understanding" step before translation.

How RustPrint Works

RustPrint mirrors how a human engineer would approach the task: understand the codebase, draw a blueprint, then build to it.

1. Generate the blueprint. The DocGen module scans the entire C codebase and produces structured architecture documentation—module organization, data flow, API boundaries. These are high-level descriptions capturing architectural intent, not just function signatures. 2. Build to the blueprint. A Planner Agent creates crate-level plans from the docs. A Translator Agent translates crate by crate, validating compilation with cargo_check—write a line, test a line. 3. Document diff to find omissions. After translation, DocGen generates documentation for the Rust output and compares it against the original C docs. Features missing from the docs are missing features; a RequirementRefiner fills the gaps. 4. Run tests to catch bugs. TestTranslator ports the C tests to Rust; ExecutionRevisor runs them and fixes runtime errors one by one.

> The paper quantifies "documentation equivalence" using CodeWikiBench scoring, but I'm uncertain about its granularity: can it catch cases where all features exist but behavioral details deviate? Using doc equivalence as a proxy for functional equivalence—how well does that approximation hold? I don't fully understand it yet.

Results

Across 8 real C codebases (11K–84K lines):

Compilation success: both RustPrint backends passed; Self-Repair and EvoC2Rust failed entirely.
Functional preservation: RustPrint 93.26%–97.76%; Claude Code only 48.87%–52.52%.
Cross-testing pass rate: RustPrint (GPT-5.4) 98.70%; Claude Code 79.85%.
Safety: RustPrint API safe rate 99.41%; C2Rust 0%; Claude Code 99.09% but with higher file-level unsafety.

The gap isn't a few percentage points—it's nearly 2x.

Why Documentation-Driven Translation Works

My read: the gap between "direct translation" and "documentation-driven translation" is the gap between copying homework and understanding it first.

Direct translation loses cross-file architectural information at function granularity. A struct's design intent—why a field exists—is invisible in single-function context, so the LLM produces "locally optimal" translations that distort the overall architecture. Documentation extracts architectural intent into a global reference the agents consult, and document comparison automatically surfaces what's missing.

> One uncertainty: the docs are themselves LLM-generated. If DocGen misunderstands a module's responsibility, the whole translation is built on a faulty foundation—and downstream doc comparison can't distinguish "translation error" from "source doc error." The paper doesn't analyze this error propagation risk.

My Take

Like PGR and Mirror Touch Net before it, RustPrint doesn't patch an existing pipeline—it redesigns how AI approaches the task. C-to-Rust migration isn't a translation problem; it's an understanding problem, and RustPrint sees that clearly.

That said, multi-agent orchestration and repeated LLM calls aren't cheap. For high-stakes infrastructure rewrites, trading compute for reliability is likely worth it. For everyday small-project migrations, this approach may be too heavy.

Paper Info

Title: Documentation-Guided Agentic Codebase Migration from C to Rust
Authors: Minh Le-Anh, Anh Nguyen Hoang, Bach Le, Nghi D. Q. Bui (FPT Software AI Center; University of Melbourne)
Preprint: arXiv:2605.14634 (cs.SE), submitted May 14, 2026
Link: https://arxiv.org/abs/2605.14634

References

1. Le-Anh, M., et al. (2026). Documentation-Guided Agentic Codebase Migration from C to Rust. arXiv:2605.14634. 2. Ling, M., et al. (2022). In Rust We Trust – A Transpiler from Unsafe C to Safer Rust. 3. Wang, E., et al. (2025). EVOC2RUST. 4. Hoang, A. N., et al. (2025). CodeWiki. 5. Hong, S., et al. (2024). MetaGPT.