Req2Rust: A Requirements-Guided Agent Harness for Project-Level C++-to-Rust Migration

Req2Rust: A Requirements-Guided Agent Harness for Project-Level C++-to-Rust Migration Shengbo Wang, Mingwei Liu* , Yuwen Chen, and Yanlin Wang

arXiv:2611.07442v1 [cs.SE] 5 Nov 2026

Sun Yat-sen University wangshb25@mail2.sysu.edu.cn, liumw26@mail.sysu.edu.cn chenyw95@mail2.sysu.edu.cn, yanlin-wang@outlook.com

Abstract—Memory-safety concerns make Rust an attractive target for modernizing legacy C/C++ systems, yet project-level C++ migration must balance semantic fidelity with Rust-oriented reconstruction. Source-structure-preserving migration can track low-level behavior, but it can also carry source-language organization, unsafe idioms, and project assumptions into Rust. Direct agent-based translation gives the model more freedom to construct a Rust project, but semantic coverage depends on the model identifying the source behaviors that must be preserved. This problem is especially acute for C++, where source behaviors are often hidden in object models, destructor-driven lifetime protocols, and other hard-to-localize C++ semantics. This paper presents Req2Rust, the first project-level LLMbased C++-to-Rust migration harness. Req2Rust first derives an evidence-grounded Migration Requirements Specification (MRS) that records the behaviors and constraints that must be preserved. It then synthesizes a Rust Design Specification (RDS) and realizes it as an initial Rust project. Because real projects contain implementation details and idioms that only become visible during build and validation, Req2Rust treats the initial Rust project as an executable refinement state. Compiler, semantic, and unsafe-reduction validators produce validation reports for improving buildability, behavioral alignment, and unsafe usage. We evaluate Req2Rust on general C++ projects and modules from the large-scale Openharmony codebase against a ClaudeCode baseline. Req2Rust produces buildable Rust crates in both settings and improves test pass rate from 69.5% to 91.9% on general projects and from 45.4% to 87.9% on Openharmony modules. Index Terms—C++-to-Rust migration, code translation, requirements engineering, LLMs, agent harnesses

I. I NTRODUCTION Memory-safety vulnerabilities remain a persistent source of systems software failures because they arise from ordinary implementation patterns in memory-unsafe languages. Errors such as out-of-bounds access and use-after-free can be mitigated by static analysis, sanitizers, and hardening techniques, but these approaches operate within languages that still permit unsafe memory behavior. Rust has emerged as a promising alternative because its ownership and borrowing system enforces memory safety at compile time, making it an increasingly attractive target for modernizing legacy C/C++ systems [1]–[5]. However, migrating C/C++ systems to Rust is not merely a translation problem but a project-level redesign problem. Developers must recover intended behavior while reorganizing software around Rust’s ownership model, module structure, and ecosystem conventions [6], [7]. This creates a fundamental

tension between preserving semantic fidelity and enabling Rust-oriented reconstruction. A substantial body of prior work has studied C-toRust migration, primarily through rule-based translation and refinement-based approaches. These systems demonstrate that C programs can be systematically transformed into Rust while preserving low-level behavior, enabling traceability and incremental safety improvements [7]–[11]. However, they are largely designed for C, where program structure and semantics are comparatively explicit and procedurally organized. In contrast, C++-to-Rust migration remains significantly more challenging and less explored due to the richer and more implicit semantics of C++. C++ binds program behavior to object models, constructor and destructor lifecycles, template instantiation, overload resolution, callbacks, resource ownership protocols, and build-time conventions. These semantics are often distributed across files and only become observable through cross-module interactions and compilation behavior. As a result, project-level migration cannot rely on local translation alone, but must reason globally about which behaviors must be preserved and which can be restructured in Rust [6], [12]. With the emergence of LLMs, recent work has introduced new possibilities for automated program migration and code translation [13], [14]. LLM-based approaches are effective at local code transformation and iterative repair, and codingagent systems further extend this capability through executiondriven feedback loops. However, dedicated LLM-based C++to-Rust work remains sparse, and existing studies mainly operate at the snippet, feature, or translation-unit level rather than project-level reconstruction [12], [15]. These systems also rely on implicit inference of semantic preservation rather than explicit modeling of migration intent. This limitation becomes particularly severe in C++-to-Rust migration, where critical behaviors are often non-local and only observable at the project level. This reveals a key limitation of existing approaches: without an explicit mechanism to separate what must be preserved from how the target system should be reconstructed, LLM-based migration systems struggle to reliably support project-level C++-to-Rust migration. Table I summarizes this positioning across representative C/C++-to-Rust migration settings. Req2Rust addresses this gap through a three-stage

TABLE I P OSITIONING OF R EQ 2RUST AGAINST REPRESENTATIVE C/C++- TO -RUST MIGRATION SETTINGS . Migration setting

Representative work/system

Main scope

Gap for project-level C++ migration

Rule-based C-to-Rust migration Rule-based C++-to-Rust translation

C2Rust and later C-to-Rust refinement systems [7]–[9], [16]

C programs; source-aligned translation

Weak C++ object, lifetime, template, and build semantics.

Cpp2Rust [6]

Supported C++ subset; safe Rust translation

Limited end-to-end project reconstruction.

Function or unit translation with validation/repair

Not specialized for project-level C++ reconstruction.

Snippet, feature, or translation-unit translation

Limited project-wide preservation modeling.

Executable repair loop

Preservation remains implicit.

MRS + RDS + validation reports

Project-level LLM C++-to-Rust reconstruction.

LLM code translation to Rust LLM-based C++-to-Rust translation Direct coding-agent migration Req2Rust

Real-world Rust translation studies and general LLM translation frameworks [13], [14], [17] RAG-LLM C++ translation and C++ feature studies [12], [15] ClaudeCode and related coding-agent systems [18] This work

requirements-mediated pipeline. First, it moves preservation decisions out of the model’s implicit context and into an MRS, a language-neutral intermediate representation between C++ evidence and Rust implementation. The MRS records externally visible behavior, dependency assumptions, state and resource effects, and safety constraints as preservation obligations. By separating what must be preserved from how Rust will implement it, the MRS helps bridge the source-target language gap before Rust-specific design choices are made. Second, requirements-guided reconstruction synthesizes an RDS from the MRS and realizes it as an initial Rust project. Third, agent-harnessed refinement treats that project as an executable state. Compiler, semantic, and unsafereduction validators produce validation reports for a refinement agent, which iteratively fixes compilation failures, behavioral risks, and reducible unsafe usage. This creates a closed loop between requirements-guided project reconstruction and validator-guided refinement [19]. We evaluate Req2Rust on seven general C++ projects and five Openharmony modules against ClaudeCode. Req2Rust produces buildable Rust crates in both settings and improves test pass rate from 69.5% to 91.9% on general projects and from 45.4% to 87.9% on Openharmony modules. The ablation study shows that semantic validation drives most behavioral gains, while unsafe reduction lowers unsafe usage without reducing the observed test pass rate. This paper makes the following contributions: (1) We introduce MRS, a preservation-oriented intermediate representation for project-level C++-to-Rust migration. (2) We design a requirements-guided reconstruction pipeline that synthesizes an RDS and realizes it as an initial Rust project, followed by agent-harnessed refinement under validation reports. (3) We evaluate Req2Rust on general C++ projects and Openharmony modules, with ablation studies demonstrating its ability to produce buildable Rust crates with stronger behavioral preservation and lower unsafe usage. II. M ETHODOLOGY Req2Rust formulates project-level C++-to-Rust migration as a requirements-mediated process. The input is a C++ project or module together with source, interface, and build evidence,

