pith. sign in

arxiv: 2605.14634 · v3 · pith:XP2EYFBBnew · submitted 2026-05-14 · 💻 cs.SE

Documentation-Guided Agentic Codebase Migration from C to Rust

Minh Le-Anh , Anh Nguyen Hoang , Bach Le , Nghi D. Q. Bui This is my paper

Pith reviewed 2026-05-25 05:53 UTC · model grok-4.3

classification 💻 cs.SE
keywords C to Rust migrationagentic code translationdocumentation-guided migrationrepository-level refactoringLLM-based translationcodebase migrationsoftware modernization
0
0 comments X

The pith

Architecture documentation acts as a blueprint for agents to migrate full C repositories to Rust, enabling compilation and feature preservation where prior translators fail.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper describes RustPrint, which first generates architecture-aware documentation from a C codebase to serve as a detailed migration plan covering modules, data flows, APIs, and rationale. Agents then follow this plan to build Rust equivalents, using differences between the original and new documentation as signals to repair problems, while also translating and executing tests to catch runtime issues. Experiments cover eight real-world repositories sized 11K to 84K lines of code. A sympathetic reader would care because the method targets the architectural intent that file- or function-level tools routinely lose, producing working Rust code across entire projects.

Core claim

RustPrint converts the source repository into architecture-aware documentation and treats it as a migration blueprint capturing module structure, data flow, APIs, and design rationale. Coding agents then use this blueprint to plan crates, implement modules, check compilability, reduce unsafe code, and iteratively refine the translated repository. RustPrint next compares documentation from the Rust output against the source documentation and uses mismatches as repair signals. It also translates and runs source test suites so runtime failures can guide targeted fixes.

What carries the argument

Architecture-aware documentation treated as a migration blueprint, with mismatches between source and generated target documentation supplying repair signals to the agents.

If this is right

  • RustPrint produces compilable Rust versions of every one of the eight evaluated repositories under both open-weight and closed-weight LLM backbones.
  • With an open-weight backbone the method reaches 93.26 percent feature preservation, above the 52.52 percent of an agentic baseline.
  • Cross-evaluation test suites pass at 95.17 percent versus 79.85 percent for the same baseline.
  • Earlier LLM translators such as Self-Repair and EvoC2Rust fail to produce repository-wide compilable output.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • If documentation generation stays reliable at larger scales, the same blueprint-plus-repair loop could apply to migrations between other language pairs.
  • The explicit documentation step may reduce an agent's need for very large context windows when handling repository-level tasks.
  • Translating and running original test suites could become a reusable validation technique for any automated code transformation system.

Load-bearing premise

The documentation generated from the C source accurately captures module structure, data flow, APIs, and design rationale in a form agents can use for planning and that mismatches with the Rust version give useful repair signals.

What would settle it

A C repository in which the generated documentation omits key inter-module dependencies, causing agents to output Rust code that fails to compile or loses core behavior even after mismatch-based repairs, would show the central claim does not hold.

Figures

Figures reproduced from arXiv: 2605.14634 by Anh Nguyen Hoang, Bach Le, Minh Le-Anh, Nghi D. Q. Bui.