and the output is a Rust crate that can be compiled, inspected, and refined under validation reports. The central design choice is to separate preservation obligations from target-side implementation: the MRS records externally visible behavior, dependency assumptions, state and resource effects, and safety-relevant constraints, while Rust project reconstruction decides how these obligations should be organized as a Rust crate. Figure 1 shows this workflow: Req2Rust first models preservation obligations as an MRS, then synthesizes an RDS and realizes an initial Rust project, and finally refines the executable project state through validator-guided agent actions. A. Migration-Oriented Requirement Modeling Req2Rust first constructs an MRS from the source project. This stage turns heterogeneous source-code, interface, and build evidence into a preservation target for later reconstruction and validation. The MRS summarizes the source module from the perspective of migration: it records project-level obligations for the initial Rust project and removes sourcelanguage syntax from the main generation target. The MRS groups migration-relevant information into several categories. It records externally observable interfaces, including public API identity, ownership, callable shape, parameters, return behavior, and visibility. It records behavioral facts, including normal behavior, input and output constraints, failure behavior, state effects, and dependency effects. It also records external dependencies and exposed symbols, so later stages can separate behavior implemented by the source project from behavior delegated to external libraries or platform APIs. For project-level behavior that spans multiple functions, the MRS captures state and resource facts, cross-API relationships, and open migration items that require later validation. The resulting artifact explicitly separates what must be preserved from how the Rust project will implement it. B. Requirements-Guided Rust Project Reconstruction Req2Rust then reconstructs a Rust project from the MRS. This stage answers the target-side question left open by the requirements: which files, modules, public items, helpers, and implementation units should carry each obligation? It contains two sub-stages, Requirements-Driven Rust Design Synthesis and Design-Guided Project Realization.

A. Migration-Oriented Requirement Modeling

B. Requirements-Guided Rust Project Reconstruction File-Architecture Design LLM

C++ Project

RDS Requirement Planning Agent

1

File-Level Design

2

Implementation Units Parallel Unit Code Generation

3 Feature Agent 1

Feature Agent 2

Feature Agent 3

•••

Feature Agent x

mod_io.rs

mod_core.rs

mod_net.rs

u1 u2 u3 · ·· u1 u2 u3 ··· u1 u2 u3 ··· u1 u2 u3 ···

Project Assembly

5

Initial Complete Rust Project

•••

••• •••

Generated Rust source files

4

mod_api.rs

Crate skeleton

Project Assembly

MRS

Initial Rust Project

C. Agent-Harnessed Refinement Main Refinement Agent

Translation Harness Validators

Validation Reports

Semantic Validator

Compiler Validator

review & integrate

Parallel Subrefinement Agents

•••

Refined Rust Project

iterate until all gates accepted

cargo check

Parallel Semantic Audit Subagents

•••

UnsafeReduction Validator unsafe { ... }

Fig. 1. Overall workflow of Req2Rust. The harness first derives an MRS from source evidence, synthesizes an RDS from the MRS, realizes an initial Rust project, and then refines the project through validation reports from compiler, semantic, and unsafe-reduction validators.

1) Requirements-Driven Rust Design Synthesis: Requirements-driven Rust design synthesis translates preservation obligations into an RDS. The RDS specifies the project organization used for realization, including Rust files, file responsibilities, module dependencies, owned symbols, public-facing surfaces, and the implementation units assigned to each file. The RDS also carries global design constraints. These constraints describe the shared Rust model that should be used across files, such as common data structures, error handling conventions, resource ownership, serialization or formatting paths, and other cross-file behavior. This prevents later unit construction from treating each source fragment as an isolated translation task. Within each file, Req2Rust further decomposes the design into implementation units. A unit corresponds to a Rust item such as a function, type, trait, implementation block, constant, or helper. Each unit records its intended signature, responsibility, call relationships, and the MRS entries it is expected to satisfy. The RDS therefore bridges requirements and project realization: the MRS defines source-side obligations, and the RDS converts them into target-side structure. Figure 2 summarizes the schemas of the two structured artifacts. The MRS records source-side preservation obligations, while the RDS organizes those obligations into Rust project

Schema ➢ ➢ ➢ ➢

Schema ➢ ➢ ➢ ➢

MRS

Source scope and evidence anchors ➢ Public interfaces and exposed symbols ➢ Behavioral obligations ➢ Dependency and platform assumptions

Target files and module roles Public-facing Rust surface Owned symbols and dependencies Global design constraints

State and resource effects Cross-API constraints Validation targets and open items

RDS ➢ ➢ ➢

Ordered implementation units MRS coverage links Open design assumptions

Fig. 2. Schemas of the MRS and RDS artifacts. The MRS records source-side preservation obligations, while the RDS organizes those obligations into Rust project design decisions.

design decisions. 2) Design-Guided Project Realization: Design-guided project realization materializes the RDS into an initial Rust project. A realization planner first orders implementation units and groups them into construction batches according to their file targets and call dependencies. A renderer then creates a marker-based Rust skeleton: source files, crate structure, module declarations, and placeholder regions that can later be replaced by generated unit bodies. Req2Rust then translates unit bodies under the constraints provided by the RDS and

MRS. The body application step writes generated unit bodies back into the marker-based skeleton. A Rust crate assembly step completes the crate root, manifest, module exports, and dependency skeleton needed for ordinary Rust tooling. The initial Rust project is treated as a refinable project artifact. It provides the concrete source files that validators and the refinement agent inspect and modify in the next stage. The MRS and RDS recover the main preservation targets, and the initial Rust project carries the remaining implementation details into executable refinement. C. Agent-Harnessed Refinement The final stage refines the initial Rust project through an agent harness. This stage exists because project reconstruction can produce a coherent crate while still missing details that only appear during compilation, semantic checking, or unsafe-use analysis. The harness maintains the current project state, invokes validators, collects validation reports, and feeds those reports back to the refinement agent. The refinement agent updates the existing Rust project and preserves the accumulated validation context. Req2Rust uses three Translation Harness Validators. The Compiler Validator checks whether the current Rust project is buildable and localizes compilation failures, missing items, and type or API mismatches. The Semantic Validator compares the current Rust project with the MRS and source evidence through observable contracts: normal behavior, boundary and error behavior, state and resource effects, and publicfacing coverage. Its validation report connects potential divergence to the relevant preservation obligation, Rust location, source evidence, and repair rationale. The Unsafe Reduction Validator analyzes unsafe usage with the same preservationoriented view. It distinguishes unsafe code that protects migration boundaries from unsafe code that can be reduced within the Rust implementation. Boundary unsafe is retained when it is needed for ABI compatibility, layout preservation, extern calls, resources, callbacks, or ownership transfer across the migrated interface. Reducible unsafe is reported when equivalent observable behavior can be expressed through safe Rust abstractions or through a smaller unsafe wrapper. These validators return validation reports that serve as editing targets for the refinement agent. Each report contains actionable findings, including compilation errors, semantic mismatches, unsafe-reduction opportunities, and links to the relevant preservation obligations. The refinement agent edits the Rust project according to these reports, and Req2Rust validates the updated project again. When findings are independent, Req2Rust can assign them to parallel refinement agents and merge the changes before the next validation round. The loop terminates when the configured acceptance criteria are satisfied or the refinement budget is exhausted. D. Concrete Artifact Trace Across Req2Rust Figure 3 illustrates Req2Rust on two real artifact traces from paho.mqtt.cpp. The figure shows how specific source