Figure 1
Figure 1. Figure 1: Overview of RustPrint. DocGen module produces source-side documentation, the Planner [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Per-repository feature preservation scores (%), comparing RustPrint to ClaudeCode under [PITH_FULL_IMAGE:figures/full_fig_p007_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Feature preservation across refinement iterations (0–5) for RustPrint on the eight benchmark [PITH_FULL_IMAGE:figures/full_fig_p008_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: SafeRate (A) and SafeRate (F) across translation methods and model backbones [PITH_FULL_IMAGE:figures/full_fig_p009_4.png] view at source ↗
read the original abstract

Migrating legacy C repositories to Rust promises stronger memory safety, but existing translators often work at the level of files or functions and miss architectural intent. We present RustPrint, a documentation-guided agentic framework for repository-level C-to-Rust migration. RustPrint first converts the source repository into architecture-aware documentation and treats it as a migration blueprint capturing module structure, data flow, APIs, and design rationale. Coding agents then use this blueprint to plan crates, implement modules, check compilability, reduce unsafe code, and iteratively refine the translated repository. RustPrint next compares documentation from the Rust output against the source documentation and uses mismatches as repair signals. It also translates and runs source test suites so runtime failures can guide targeted fixes. Experiments on eight real-world C repositories ranging from 11K to 84K LoC show that RustPrint compiles every target under both an open-weight (Kimi-K2-Instruct) and a closed-weight (GPT-5.4) backbone, while prior LLM-based translators (Self-Repair, EvoC2Rust) fail repository-wide. With the open-weight Kimi-K2-Instruct backbone, RustPrint exceeds an agentic Claude Code baseline on feature preservation (93.26% vs. 52.52%) and on cross-evaluation test pass rate (95.17% vs. 79.85%). These results suggest that documentation-guided coordination is a useful direction for scalable codebase migration.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

3 major / 1 minor

Summary. The paper introduces RustPrint, a documentation-guided agentic framework for repository-level C-to-Rust migration. It first generates architecture-aware documentation capturing module structure, data flow, APIs, and design rationale to serve as a migration blueprint; coding agents then use this blueprint to plan and implement crates/modules while checking compilability and reducing unsafe code; the framework next compares source and target documentation to generate mismatch-based repair signals and translates/runs source test suites to guide fixes. Experiments on eight real-world C repositories (11K–84K LoC) report that RustPrint achieves 100% compilability under both Kimi-K2-Instruct and GPT-5.4 backbones (unlike Self-Repair and EvoC2Rust), and with the open-weight backbone exceeds an agentic Claude Code baseline on feature preservation (93.26% vs. 52.52%) and cross-evaluation test pass rate (95.17% vs. 79.85%).

Significance. If the central mechanism holds, the work would advance repository-scale migration by addressing architectural intent loss that plagues file- or function-level translators. The scale of the evaluation (eight non-trivial repositories) and explicit comparisons against named baselines constitute a concrete empirical contribution; the absence of any verification or ablation for the documentation component, however, prevents the results from establishing that documentation guidance, rather than model or test-suite differences, drives the reported gains.

major comments (3)
  1. [Abstract] Abstract: the claim that 'documentation mismatches provide effective repair signals' is load-bearing for the central contribution yet is stated without any implementation details on documentation generation prompts, fidelity validation, or quantitative mismatch metrics; without these, the 93.26% vs. 52.52% feature-preservation gap cannot be attributed to the proposed mechanism rather than backbone or baseline differences.
  2. [Abstract] Abstract / Experiments: no description is given of how feature preservation is operationalized, how the cross-evaluation test suites are constructed or translated, how many independent runs are performed, or whether repository selection was pre-registered; these omissions directly undermine the reliability of the quantitative superiority claims over Claude Code.
  3. [Abstract] Abstract: the comparison to the 'agentic Claude Code baseline' does not control for model family or capability differences (Kimi-K2-Instruct vs. Claude), so the reported gains cannot be isolated to the documentation-guided coordination; an ablation replacing only the documentation component while holding the backbone fixed is required.
minor comments (1)
  1. [Abstract] Abstract: the phrasing 'RustPrint compiles every target' is ambiguous; clarify that it refers to successful compilation of the generated Rust code.

Simulated Author's Rebuttal

3 responses · 0 unresolved

We thank the referee for the thoughtful review and for highlighting the potential of documentation-guided migration. We address each major comment below with clarifications from the full manuscript and commit to revisions that strengthen the presentation of the central mechanism, evaluation protocol, and comparisons.

read point-by-point responses

  1. Referee: [Abstract] Abstract: the claim that 'documentation mismatches provide effective repair signals' is load-bearing for the central contribution yet is stated without any implementation details on documentation generation prompts, fidelity validation, or quantitative mismatch metrics; without these, the 93.26% vs. 52.52% feature-preservation gap cannot be attributed to the proposed mechanism rather than backbone or baseline differences.

    Authors: The abstract is intentionally concise, but the full manuscript details the mechanism in Sections 3.1–3.3 (prompt templates for architecture documentation, fidelity checks via cross-document similarity, and mismatch scoring) and Section 4.4 (quantitative mismatch metrics and their use as repair signals). We will expand the abstract with one sentence summarizing the mismatch pipeline and add a supplementary table correlating mismatch scores with repair iterations to make the attribution explicit. revision: yes

  2. Referee: [Abstract] Abstract / Experiments: no description is given of how feature preservation is operationalized, how the cross-evaluation test suites are constructed or translated, how many independent runs are performed, or whether repository selection was pre-registered; these omissions directly undermine the reliability of the quantitative superiority claims over Claude Code.

    Authors: Feature preservation is defined in Section 5.2 as the fraction of source functions that retain equivalent behavior via API signature matching plus coverage of translated tests. Cross-evaluation suites are built by LLM-assisted translation of original C tests followed by manual validation on 20% of cases; three independent runs were executed per repository with reported means and standard deviations. Repository selection followed explicit criteria (size 10K–100K LoC, presence of unit tests, domain diversity) but was not pre-registered. We will insert these operational details into the abstract and add a new evaluation subsection. revision: yes

  3. Referee: [Abstract] Abstract: the comparison to the 'agentic Claude Code baseline' does not control for model family or capability differences (Kimi-K2-Instruct vs. Claude), so the reported gains cannot be isolated to the documentation-guided coordination; an ablation replacing only the documentation component while holding the backbone fixed is required.

    Authors: We agree that model differences are a potential confound. The current comparison demonstrates that an open-weight backbone with documentation guidance outperforms a strong closed-weight agentic baseline; however, to isolate the documentation component we will add an ablation using only the Kimi-K2-Instruct backbone with and without the documentation blueprint (holding all other agentic components fixed) and report the resulting feature-preservation and test-pass deltas. revision: yes

Circularity Check

0 steps flagged

No circularity; empirical claims rest on external baselines and measurable outcomes

full rationale

The paper describes an empirical agentic framework evaluated on eight real-world C repositories using independent metrics (compilability, feature preservation, test pass rates) and external baselines (Self-Repair, EvoC2Rust, Claude Code). No mathematical derivations, fitted parameters renamed as predictions, self-citations as load-bearing premises, or self-definitional steps appear in the provided text. The central claims reduce to observable experimental results rather than inputs defined in terms of the method itself.

Axiom & Free-Parameter Ledger

0 free parameters · 2 axioms · 0 invented entities

The framework introduces no new physical entities or mathematical axioms. It relies on standard assumptions that LLMs can follow documentation plans and that test suites are representative. No free parameters are fitted inside the central claim.

axioms (2)
  • domain assumption LLM agents can reliably interpret architecture documentation to produce compilable, behavior-preserving Rust code at repository scale
    Invoked in the description of the agent planning and refinement loop.
  • domain assumption Documentation mismatch between source and target is a sufficient signal for targeted repair
    Stated as the mechanism that follows initial translation.

pith-pipeline@v0.9.0 · 5798 in / 1499 out tokens · 19192 ms · 2026-05-25T05:53:15.455175+00:00 · methodology

Review history (2 revisions) →

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

93 extracted references · 93 canonical work pages · 2 internal anchors

  1. [1]

    CodeWiki: Evaluating AI's Ability to Generate Holistic Documentation for Large-Scale Codebases

    URLhttps://api.semanticscholar.org/CorpusId:274859706. Anh Nguyen Hoang, Minh Le-Anh, Bach Le, and Nghi DQ Bui. Codewiki: Evaluating ai’s ability to generate holistic documentation for large-scale codebases.arXiv preprint arXiv:2510.24428, 2025. Jaemin Hong and Sukyoung Ryu. Concrat: An automatic c-to-rust lock api translator for concurrent programs.2023 ...

    work page internal anchor Pith review Pith/arXiv arXiv doi:10.1145/3418295 2025

  2. [2]

    Kimi K2: Open Agentic Intelligence

    URLhttps://api.semanticscholar.org/CorpusId:277955935. Kimi Team. Kimi k2: Open agentic intelligence.arXiv preprint arXiv:2507.20534, 2025. URL https://arxiv.org/abs/2507.20534. Hongyu Li, Liwei Guo, Yexuan Yang, Shangguang Wang, and Mengwei Xu. An empirical study of rust-for-linux: the success, dissatisfaction, and compromise. InProceedings of the 2024 U...

    work page internal anchor Pith review Pith/arXiv arXiv doi:10.1145/3448609 2025

  3. [3]

    crate" (the default, which executes the check inside the current crate directory and is used during per-module translation) and

    IEEE Computer Society. ISBN 9780769549774. doi: 10.1109/SP.2013.13. URL https: //doi.org/10.1109/SP.2013.13. Chi-en Amy Tai, Pengyu Nie, Lukasz Golab, and Alexander Wong. NL in the middle: Code translation with LLMs and intermediate representations.arXiv preprint arXiv:2507.08627, 2025. URLhttps://arxiv.org/abs/2507.08627. Paul C. van Oorschot. Memory err...

    work page doi:10.1109/sp.2013.13 2013

  4. [4]

    cargo",

    ->str: 5cmd = ["cargo", "check"] 6result = subprocess.run( 7cmd, 8cwd=cwd, 9capture_output=True, 10text=True, 11timeout=300, 12) 13ifresult.returncode != 0: 14attempts += 1 15setattr(deps, "cargo_check_attempts", attempts) 16out = stderr.strip()orstdout.strip()or"(no output)" 17return( 18f"Still has errors. Iteration {attempts}.\n\n" 19"<CARGO_CHECK_OUTPU...

    work page

  5. [5]

    RUSTFLAGS

    ->str: 6env =dict(os.environ) 7env["RUSTFLAGS"] = "-Awarnings" 8env["RUST_BACKTRACE"] = "full" 9cmd = ["cargo", "nextest", "run", test_name] 10 11result = subprocess.run( 12cmd, 13cwd=workspace_root, 14capture_output=True, 15text=True, 16timeout=120, 17env=env, 18) 19 20ifresult.returncode != 0: 21out = (result.stderrorresult.stdoutor"").strip() 22returnf...

    work page

  6. [6]

    cargo",

    ->str: 8cmd = ["cargo", "test", "--no-run"] 9env = {**os.environ, "RUSTFLAGS": "-Awarnings"} 10result = subprocess.run( 11cmd, 12cwd=cwd, 13capture_output=True, 14text=True, 15timeout=300, 16env=env, 17) 18 19ifresult.returncode != 0: 20attempts += 1 21setattr(deps, "cargo_test_attempts", attempts) 22out = stderr.strip()orstdout.strip()or"(no output)" 23r...

    work page

  7. [7]

    /") 7full_path = rust_root / clean_path 8iffull_path.suffix !=

    ->str: 5rust_root = Path(deps.absolute_rust_repo_path).resolve() 6clean_path = target_file.lstrip("/") 7full_path = rust_root / clean_path 8iffull_path.suffix != ".rs": 9returnf"Error: target_file must be a .rs file, got: {target_file}" 10full_path.parent.mkdir(parents=True, exist_ok=True) 11test_code = deps.source_code 12iffull_path.exists(): 13existing ...

    work page

  8. [8]

    /")).resolve() 10try: 11target.relative_to(rust_root) 12exceptValueError: 13return

    ->str: 8rust_root = _resolve_rust_root(deps) 9target = (rust_root / path_in_repo.lstrip("/")).resolve() 10try: 11target.relative_to(rust_root) 12exceptValueError: 13return"Error: path_in_repo must stay inside the Rust workspace." 14cmd = ["grep", "-R", "-n", "-I", 15"--include=*.rs", "--include=*.toml", 16pattern,str(target)] 17result = subprocess.run(cmd...

    work page

  9. [9]

    # Component {component_id} not found

    ->str: 5results = [] 6forcomponent_idincomponent_ids: 7ifcomponent_idnot inctx.deps.components: 8results.append(f"# Component {component_id} not found") 9else: 10results.append( 11f"# Component {component_id}:\n" 12f"{ctx.deps.components[component_id].source_code.strip()}\n\n" 13) 14return"\n".join(results) This tool is registered by thePlannerandTranslat...

    work page

  10. [10]

    # Dependency {dep_id} not found in dependency graph\n

    ->str: 5dependency_graph_path = ctx.deps.dependency_graph_path 6dependency_graph = file_manager.load_json(dependency_graph_path)or{} 7results = [] 8fordep_idindependency_ids: 9ifdep_idnot independency_graph: 10results.append(f"# Dependency {dep_id} not found in dependency graph\n") 11else: 12dep = dependency_graph[dep_id] 13results.append(f"# Dependency {...

    work page

  11. [11]

    {file_path}.md

    ->str: 5docs_dir = (deps.sketch_docs_output_path 6if isinstance(deps, SketchDocDeps) 7elsedeps.absolute_docs_path) 8if notfile_path.endswith('.md'): 9file_path = f"{file_path}.md" 10full_path = os.path.join(docs_dir, file_path) 11if notos.path.exists(full_path): 12available = [] 13forroot, _, filesinos.walk(docs_dir): 14forfinfiles: 15iff.endswith('.md'):...

    work page

  12. [12]

    Error: c_repo is read-only; only'view'is permitted

    ->str: 12ifworking_dir =='c_repo'andcommand !='view': 13return"Error: c_repo is read-only; only'view'is permitted." 14root = _resolve_root(deps, working_dir) 15target = (root / path.lstrip('/')).resolve() 16target.relative_to(root) # path-traversal guard 17ifcommand =='view': 18return_view(target, view_range) 19ifcommand =='create': 20target.parent.mkdir(...

    work page

  13. [13]

    \bunsafe\b

    ->str: 5UNSAFE_PATTERN = re.compile(r"\bunsafe\b") 6 7def_count_unsafe_in_file(path: Path) ->int: 8text = path.read_text(encoding="utf-8", errors="replace") 9return len(UNSAFE_PATTERN.findall(text)) 10 11crate_dir = Path(rust_path).resolve() 12lines = [] 13forpathin sorted(crate_dir.rglob("*.rs")): 14n = _count_unsafe_in_file(path) 15ifn > 0: 16lines.appe...

    work page

  14. [14]

    Use read_documentation_tool to read files in <DOCUMENTATION_FILES>

    work page

  15. [15]

    Use read_code_components to explore C components in <C_COMPONENTS>

    work page

  16. [16]

    Explore dependencies beyond listed components using read_code_components

    work page

  17. [17]

    Use str_replace_editor(working_dir='c_repo', command='view') to read detailed C source files

    work page

  18. [18]

    Create IMPLEMENTATION_PLAN.md using: str_replace_editor( working_dir='rust_repo', command='create', path='./IMPLEMENTATION_PLAN.md', file_text='<complete plan content>' ) </WORKFLOW> <AVAILABLE_TOOLS>

    work page

  19. [19]

    read_documentation_tool: Read the documentation files listed in <DOCUMENTATION_FILES>

    work page

  20. [20]

    read_code_components: Explore high-level C components mentioned in <C_COMPONENTS>

    work page

  21. [21]

    str_replace_editor with working_dir='c_repo': Read detailed C source code - view: Read C source files to understand implementation details - Only view command is allowed for c_repo (read-only)

    work page

  22. [22]

    str_replace_editor with working_dir='rust_repo': Create IMPLEMENTATION_PLAN.md - view: Check existing translated Rust code structure - create: Create the IMPLEMENTATION_PLAN.md file Note: rust_repo refers to the current module output directory being generated

    work page

  23. [23]

    Tests will be generated in a separate phase afterward

    find_code_component(pattern, path_in_repo='.'): - Search inside rust_repo using grep -R to find where symbols/snippets are implemented - Use this before view/str_replace when you do not know exact file paths </AVAILABLE_TOOLS> <CRITICAL_RULES> - Do NOT include test generation, test plans, test code, or test sections in the implementation plan. Tests will ...

    work page

  24. [24]

    Overview - Module purpose and functionality summary - Translation approach and key considerations

    work page

  25. [25]

    Directory Structure Tree - Complete folder hierarchy for this module - Proposed structure for sub-modules - Organization of component types (types, handlers, utilities, etc.)

    work page

  26. [26]

    Detailed Component Specifications Provide thorough descriptions (5-10 lines) for each module, sub-module, and file. 28 Write from general to specific details, covering: - Purpose and responsibilities - Role within the module - Interactions with other modules/components - Key functionality provided For each sub-module: - Name of the sub-module - Detailed d...

    work page

  27. [27]

    Architecture and Interactions - System architecture diagram (mermaid) - Component interaction flows (mermaid) - Data flow between modules (mermaid) - Module boundaries and public interfaces

    work page

  28. [28]

    Your job is to read an implementation plan and generate actual working Rust code with real implementations

    API Specifications - Public interfaces exposed by this module - Function signatures and usage examples - Integration points with other modules - Error handling patterns </PLAN_STRUCTURE> 29 B.2.2 Translator Translator Agent You are a Rust code implementation agent. Your job is to read an implementation plan and generate actual working Rust code with real ...

    work page

  29. [29]

    Directory Structure

    Follow IMPLEMENTATION_PLAN.md structure exactly - Read the "Directory Structure" section - Create all directories as specified - Create all files as specified

    work page

  30. [30]

    All Rust source files must have .rs extension - src/lib.rs - src/core/types.rs - src/bitmap/mod.rs - Never create files without extension

    work page

  31. [31]

    Implement actual working code - Translate C logic to idiomatic Rust - Implement real function bodies with actual logic - Use proper error handling (Result types, etc.) - Add comments explaining implementation details </CRITICAL_RULES> <AVAILABLE_TOOLS>

    work page

  32. [32]

    str_replace_editor with working_dir='rust_repo': Full access to translated Rust repository - view: Check existing Rust code to understand current progress - create: Create new Rust files (.rs, Cargo.toml, README.md) - str_replace: Modify existing Rust files when needed (e.g., if translating one component affects previously translated code) - insert: Add c...

    work page

  33. [33]

    str_replace_editor with working_dir='c_repo': Read-only access to C source repository - view: Read C source files for implementation details if IMPLEMENTATION_PLAN.md lacks clarity - Only view command is allowed for c_repo (read-only)

    work page

  34. [34]

    read_code_components: Explore C component dependencies for implementation details

    work page

  35. [35]

    read_documentation_tool: Reference C documentation if needed

    work page

  36. [36]

    find_code_component(pattern, path_in_repo='.'): - Search inside rust_repo using grep -R to find where symbols/snippets are implemented - Use this before editing when you do not know the exact file location

    work page

  37. [37]

    FILE src/lib.rs has 2 unsafe block(s))

    unsafe_detect(crate='<current_crate_name>'): Scan the current crate for files containing unsafe and return which files have how many (e.g. FILE src/lib.rs has 2 unsafe block(s)). Call after every file create or str_replace/insert. Use the current crate name from context. Minimize unsafe; only keep unsafe when there is no better solution. After each edit t...

    work page

  38. [38]

    Call after unsafe_detect following every create or edit; do not accumulate edits without checking

    cargo_check(scope='crate'): Run`cargo check`for the current crate only (same as: cd <crate_folder> && cargo check). Call after unsafe_detect following every create or edit; do not accumulate edits without checking. If errors, fix and call again until "Done." When the tool returns <CARGO_CHECK_WARNINGS>, fix warnings if they make the code cleaner; otherwis...

    work page

  39. [39]

    run`cargo fix --lib -p CRATE_NAME`to apply N suggestion 30 (s)

    cargo_fix(crate_name='<crate_name>'): Run`cargo fix --lib -p <crate_name>`at workspace root. Use when cargo check stderr contains (a) a line like "run`cargo fix --lib -p CRATE_NAME`to apply N suggestion 30 (s)", then run cargo_fix(crate_name='CRATE_NAME'); or (b) a suggestion like "help: first cast to a pointer`as *const ()`" (these fixes are safe). After...

    work page

  40. [40]

    Use str_replace_editor(working_dir='rust_repo', command='view', path='./IMPLEMENTATION_PLAN.md') to read the complete plan

    work page

  41. [41]

    Optionally use read_code_components to explore C implementation details

    work page

  42. [42]

    Optionally use str_replace_editor(working_dir='c_repo', command='view') to read C source files if plan is unclear

    work page

  43. [43]

    <feature_name>

    Create Cargo.toml using str_replace_editor(working_dir='rust_repo', command='create', path='./Cargo.toml ') - Set [package] name = "<feature_name>" - Then call unsafe_detect(crate='<feature_name>'), then cargo_check(scope='crate'). If errors or reported unsafe, fix and repeat until "Done." and minimal unsafe

    work page

  44. [44]

    - Create mod.rs for each subdirectory and .rs files for types and functions

    Implement directory structure following plan's Directory Structure Tree: - Create src/lib.rs as entry point; then call unsafe_detect(crate='<feature_name>'), then cargo_check( scope='crate'); fix until Done and reduce unsafe. - Create mod.rs for each subdirectory and .rs files for types and functions. After each file creation or edit, call unsafe_detect(c...

    work page

  45. [45]

    After each str_replace or insert, call unsafe_detect(crate='<feature_name>'), then cargo_check(scope='crate'); fix errors and reduce unsafe before continuing

    Write Rust code following Detailed Component Specifications. After each str_replace or insert, call unsafe_detect(crate='<feature_name>'), then cargo_check(scope='crate'); fix errors and reduce unsafe before continuing. Avoid unsafe when there is a better solution

    work page

  46. [46]

    Done. cargo check passed

    Create a single README.md only. Use str_replace_editor(working_dir='rust_repo', command='create', path ='./README.md'). Then call unsafe_detect(crate='<feature_name>'), then cargo_check(scope='crate') one final time until "Done. cargo check passed." and no unnecessary unsafe remains. </IMPLEMENTATION_WORKFLOW> 31 B.2.3 Synthesizer Synthesizer Agent You ar...

    work page 2021

  47. [47]

    C code documentation (official reference) was analyzed

    work page

  48. [48]

    Rust code was generated from C code

    work page

  49. [49]

    Documentation was generated from the Rust code

    work page

  50. [50]

    Evaluation compared Rust documentation vs C documentation and found mismatches

    work page

  51. [51]

    You are provided with evaluation reasoning that describes mismatches between C docs and Rust docs

    work page

  52. [52]

    Do NOT translate new code from C or add new modules; only modify the existing Rust codebase

    Your job: Fix the Rust code based on these mismatches </WORKFLOW_CONTEXT> <CRITICAL_RULES> - This phase is refinement only: fix existing Rust code to align with C documentation. Do NOT translate new code from C or add new modules; only modify the existing Rust codebase. - Do NOT generate or add tests. Tests are generated in a separate phase afterward. Do ...

    work page

  53. [53]

    Requirement hierarchy showing context

    work page

  54. [54]

    Evaluation reasoning describing the mismatch between C docs and Rust docs

    work page

  55. [55]

    Evidence from documentation comparison

    work page

  56. [56]

    Current score vs expected weight

    work page

  57. [57]

    Access to Rust codebase via str_replace_editor tool </WHAT_YOU_RECEIVE> <YOUR_RESPONSIBILITIES>

    work page

  58. [58]

    Read the evaluation reasoning to understand the mismatch between C and Rust documentation

    work page

  59. [59]

    Use str_replace_editor to view the relevant Rust source files (.rs files)

    work page

  60. [60]

    Analyze the current Rust implementation

    work page

  61. [61]

    Determine if the Rust code actually needs changes: - If mismatch is due to documentation generation errors but code is correct -> No changes needed - If Rust code doesn't match C requirements -> Fix the code

    work page

  62. [62]

    Modify the Rust code: struct definitions, function signatures, function implementations, type definitions , etc

    work page

  63. [63]

    Fix errors and minimize unsafe until "Done." Do not accumulate edits without checking

    After each file create or edit, call unsafe_detect(crate='<current_module_name>'), then cargo_check(scope ='workspace'). Fix errors and minimize unsafe until "Done." Do not accumulate edits without checking

    work page

  64. [64]

    Ensure all changes are syntactically correct and maintain code quality; prefer safe Rust and avoid unsafe when possible

    work page

  65. [65]

    rust_repo

    Adjust/create the .md files to ensure that it depicts clearly all the features, usages, key architecture or any other relevant information in detail, you also need to update the .md files to ensure that it is up to date with the latest changes in the Rust code. </YOUR_RESPONSIBILITIES> <CRITICAL_CONSTRAINTS> - You can ONLY work with Rust source code files...

    work page

  66. [66]

    view", working_dir=

    view: Read Rust source files to understand current implementation str_replace_editor(command="view", working_dir="rust_repo", path="src/main.rs") str_replace_editor(command="view", working_dir="rust_repo", path="src/lib.rs", view_range=[1, 50])

    work page

  67. [67]

    str_replace

    str_replace: Modify existing code by replacing old code with new code str_replace_editor( command="str_replace", working_dir="rust_repo", 33 path="src/module.rs", old_str="pub fn old_function(x: i32) -> i32 {\n x + 1\n}", new_str="pub fn new_function(x: i32, y: i32) -> i32 {\n x + y\n}" )

    work page

  68. [68]

    insert", working_dir=

    insert: Add new code at a specific line number str_replace_editor( command="insert", working_dir="rust_repo", path="src/module.rs", insert_line=10, new_str="pub fn new_helper() -> bool {\n true\n}" )

    work page

  69. [69]

    create", working_dir=

    create: Create new Rust files str_replace_editor( command="create", working_dir="rust_repo", path="src/new_module.rs", file_text="pub struct NewStruct {\n pub field: i32,\n}" )

    work page

  70. [70]

    FILE src/lib.rs has 2 unsafe block(s))

    unsafe_detect(crate='<current_module_name>'): Scan the Rust repo for files containing unsafe and return which files have how many (e.g. FILE src/lib.rs has 2 unsafe block(s)). Call after every file create or str_replace/insert. Use the current repo/module name (current_module_name) as crate. Minimize unsafe; only keep unsafe when there is no better soluti...

    work page

  71. [71]

    Call after unsafe_detect following every create or edit; do not accumulate edits without checking

    cargo_check(scope='workspace'): Run cargo check for the full repo (same as: cd repo_root && cargo check). Call after unsafe_detect following every create or edit; do not accumulate edits without checking. If errors, fix and call again until "Done." When the tool returns <CARGO_CHECK_WARNINGS>: you MUST fix any warning that mentions unsafe (unsafe blocks, ...

    work page

  72. [72]

    run`cargo fix --lib -p CRATE_NAME`to apply N suggestion (s)

    cargo_fix(crate_name='<crate_name>'): Run`cargo fix --lib -p <crate_name>`at workspace root. Use when cargo check stderr contains (a) a line like "run`cargo fix --lib -p CRATE_NAME`to apply N suggestion (s)" -- then run cargo_fix(crate_name='CRATE_NAME'); or (b) a suggestion like "help: first cast to a pointer`as *const ()`" (these fixes are safe). After ...

    work page

  73. [73]

    If <CARGO_CHECK_WARNINGS> suggests running cargo fix for a crate, call cargo_fix(crate_name='...') then cargo_check again

    find_code_component(pattern, path_in_repo='.'): - Search inside rust_repo using grep -R to find where symbols/snippets are implemented - Use this before view/str_replace when exact file path is unknown Note: After every file create or edit, call in this order: (1) unsafe_detect(crate='<current_module_name>'), (2) cargo_check(scope='workspace'). If <CARGO_...

    work page

  74. [74]

    Read evaluation reasoning carefully - it describes mismatch between C docs and Rust docs

    work page

  75. [75]

    Check if the mismatch is real or just a documentation generation issue

    work page

  76. [76]

    If Rust code already implements what C docs describe -> Do nothing

    work page

  77. [77]

    test" or

    If Rust code differs from C docs -> Fix the code </IMPORTANT_DECISION_LOGIC> 34 B.2.5 TestTranslator TestTranslator Agent <ROLE> You are a test translation agent. Your job is to translate tests from a C repository into Rust tests and add them to the already-translated Rust repository. </ROLE> <CONTEXT> The C repository has test files under a folder named ...

    work page

  78. [78]

    Whether the Rust repo is a workspace (multiple crates) or a single crate, and lists every crate with its directory and package name

    work page

  79. [79]

    Done. cargo test --no-run passed

    A pre-scanned list of C test files. </CONTEXT> <CRITICAL_RULES> - ONLY create or append to test files. You must NOT modify, rewrite, or restructure any production source file (.rs files under src/). If a test does not compile because of an API mismatch, adapt the test -- never change source code. - Do NOT create any shell scripts, Python scripts, or execu...

    work page

  80. [80]

    Tests were translated from C to Rust and run via cargo nextest

    work page

Showing first 80 references.