obligations are converted into intermediate artifacts that guide generation and repair. Panel A follows the message model. Source declarations and constructor bodies show that a message must preserve topic/payload construction, reconstruction from an existing C MQTT message, QoS and retained-state setters, and property updates. The MRS turns these facts into named preservation targets, and the RDS assigns the target to src/message.rs. The initial generated code created a plausible Message struct but missed from_c_message and several setter behaviors; the repair task localizes the fix to the message model and the final code restores the missing reconstruction and setter paths. Panel B follows client publishing. The source evidence links the public publish API to message creation, delivery-token registration, the MQTTAsync_sendMessage call, success recording, and token cleanup on failure. The MRS records these as publish, buffer, user-context, and listener obligations, and the RDS routes them to src/client.rs with dependencies on the message, token, option, error, and threading modules. The initial generated code still used a placeholder send result and incomplete callback/consumer paths; the repair task spans the client-facing files and restores the publish path, callback dispatch, consumer events, and token-removal behavior. The two traces show that source snippets are not translated in isolation. They are first converted into named obligations, assigned to Rust files and units, and then used to scope validation reports so the refinement harness can repair concrete behavioral gaps without losing the source evidence that explains why those gaps matter. III. E VALUATION S ETUP A. Subjects and Settings Req2Rust targets project-level migration, so the benchmark must expose more than isolated function bodies. We therefore include multi-file projects with build context and diverse C++ features. The first subject group consists of general C++ projects with available tests, diverse domains, different code sizes, and combinations of C++ language features. The second subject group consists of Openharmony modules, which exercise migration inside a large real-world codebase [20]. For the Openharmony setting, incremental migration means replacing selected C++ modules with Rust crates while the rest of the codebase remains in place. The translated crate must preserve source-facing interfaces, platform calls, resource and callback boundaries, and build assumptions required by the surrounding codebase. This differs from a standalone Rust rewrite because some unsafe code may represent necessary ABI, FFI, or platform-resource boundaries. B. Feature Characterization To guide subject selection and characterize migration difficulty, we classify C++ features using the taxonomy in Table II. The taxonomy summarizes the feature coverage used to select and compare benchmark subjects. The RQ1 and RQ2 result tables include a Categories column that reports how many

A. message model trace MRS

RDS

Unit design

Initial Rust Project

include/mqtt/message.h

Source evidence

sem.doc.message_model

RDS: src/message.rs

unit design: src/message.rs

MQTTAsync_message msg_{DFLT_C_STRUCT}; string_ref topic_; binary_ref payload_; properties props_; message(topic, const void* payload, len, qos, retained, props); message(topic, binary_ref payload, qos, retained, props); message(topic, const MQTTAsync_message& cmsg);

Feature unit: unit_003 Source files: include/mqtt/message.h; src/message.cpp; include/mqtt/buffer_ref.h Relevant symbols: message::message, get_topic, get_payload, get_qos, set_retained, ... Key behaviors: • construct with topic + payload + qos + retained + props • construct from MQTTAsync_message and copy fields / properties • preserve shallow reference semantics where appropriate

Rust file: file.rust.message Role: implement MQTT message model Based on: sem.doc.message_model Main symbols: struct Message Relevant units: unit.rust.message.message_struct; unit.rust.message.message_impl

unit.rust.message.message_ struct

src/message.cpp : topic_(std::move(topic)) { set_payload(payload, len); set_qos(qos); set_retained(retained); set_properties(props); } : msg_(cmsg), topic_(std::move(topic)), props_(cmsg.properties) { set_payload(cmsg.payload, cmsg.payloadlen); msg_.properties = props_.c_struct(); }

unit.rust.message.message_struct Signature: pub struct Message Purpose: define the Rust data structure for MQTT messages

unit.rust.message.message_impl Signature: impl Message Purpose: implement new(...), set_payload(...), getters, QoS validation

Repair task: Message Model Refinement Expected behavior: validate QoS, provide setters, support construction from C message Outcome: topic uses Arc<str>; from_c_message copies payload / properties; set_topic, set_qos, and set_retained are present; cargo passed

Refined Rust Project

final src/message.rs excerpt

• missing from_c_message() • missing set_topic / set_qos / set_retained

pub struct Message { pub topic: Arc<str>, pub payload: Arc<Vec<u8>>, pub qos: u8, pub retained: bool, pub properties: Properties, } impl Message { pub fn new( topic: &str, payload: &[u8], qos: u8, retained: bool, props: Option<Properties>, ) -> Result<Self, Error> { ... } pub fn from_c_message( topic: &str, cmsg: &MQTTAsync_message,) -> Self { ... } pub fn set_topic(&mut self, topic: impl Into<Arc<str>>) { self.topic = topic.into(); } pub fn set_qos(&mut self, qos: u8) -> Result<(), Error> { ... } pub fn set_retained(&mut self, retained: bool) { self.retained = retained; } }

Initial Rust Project

Refined Rust Project

pub struct Message { pub topic: String, pub payload: Arc<Vec<u8>>, pub qos: u8, pub retained: bool, pub properties: Properties, } impl Message { pub fn new(...) -> Self { ... } }

Validation Reports

B. client publish trace Source evidence

MRS

Unit design

RDS

include/mqtt/async_client.h

sem.doc.publishing

RDS: src/client.rs

unit design: src/client.rs

unit.rust.client.publish

final src/client.rs excerpt

delivery_token_ptr publish( string_ref topic, const void* payload, size_t n, int qos, bool retained, const properties& props = properties() ) override; delivery_token_ptr publish( string_ref topic, binary_ref payload, int qos, bool retained, const properties& props = properties() ) override; delivery_token_ptr publish( const_message_ptr msg, void* userContext, iaction_listener& cb ) override;

Feature unit: unit_004 Source files: include/mqtt/async_client.h src/async_client.cpp include/mqtt/delivery_token.h include/mqtt/topic.h src/topic.cpp Relevant symbols: async_client::publish delivery_token::delivery_token topic::publish Key behaviors: • create delivery token and send • preserve user context and listener behavior Important obligations: • public API: • async_client::publish preserve buffer semantics

Rust file: file.rust.client Role: core AsyncClient state and operations: publish, callbacks, event consumer Based on: sem.doc.publishing sem.doc.message_reception sem.doc.event_consumer sem.doc.thread_safety Main symbols: struct ClientState, struct Client Relevant units: unit.rust.client.publish unit.rust.client.callback unit.rust.client.event_consumer Depends on: src/token.rs, src/message.rs, src/options.rs, src/error.rs, src/threading.rs

unit.rust.client.publish Signature: fn publish(...) Purpose: create delivery token, send, remove token on failure

pub fn publish(&self, msg: Message) -> Result<Arc<Token>, Error> { let token = Arc::new(Token { ... }); state.add_token(token.clone()); let send_result = if msg.topic.is_empty() { Err(...) } else { Ok(1u16) }; match send_result { Ok(id) => { token.inner.lock().unwrap().message_id = id; Ok(token) } Err(e) => { state.remove_token(&*token); Err(e) } } }

pub fn publish(&self, msg: crate::Message) -> Result<Arc<Token>, Error> { self.publish_internal(msg, std::ptr::null_mut(), None) } pub fn publish_with_listener( &self, msg: crate::Message, user_context: *mut c_void, listener: Box<dyn crate::ActionListener>, ) -> Result<Arc<Token>, Error> { self.publish_internal(msg, user_context, Some(listener)) } fn publish_internal(...) -> Result<Arc<Token>, Error> { ... } // C callback path let topic = if topic_name.is_null() { String::new() } else { ... }; let cmsg = unsafe { &*msg }; let mqtt_msg = crate::Message::from_c_message(&topic, cmsg); if let Some(ref handler) = state.message_handler { handler(mqtt_msg.clone()); } if let Some(ref cb) = state.callback { cb.message_arrived(mqtt_msg.clone()); } if let Some(ref queue) = state.consumer_queue { let _ = queue.put(Event::Message(mqtt_msg)); } free_message(&mut msg);

src/async_client.cpp auto msg = message::create( std::move(topic), payload, n, qos, retained, props ); return publish(std::move(msg)); auto msg = message::create( std::move(topic), payload, n, qos, retained ); return publish(std::move(msg), userContext, cb); auto tok = delivery_token::create(*this, msg); add_token(tok); int rc = MQTTAsync_sendMessage( cli_, msg->get_topic().c_str(), &(msg->msg_), &rspOpts.opts_ ); if (rc == MQTTASYNC_SUCCESS) tok->set_message_id(rspOpts.opts_.token); else { remove_token(tok); throw exception(rc); }

unit.rust.client.callback Signature: fn on_*_callback(...) Purpose: dispatch raw C callbacks to handler / callback object / consumer queue unit.rust.client.event_consumer Signature: fn consume_message(...) Purpose: ThreadQueue<Event> based consumer mode

Repair task: Client PublishCallback Refinement

Validation Reports

Affected files: src/client.rs, src/lib.rs, src/persistence.rs, Cargo.toml, src/options.rs Expected behavior: full async publish path; callback dispatch; event consumer integration Outcome: publish path goes through publish_internal; C callback builds Message from raw topic/message; dispatches to handler / callback / consumer_queue; final gate accepted

• placeholder send result: Ok(1u16) • no real MQTTAsync_sendMessage path • incomplete callback / consumer integration

Fig. 3. Concrete artifact traces for paho.mqtt.cpp. Panel A tracks message-model preservation from source evidence to the MRS, RDS, unit design, initial generated code, and final repaired code. Panel B tracks client publish behavior through the same artifacts, including the repair tasks and initial validation reports.

TABLE II C++ FEATURE TAXONOMY USED FOR BENCHMARK CHARACTERIZATION .

ID

Category

C1 C2 C3 C4 C5 C6 C7 C8 C9 C10

Basic declarations and type system Function, call, and callable semantics Pointer, layout, and low-level memory operations Resource and lifetime management Classes and object model Inheritance and polymorphism Templates and generic programming STL and library abstractions Error handling and non-local control flow Concurrency and synchronization

taxonomy categories each project or module covers, together with project size and evaluation results.

C. Baseline We compare Req2Rust with a ClaudeCode baseline. ClaudeCode is a state-of-the-art general-purpose agentic coding system that can read a codebase, edit files, run tests, and iterate on failures [18]. This makes it a strong baseline for direct agent-based project migration. Both Req2Rust and the ClaudeCode baseline use DeepSeek-V4-Pro as the underlying language model. We do not use Cpp2Rust as a baseline because it currently supports only a subset of C++ language features [6]. This subset does not cover all subjects in our benchmark and does not provide a general end-to-end project migration baseline for our setting. D. Metrics We report three metrics.

Compilable. This metric records whether the final generated Rust project is compilable. It measures the basic engineering viability of the translated project. Test pass rate. This metric reports the percentage of available tests that pass after translation. Unsafe rate. This metric measures the amount of unsafe usage in the generated Rust project.

C++ source excerpt

ClaudeCode

Req2Rust

message(string_ref topic, binary_ref payload, int qos, bool retained, const properties& props); message(string_ref topic, const MQTTAsync_message& cmsg); bool is_retained() const { return to_bool(msg_.retained); } void set_payload(const void* payload, size_t n); // source: byte payload + C-message reconstruction

E. Ablation Variants For RQ3, we evaluate four executable variants on the same seven general C++ subjects. Full Req2Rust uses designguided project realization followed by compiler, semantic, and unsafe-reduction validators. No semantic validator keeps compiler validation and unsafe reduction while removing semantic-validator feedback. No unsafe reduction keeps compiler and semantic validation and stops before the unsafereduction validator. Initial Rust only evaluates the initial Rust project before validator-guided refinement. IV. E XPERIMENTAL E VALUATION We organize the evaluation around three research questions: RQ1. How effectively does Req2Rust migrate general C++ projects into buildable and testable Rust crates? RQ2. How effectively does Req2Rust support incremental migration in a large-scale real-world codebase? RQ3. Which components of requirements-mediated migration contribute to migration quality? A. RQ1: General C++ Project Migration Effectiveness RQ1 evaluates whether Req2Rust can turn general C++ subjects into buildable and testable Rust crates, and whether explicit requirements improve source-behavior preservation compared with direct agent-based migration. We report project scale, C++ feature coverage, compilability, test pass rate, and unsafe usage. 1) Overall Migration Results: Table III reports the RQ1 results on seven general C++ subjects. All generated crates from both systems compiled, so the main difference appeared in behavior tests. Req2Rust passed 91.9% of tests overall, compared with 69.5% for ClaudeCode. Req2Rust achieved full pass rates on paho.mqtt.cpp, hsmcpp, fkYAML, and csvparser, and improved over ClaudeCode on six of the seven subjects. The subjects cover 7–10 C++ feature categories each, including object models, resource management, templates, low-level memory operations, and concurrency. 2) Behavioral Accuracy and Source-Semantic Preservation: The largest gap occurred in paho.mqtt.cpp, where Req2Rust passed 100.0% of tests and ClaudeCode passed 3.3%. Figure 4 shows the reason at the code level. The C++ source exposes message construction over byte payloads, retained flags, and a C MQTT message structure. ClaudeCode constructed a Rustoriented message abstraction, but changed constructor and accessor shapes used by the migrated tests. Req2Rust preserved these migration-facing message behaviors, including byte-slice construction, retained-flag access, and reconstruction from C MQTT messages.

pub fn new(topic: impl Into<String>, payload: Vec<u8>, qos: i32, retained: bool, properties: Properties, ) -> Result<Self> { ... } pub fn is_retained(&self) -> bool { self.retained } pub fn is_duplicate(&self) -> bool { self.duplicate } // issue: no source-facing C-message constructor pub fn new(topic: &str, payload: &[u8], qos: u8, retained: bool, props: Option<Properties>) -> Result<Self> { ... } pub fn from_c_message(topic: &str, cmsg: &MQTTAsync_message) -> Self { ... } pub fn retained(&self) -> bool { self.retained }

// preserved: byte-slice API + C-message path

Fig. 4. Code-level comparison on paho.mqtt.cpp. The source exposes message constructors and accessors that are exercised by migrated tests. Req2Rust preserves the source-facing constructor shape and C-message reconstruction path.

HFSM2 shows a different pattern. ClaudeCode captured the high-level state-machine structure, but represented internal activity state with generic vectors. Req2Rust reconstructed the project-specific byte-backed fixed-capacity bitset behavior, including bit-level get, set, clear, and clear-all behavior. Figure 5 shows this difference. This abstraction explains a cluster of HFSM2 tests covering runtime bit access, cross-byte access, zero-capacity behavior, and masking. 3) Project-Level Rust Reconstruction: Beyond individual functions, RQ1 also reveals a larger advantage: Req2Rust more often carries source-level subsystem boundaries into a natural Rust crate structure. We use fkYAML as a representative example because both systems compiled the project and reached high test pass rates, but the generated crates expose different architecture. The source project is not just a YAML node type; it contains parsing and serialization entry points, value conversion traits, input handling, tag and anchor mechanisms, and UTF encoding utilities. Figure 6 compares these source obligations with the two generated Rust crates. This example shows why Req2Rust can produce a more natural Rust project even when a direct migration already compiles. Req2Rust’s RDS makes source obligations explicit before project realization, so the Rust crate contains separate modules for parse, serialize, convert, io, tag, anchor, and encoding, and then re-exports the corresponding public APIs. These boundaries give each migrated requirement a stable implementation location and make validation reports local to the relevant subsystem. ClaudeCode instead

TABLE III RQ1 RESULTS FOR GENERAL C++ PROJECT MIGRATION .

Project

Files

bitsery paho.mqtt.cpp uriparser HFSM2 hsmcpp fkYAML csv-parser Mean

Code Lines

Functions

Categories

Compilable

Test Pass Rate

Unsafe Rate

Ours

ClaudeCode

Ours

ClaudeCode

Ours

ClaudeCode

33 26 17 52 36 26 33

6041 5379 5012 10859 5351 14702 6459

623 666 861 415 431 1747 700

10 9 7 9 9 8 10

Yes Yes Yes Yes Yes Yes Yes

Yes Yes Yes Yes Yes Yes Yes

93.3% 100.0% 83.3% 66.7% 100.0% 100.0% 100.0%

83.3% 3.3% 93.3% 33.3% 90.0% 96.7% 86.7%

1.93% 6.83% 3.22% 0.36% 0.93% 0.06% 0.11%

2.67% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00%

31.9

7,686.1

777.6

8.9

100.0%

100.0%

91.9%

69.5%

1.78%

0.31%

C++ source excerpt

ClaudeCode

Req2Rust

template <unsigned NCapacity> class BitFlatSetT final { static constexpr Index CAPACITY = NCapacity; static constexpr Index UNIT_COUNT = ceil(CAPACITY / 8); uint8_t _storage[UNIT_COUNT] {}; bool get(const TIndex index) const noexcept; void set(const TIndex index) noexcept; void clear(const TIndex index) noexcept; }; // source: fixed-capacity byte-backed bitset pub struct Registry { state_infos: Vec<StateInfo>, active_states: Vec<bool>, resumable_states: Vec<bool>, active_sub_states: Vec<Prong>, ... // issue: bitset behavior flattened into vectors }

pub struct BitFlatSet<const UNIT_COUNT: usize> { storage: [u8; UNIT_COUNT], } impl<const UNIT_COUNT: usize> BitFlatSet<UNIT_COUNT> { pub fn get(&self, index: Short) -> bool { ... } pub fn set(&mut self, index: Short) { ... } pub fn clear(&mut self, index: Short) { ... } pub fn clear_all(&mut self) { self.storage = [0; UNIT_COUNT]; } } // preserved: const-generic byte-backed bitset behavior

Fig. 5. Code-level comparison on HFSM2. The source defines a template bitset utility used by state-machine support code. Req2Rust reconstructs bytebacked fixed-capacity bitset behavior as a Rust const-generic abstraction, while ClaudeCode uses generic vector fields inside the registry.

exposes a smaller public surface centered on YamlNode, with parser and serializer kept as crate-private implementation details and no first-class public boundary for conversion, anchors, tags, input abstractions, or encoding. The remaining unimplemented! in its public iterator further illustrates the risk of translating local APIs without first reconstructing the project-level obligations that those APIs must support. Thus, Req2Rust’s benefit in RQ1 is not only higher test accuracy;

it also reconstructs source projects into Rust crates whose modules correspond to the original library responsibilities. Overall, RQ1 shows that Req2Rust’s gains come from preserving project-specific source behavior before Rust reconstruction. The aggregate results show higher test pass rates across the general subjects, while the paho.mqtt.cpp and HFSM2 cases show how explicit requirements preserve migration-facing APIs and source-specific utilities. The fkYAML case shows the same mechanism at the projectstructure level, where source responsibilities become public Rust modules and re-exports. ClaudeCode’s stronger result on uriparser indicates that direct agent-based migration can still be competitive on compact parsing-oriented behavior. B. RQ2: Openharmony Large-Codebase Incremental Migration RQ2 moves the same design into Openharmony, where translated Rust modules must coexist with a larger existing codebase. This setting stresses interface compatibility, platform calls, and build constraints during incremental migration. We report source scale, feature coverage, compilability, module-level test pass rates, and unsafe usage. 1) Overall Migration Results: Table IV reports results on five Openharmony modules that collectively cover all ten C++ feature categories in our taxonomy. Both systems produced compilable Rust crates, but Req2Rust achieved a much higher mean pass rate than ClaudeCode, 87.9% versus 45.4%. The largest gap appears in a module where the migrated probes depend on source-facing utility and system-service surfaces, notification ans service. 2) Behavioral Accuracy and Source-Semantic Preservation: notification ans service provides the Openharmony behavioral example. The C++ DistributedDeviceStatus implementation updates only the status bits selected by controlFlag; it also maps liteWearable updates onto the wearable device channel. The source tests observe this behavior through deviceStatus_.Find(...) and ReadVal(...). Figure 7 shows that ClaudeCode translated this subsystem into a simpler two-argument status map, which compiled but did not expose the control-flag and map-facing behavior required by the migrated probes. Req2Rust preserved the source-observable device-status channel behavior through

fkYAML source obligations

ClaudeCode

Req2Rust

pub mod error; pub mod node; pub mod node_type; pub mod version;

class node_value_converter; class basic_node;

pub mod node; pub mod error; pub mod parse; pub mod serialize; pub mod convert; pub mod io; pub mod tag; pub mod anchor; pub mod encoding;

from_node_function_t = T::from_node(...); to_node_function_t = T::to_node(...);

pub(crate) mod parser; pub(crate) mod serializer;

std::multimap<std::string, BasicNodeType> anchor_table;

pub fn iter(&self) -> Result<...> { match &self.value { NodeValue::Sequence(seq) => Ok(Box::new(... unimplemented!( "Use values() or iter_seq()" ))), ... // issue: public path incomplete } }

pub use node::YamlNode;

lexical_token_t::ANCHOR_PREFIX; lexical_token_t::TAG_PREFIX; // obligations: conversion, parser, anchors, tags

pub use parse::{deserialize, Lexer, Parser, Token}; pub use convert::{FromNode, ToNode}; pub use io::{Input, FileInput, StringInput, StreamInput}; pub use tag::{Tag, TagResolver, resolve_implicit_tag}; pub use anchor::AnchorTable; // public boundaries match source responsibilities

Fig. 6. Project-level code comparison on fkYAML. The source exposes parsing, serialization, conversion, tag, anchor, and encoding obligations. Req2Rust maps these obligations to public Rust modules and re-exports, while ClaudeCode centers the crate on YamlNode, keeps parser and serializer modules internal, and leaves a public sequence-iteration path unimplemented. TABLE IV RQ2 RESULTS FOR O PENHARMONY MODULE MIGRATION .

Module wmserver deviceprofile core graphics effect notification ans service relational rdb Mean

Files

Code Lines

Functions

Categories

Compilable

Test Pass Rate

Unsafe Rate

Ours

ClaudeCode

Ours

ClaudeCode

Ours

ClaudeCode

117 148 157 238 115

18,967 14,630 10,018 26,537 18,590

1,009 676 533 1,257 1,323

10 10 10 10 10

Yes Yes Yes Yes Yes

Yes Yes Yes Yes Yes

83.3% 100.0% 100.0% 100.0% 56.3%

50.0% 26.7% 97.3% 0.0% 53.1%

0.60% 0.98% 0.21% 1.01% 3.43%

0.00% 0.00% 0.13% 0.00% 0.10%

155.0

17,748.4

959.6

10.0

100.0%

100.0%

87.9%

45.4%

1.07%

0.03%

a Rust provider abstraction and probe-visible set/get paths, so the migrated probes could check the same wearable-channel effects. 3) Platform-Boundary Preservation in Incremental Migration: RQ2 also changes how unsafe usage should be interpreted. In a standalone Rust rewrite, lower unsafe usage is usually preferable. In Openharmony incremental migration, however, translated Rust modules must still call C/C++ platform services, window tokens, RenderService operations, SQLite APIs, and OS helpers. Some unsafe code is the necessary boundary through which Rust reuses the surrounding system rather than replacing it with an isolated model. Figure 8 illustrates this point on wmserver. The C++ source calls RenderService and window-token APIs such as surface bounds updates, transaction flushing, focus-app registration, and zoom-transform propagation. ClaudeCode largely models the corresponding state as Rust fields and local methods. Req2Rust instead isolates those calls in explicit Rust adapter modules, such as rs_adapter.rs and token_adapter.rs, whose unsafe blocks wrap the FFI calls. The unsafe rate is therefore higher, but it reflects preserved platform boundaries needed for an incremental Openharmony replacement. Together, the RQ2 examples show that Req2Rust preserves both source-observable behavior and explicit platform-call

TABLE V A BLATION RESULTS ON THE SEVEN GENERAL C++ SUBJECTS .

Variant

Build

Tests

Unsafe

Full Req2Rust No semantic validator No unsafe reduction Initial Rust only

7/7 7/7 7/7 0/7

91.90% 28.10% 91.90% 0.00%

1.7757% 1.3227% 4.9950% 3.3392%

boundaries in an incremental Openharmony setting, while still producing compilable Rust crates with higher mean pass rates. C. RQ3: Ablation Study RQ3 asks which parts of the pipeline account for the observed migration quality. We construct executable ablations that remove semantic validation, unsafe reduction, or agentharnessed refinement while keeping the remaining evaluation procedure fixed. Table V separates the roles of design-guided project realization, semantic validation, and unsafe reduction. The initial Rust projects did not compile on any of the seven subjects, while the full harness compiled all seven and passed 91.90% of tests. This gap shows that the initial Rust project provides a project object for subsequent refinement, and that validator-

C++ source excerpt

ClaudeCode

Req2Rust

ErrCode SetDeviceStatus(deviceType, status, controlFlag); ASSERT_TRUE(deviceStatus_.Find("wearable", value)); ASSERT_TRUE((ReadVal("wearable") & status) != 0); // source: controlFlag + wearable channel pub fn set_device_status(&self, device_id: &str, status: i32) { statuses.insert(device_id.to_string(), status); } // issue: no controlFlag / Find surface pub trait DeviceStatusProvider { fn get_device_status(&self, device_type: &str) -> u32; } provider.set("not_liteWearable", 1); assert_eq!(provider.get_device_status("wearable"), 0); // preserved: source-observable status channel

Fig. 7. Code-level comparison on Openharmony notification ans service. The source updates device status through control-flagged bit operations and exposes wearable-channel map queries. ClaudeCode produces a simpler local status setter, while Req2Rust preserves the source-observable device-status channel behavior required by the migrated probes.

C++ source excerpt

ClaudeCode

C++ source excerpt

No semantic validator

Full Req2Rust

rc_ = MQTTASYNC_SUCCESS; complete_ = true; if (listener) listener->on_success(*this); cond_.notify_all(); cli_->remove_token(this); // source: callback + wakeup + client cleanup pub(crate) fn on_success(&self, response: TokenResponse) { let mut inner = self.inner.lock().unwrap(); inner.result = Some(Ok(response)); inner.completed = true; drop(inner); self.condvar.notify_all(); } // issue: callback and client cleanup omitted pub fn on_success(&self, response: TokenResponse) { let mut inner = self.inner.lock().unwrap(); inner.result = Some(Ok(response)); inner.completed = true; drop(inner); // ... listener.on_success(self) ... self.condvar.notify_all(); self.remove_self_from_client(); } // restored: source-observable completion effects

Req2Rust

windowToken_->UpdateZoomTransform(trans, is_on); node->surfaceNode_->SetBounds(x, y, w, h); RSTransactionAdapter::FlushImplicitTransaction(...); RSInterfaces::GetInstance().SetFocusAppInfo(appInfo); // source: RS + window-token platform boundary pub struct WindowNode { pub surface_node_id: u64, window_token: Option<u64>, } pub fn request_focus(&mut self, id: u32) { ... } // issue: boundary becomes local Rust state extern "C" { fn RsTokenUpdateZoomTransform(...); }

pub fn update_zoom_transform(...) { unsafe { RsTokenUpdateZoomTransform(...); } } pub fn flush_rs_transaction() { unsafe { ... } } // preserved: external calls isolated in adapters

Fig. 8. Incremental-migration boundary example from Openharmony wmserver. The source relies on RenderService and window-token calls. Req2Rust keeps these platform calls behind explicit Rust adapters, while ClaudeCode mainly reconstructs local Rust state without the same external-call boundary.

guided refinement is the step that turns it into an executable migration result. The semantic validator accounts for most of the behavioral improvement. Removing semantic validation still produced compilable crates for all seven subjects, but the aggregate test pass rate dropped from 91.90% to 28.10%. Figure 9 shows the mechanism on paho.mqtt.cpp. The no-semantic variant

Fig. 9. Semantic-validation example from the RQ3 ablation. Without semantic validation, token completion in paho.mqtt.cpp records completion and wakes waiters but omits callback invocation and client-side token cleanup. Full Req2Rust restores these source-observable completion effects.

records token completion and wakes waiters, but it omits callback invocation and removal of the completed token from the client. The full configuration preserves these cross-file token-completion behaviors. Unsafe reduction affects a different dimension. Removing the unsafe-reduction validator preserved the same 91.90% test pass rate, but increased the unsafe rate from 1.7757% to 4.9950%. Figure 10 illustrates the difference on uriparser. Before unsafe reduction, parser code constructs text ranges through direct pointer arithmetic. The full configuration routes the same range construction through a safe helper over input indices, reducing local unsafe usage while keeping the parsed representation unchanged. Overall, the ablation results show that Req2Rust’s gains come from complementary components. Semantic validation drives behavior preservation beyond compilability, while unsafe reduction improves the safety profile without reducing the observed test pass rate. The full harness combines these effects into buildable Rust crates with high test pass rates and lower unsafe usage. V. T HREATS TO VALIDITY Behavioral Oracle: Our tests and probes are derived from available project tests, source evidence, and Openharmony gtest cases, but they do not prove full semantic equivalence. They mainly exercise public APIs and selected state, error, callback, and boundary behaviors. Untested paths, rare inputs,

No unsafe reduction

Full Req2Rust

Some(b’:’) => { let first = unsafe { self.input.as_ptr().add(start) }; let after_last = unsafe { self.input.as_ptr().add(self.pos) }; self.advance(); return Ok(Some(TextRange { first, after_last })); } // issue: reducible unsafe pointer arithmetic Some(b’:’) => { let tr = TextRange::from_indices( self.input, start, self.pos, ); self.advance(); return Ok(Some(tr)); } // reduced: safe helper over input indices

Fig. 10. Unsafe-reduction example from the RQ3 ablation. Without the unsafe-reduction validator, uriparser range construction uses direct pointer arithmetic. Full Req2Rust routes the same range construction through a safe helper over input indices while preserving the parsed representation.

timing-sensitive behavior, and cross-module interactions may still be missed. Benchmark Coverage: Our benchmark covers multiple C++ feature categories, project sizes, general projects, and Openharmony modules. Generalization may vary for projects with unusual build systems, stronger platform coupling, larger template-heavy surfaces, or rare language features not represented by our subjects. We report project characteristics and feature coverage to make the evaluation scope explicit. Agent Variability: Both Req2Rust and the ClaudeCode baseline use DeepSeek-V4-Pro, but agentic translation remains sensitive to model behavior, prompt wording, tool traces, and run-time decisions. A different model, ClaudeCode version, or sampling configuration may change absolute results. VI. R ELATED W ORK

or dependency-preserving decompositions; target-side reconstruction beyond source-aligned translation remains less central. B. C++-to-Rust Translation C++-to-Rust translation is less mature than C-to-Rust migration because many C++ obligations are difficult to extract directly from source structure. Classes, overloads, templates, RAII and destructor protocols, callbacks, and resource ownership patterns can define behavior across files and API boundaries. Cpp2Rust demonstrates automatic translation from a supported C++ subset to safe Rust [6]. LLM/RAG-based work retrieves documentation and examples for unit- or fragmentlevel C++-to-Rust translation [15], and empirical work identifies C++-specific LLM failures caused by language features and source-target semantic gaps [12]. These studies establish feasibility, but feature support alone does not define project-level migration. Realistic C++ projects distribute behavior across class invariants, lifetime protocols, template utilities, callbacks, resources, and build-dependent dependencies. The task is therefore to recover which cross-file behaviors and project assumptions should survive Rust reconstruction. More broadly, LLM-based code translation reports recurring semantic bugs, type mismatches, API mismatches, and source-target semantic gaps [13], [14], [17]. C. Agentic Refinement and Validation Feedback Agentic coding systems treat code as an executable state that can be inspected, modified, and rechecked [19]. Migration systems improve generated Rust through compilation feedback, tests, FFI validation, static analysis, or equivalence checks [29]–[31], [36], [37]. Such feedback exposes many errors only after the generated project is built or exercised. Validation and refinement complement both sourcepreserving and LLM-based translation: build feedback exposes missing items and type mismatches, tests expose behavioral failures, FFI checks compare source and translated behavior, and static or verification feedback can reduce unsafe usage or check equivalence. However, repair remains bounded by its evidence; untested or implicit source obligations may stay invisible even when the generated project is executable.

A. Source-Preserving Migration to Rust Automated migration to Rust often begins from a sourcepreserving representation. C2Rust provides a practical C-toRust source-to-source baseline [8], and later work improves translated programs through unsafe reduction, ownership inference, aliasing analysis, type migration, output-parameter rewriting, union translation, and I/O API migration [7], [9]– [11], [21]–[25]. Preserving declarations, control flow, and lowlevel operations keeps source behavior traceable while later analyses recover more Rust-oriented types and APIs. Recent systems add LLMs, static analysis, dependency recovery, FFI validation, historical retrieval, and compilerfeedback repair to source- or skeleton-preserving migration [16], [26]–[35]. They improve scale and build recovery, but remain tied to source structure, generated skeletons,

VII. C ONCLUSION This paper presents Req2Rust, a project-level LLM-based C++-to-Rust migration harness that records preservation obligations in an MRS, synthesizes an RDS to guide Rust reconstruction, and then refines the initial Rust project through compiler, semantic, and unsafe-reduction validators. Our evaluation on general C++ projects and Openharmony modules shows that Req2Rust produces buildable Rust crates in both settings and improves test pass rate from 69.5% to 91.9% on general projects and from 45.4% to 87.9% on Openharmony modules. The ablation study further shows that semantic validation drives most of the behavioral gain, while unsafe reduction lowers unsafe usage without reducing the observed test pass rate.

DATA AVAILABILITY S TATEMENT The raw data, test code, and harness source code used in this study are available at: https://anonymous.4open.science/r/ Req2Rust-8FB1. R EFERENCES [1] National Security Agency and Cybersecurity and Infrastructure Security Agency, “Memory safe languages: Reducing vulnerabilities in modern software development,” National Security Agency and Cybersecurity and Infrastructure Security Agency, Tech. Rep., Jun. 2025, cybersecurity Information Sheet. [Online]. Available: https: //media.defense.gov/2025/Jun/23/2003742198/-1/-1/0/CSI MEMORY SAFE LANGUAGES REDUCING VULNERABILITIES IN MODERN SOFTWARE DEVELOPMENT.PDF [2] National Security Agency, “Software memory safety,” National Security Agency, Tech. Rep., Nov. 2022, cybersecurity Information Sheet, version 1.1 updated April 2023. [Online]. Available: https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/1/ CSI SOFTWARE MEMORY SAFETY.PDF [3] Cybersecurity and Infrastructure Security Agency, “The urgent need for memory safety in software products,” https://www.cisa.gov/news-events/ news/urgent-need-memory-safety-software-products, Sep. 2023, revised December 6, 2023. [4] R. Jung, J.-H. Jourdan, R. Krebbers, and D. Dreyer, “Safe systems programming in rust,” Commun. ACM, vol. 64, no. 4, p. 144–152, Mar. 2021. [Online]. Available: https://doi.org/10.1145/3418295 [5] ——, “Rustbelt: securing the foundations of the rust programming language,” Proc. ACM Program. Lang., vol. 2, no. POPL, Dec. 2017. [Online]. Available: https://doi.org/10.1145/3158154 [6] L. Popescu, F. Gouveia, H. Preto, J. Silveira, D. Hrybenko, J. F. Santos, and N. P. Lopes, “Cpp2rust: Automatic translation of c++ to safe rust,” Proceedings of the ACM on Programming Languages, vol. 10, no. PLDI, pp. 480–504, 2026. [Online]. Available: https://doi.org/10.1145/3808266 [7] M. Emre, R. Schroeder, K. Dewey, and B. Hardekopf, “Translating c to safer rust,” Proc. ACM Program. Lang., vol. 5, no. OOPSLA, Oct. 2021. [Online]. Available: https://doi.org/10.1145/3485498 [8] Galois, Inc., “C2rust,” https://galois.com/blog/2018/08/c2rust/, August 2018, accessed: 2026-01-27. [9] H. Zhang, C. David, Y. Yu, and M. Wang, “Ownership guided c to rust translation,” in Computer Aided Verification: 35th International Conference, CAV 2023, Paris, France, July 17–22, 2023, Proceedings, Part III. Berlin, Heidelberg: Springer-Verlag, 2023, p. 459–482. [Online]. Available: https://doi.org/10.1007/978-3-031-37709-9 22 [10] M. Emre, P. Boyland, A. Parekh, R. Schroeder, K. Dewey, and B. Hardekopf, “Aliasing limits on translating c to safe rust,” Proceedings of the ACM on Programming Languages, vol. 7, no. OOPSLA1, pp. 551–579, 2023. [11] J. Hong and S. Ryu, “Don’t write, but return: Replacing output parameters with algebraic data types in c-to-rust translation,” Proceedings of the ACM on Programming Languages, vol. 8, no. PLDI, pp. 716–740, 2024. [12] Y. Yan, Y. Feng, Q. He, J. Zeng, and B. Xu, “Challenges in c++ to rust translation with large language models: A preliminary empirical study,” in Proceedings of the 1st ACM SIGPLAN International Workshop on Large Language Models and Programming Languages, 2025. [Online]. Available: https://doi.org/10.1145/3759425.3763380 [13] Z. Yang, F. Liu, Z. Yu, J. W. Keung, J. Li, S. Liu, Y. Hong, X. Ma, Z. Jin, and G. Li, “Exploring and unleashing the power of large language models in automated code translation,” Proceedings of the ACM on Software Engineering, vol. 1, no. FSE, pp. 1585–1608, 2024. [14] H. F. Eniser, H. Zhang, C. David, M. Wang, M. Christakis, B. Paulsen, J. Dodds, and D. Kroening, “Towards translating real-world code with llms: A study of translating to rust,” 2025. [Online]. Available: https://arxiv.org/abs/2405.11514 [15] A. Okutan, S. Merten, C. C. Michael, and B. Ryjikov, “Leveraging rag-llm to translate c++ to rust,” in 2024 International Conference on Assured Autonomy (ICAA), 2024, pp. 102–105. [16] S. Wang, M. Liu, G. Ou, Y. Chen, Z. Li, Y. Wang, and Z. Zheng, “His2Trans: A skeleton first framework for self evolving c to rust translation with historical retrieval,” 2026. [Online]. Available: https://arxiv.org/abs/2603.02617

[17] R. Pan, A. R. Ibrahimzada, R. Krishna, D. Sankar, L. P. Wassi, M. Merler, B. Sobolev, R. Pavuluri, S. Sinha, and R. Jabbarvand, “Lost in translation: A study of bugs introduced by large language models while translating code,” in Proceedings of the IEEE/ACM 46th International Conference on Software Engineering, 2024, pp. 995–1007. [Online]. Available: https://doi.org/10.1145/3597503.3639226 [18] Anthropic, “Claude code,” 2026, accessed: 2026-06-28. [Online]. Available: https://www.anthropic.com/product/claude-code [19] X. Ning, K. Tieu, D. Fu, T. Wei, Z. Li, Y. Bei et al., “Code as agent harness: Toward executable, verifiable, and stateful agent systems,” 2026. [Online]. Available: https://arxiv.org/abs/2605.18747 [20] OpenAtom Foundation, “OpenHarmony: A distributed operating system for all scenarios,” https://gitee.com/openharmony. [21] M. Ling, Y. Yu, H. Wu, Y. Wang, J. R. Cordy, and A. E. Hassan, “In rust we trust: a transpiler from unsafe c to safer rust,” in Proceedings of the ACM/IEEE 44th international conference on software engineering: companion proceedings, 2022, pp. 354–355. [22] J. Hong and S. Ryu, “Type-migrating c-to-rust translation using a large language model,” Empirical Software Engineering, vol. 30, 10 2024. [23] ——, “To tag, or not to tag: Translating c’s unions to rust’s tagged unions,” in Proceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering, 2024, pp. 40–52. [24] ——, “Forcrat: Automatic i/o api translation from c to rust via origin and capability analysis,” arXiv preprint arXiv:2506.01427, 2025. [25] Q. Xu and J. Huang, “Optimizing type migration for llm-based c-torust translation: A data flow graph approach,” in Proceedings of the 14th ACM SIGPLAN International Workshop on the State Of the Art in Program Analysis, 2025, pp. 8–14. [26] R. Zhang, S. Zhang, and L. Xie, “A systematic exploration of c-to-rust code translation based on large language models: prompt strategies and automated repair,” Automated Software Engineering, vol. 33, 10 2025. [27] V. Nitin, R. Krishna, L. L. do Valle, and B. Ray, “C2saferrust: Transforming c projects into safer rust with neurosymbolic techniques,” 2025. [Online]. Available: https://arxiv.org/abs/2501.14257 [28] F. Luo, K. Ji, C. Gao, S. Gao, J. Feng, K. Liu, X. Xia, and M. R. Lyu, “Integrating rules and semantics for llm-based c-to-rust translation,” 2025. [Online]. Available: https://arxiv.org/abs/2508.06926 [29] M. Farrukh, S. Shah, B. Coskun, and M. Polychronakis, “Safetrans: Llm-assisted transpilation from c to rust,” 2025. [Online]. Available: https://arxiv.org/abs/2505.10708 [30] H. Zhou, Y. Luo, M. Zhang, and D. Xu, “C2rusttv: An llm-based framework for c to rust translation and validation,” in 2025 IEEE 49th Annual Computers, Software, and Applications Conference (COMPSAC), 2025, pp. 1254–1259. [31] T. Zhou, Z. Zhang, H. Lin, S. Jha, M. Christodorescu, K. Levchenko, and V. Chandrasekaran, “Sactor: Llm-driven correct and idiomatic c to rust translation with static analysis and ffi-based verification,” 2025. [Online]. Available: https://arxiv.org/abs/2503.12511 [32] X. Cai, J. Liu, X. Huang, Y. Yu, H. Wu, C. Li, B. Wang, I. N. B. Yusuf, and L. Jiang, “Rustmap: Towards project-scale c-to-rust migration via program analysis and llm,” in Engineering of Complex Computer Systems: 29th International Conference, ICECCS 2025, Hangzhou, China, July 2–4, 2025, Proceedings. Berlin, Heidelberg: Springer-Verlag, 2025, p. 283–302. [Online]. Available: https://doi.org/10.1007/978-3-032-00828-2 16 [33] C. Wang, T. Yu, B. Shen, J. Wang, D. Chen, W. Zhang, Y. Shi, C. Xie, and X. Gu, “Evoc2rust: A skeleton-guided framework for project-level c-to-rust translation,” 2026. [Online]. Available: https://arxiv.org/abs/2508.04295 [34] Z. Yuan, W. Mao, Z. Chen, X. Shang, C. Wang, Y. Lou, and X. Peng, “Project-level c-to-rust translation via synergistic integration of knowledge graphs and large language models,” 2025. [Online]. Available: https://arxiv.org/abs/2510.10956 [35] S. Dehghan, T. Sun, T. Wu, Z. Li, and R. Jabbarvand, “Translating large-scale c repositories to idiomatic rust,” 2025. [Online]. Available: https://arxiv.org/abs/2511.20617 [36] M. Shiraishi, Y. Cao, and T. Shinagawa, “Smartc2rust: Iterative, feedback-driven c-to-rust translation via large language models for safety and equivalence,” 2025. [Online]. Available: https://arxiv.org/abs/ 2409.10506 [37] A. Z. H. Yang, Y. Takashima, B. Paulsen, J. Dodds, and D. Kroening, “Vert: Verified equivalent rust transpilation with large language models as few-shot learners,” 2024. [Online]. Available: https://arxiv.org/abs/2404.18852

Related documents

• Weird Machine Compositors: Exploiting AI Orchestration at the Expression Layer#1118125
• KVerus: Scalable and Resilient Formal Verification Proof Generation for Rust Code#155360
• Fidelity Probes for Specification--Code Alignment#1116286
• Towards a Reliable and Practical Eval Pipeline#820814
• BIG, HOT TO COLD: An Odyssey of Architectural Adaptation#1190643