pith. sign in

arxiv: 2605.14634 · v2 · 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-20 21:14 UTC · model grok-4.3

classification 💻 cs.SE
keywords C to Rust migrationagentic code generationdocumentation-guided translationrepository-level migrationLLM-based code translationlegacy codebase modernizationRust memory safety
0
0 comments X

The pith

Architecture-aware documentation guides agents to migrate entire C repositories to Rust

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

The paper introduces RustPrint, a framework that turns a C codebase into detailed architecture-aware documentation capturing module structure, data flow, APIs, and design rationale, then treats this documentation as a blueprint for coding agents. The agents use the blueprint to plan Rust crates, implement modules, verify compilation, reduce unsafe code, and refine the output by spotting mismatches when new documentation is generated from the Rust side and by running translated tests to catch runtime issues. Experiments on eight real C repositories from 11K to 84K lines show the system produces compilable Rust code for every target under both open-weight and closed-weight LLM backbones, where earlier translators fail entirely. A reader would care because legacy C code often needs memory safety improvements that manual migration cannot scale to large repositories.

Core claim

RustPrint first converts the source C repository into architecture-aware documentation that captures module structure, data flow, APIs, and design rationale. Coding agents then use this documentation as a blueprint to plan Rust crates, implement modules, check for compilability, reduce unsafe code, and iteratively refine the translated code. The system compares the documentation generated from the Rust output to the source documentation to identify mismatches for repair and also translates and runs the original test suites to guide fixes based on runtime failures.

What carries the argument

Architecture-aware documentation generated from the source repository, used as a migration blueprint that agents follow for planning, implementation, compilation checks, and repair via documentation mismatches and test failures.

If this is right

  • RustPrint produces compilable Rust code for every one of the eight tested C repositories under both open-weight and closed-weight LLM backbones.
  • With the Kimi-K2-Instruct backbone the system reaches 93.26 percent feature preservation and 95.17 percent cross-evaluation test pass rate, exceeding the agentic Claude Code baseline.
  • Prior LLM-based translators Self-Repair and EvoC2Rust fail to produce repository-wide compilable output on the same targets.
  • Documentation mismatches between source and translated versions, together with test-suite failures, supply targeted repair signals that improve the final Rust code.

Where Pith is reading between the lines

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

  • The same documentation-first coordination could be tried for other source-to-target language pairs if comparable architecture documentation can be extracted automatically.
  • Performance may vary with the fidelity of the initial documentation, so controlled tests that degrade the blueprint detail would reveal how much accuracy is required.
  • The repair loop that compares generated documentation and runs tests might apply to other agentic coding tasks such as large-scale refactoring or feature addition.

Load-bearing premise

The architecture-aware documentation generated from the source repository accurately captures module structure, data flow, APIs, and design rationale in sufficient detail to serve as an effective migration blueprint that agents can use for planning and repair.

What would settle it

Running the framework on one of the same repositories but with deliberately incomplete or inaccurate documentation and checking whether the agents still produce fully compilable, feature-preserving Rust code would test whether the blueprint quality is essential.

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

2 major / 2 minor

Summary. The paper introduces RustPrint, a documentation-guided agentic framework for repository-level C-to-Rust migration. It first generates architecture-aware documentation from the source C codebase to serve as a migration blueprint capturing module structure, data flow, APIs, and design rationale. LLM-based coding agents then use this blueprint to plan crates, implement modules, check compilability, reduce unsafe code, and iteratively refine the translation. The framework compares documentation from the Rust output against the source for 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 full compilation success under both Kimi-K2-Instruct and GPT-5.4 backbones, while prior methods (Self-Repair, EvoC2Rust) fail repository-wide; with the open-weight backbone it also outperforms 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 results hold under scrutiny, the work provides empirical support for documentation-guided agentic coordination as a scalable approach to repository-wide migration, addressing a key limitation of prior file- or function-level translators that miss architectural intent. The evaluation on multiple large, real-world repositories and across open- and closed-weight LLM backbones is a clear strength, as is the use of concrete, multi-faceted metrics (compilation success, feature preservation, and runtime test pass rates) rather than synthetic benchmarks. These elements position the paper as a useful contribution to automated software migration and LLM-agent tooling in software engineering.

major comments (2)
  1. [§3] §3 (Documentation Generation and Blueprint Usage): the central claim attributes repository-wide compilation and the 93.26% feature-preservation gain to the architecture-aware documentation serving as an effective migration blueprint, yet the manuscript reports no quantitative fidelity metric (e.g., API extraction precision/recall against ground-truth headers or human-rated coverage of cross-module invariants) and no ablation that removes the documentation component while retaining the agentic repair loops and test feedback.
  2. [§4.2] §4.2 (Baseline Comparisons): the reported superiority over the agentic Claude Code baseline (93.26% vs. 52.52% feature preservation) does not specify whether the baseline was given equivalent access to source-derived architectural documentation or the same iterative repair and test-execution harness; without this control, the performance delta cannot be confidently attributed to the documentation-guided mechanism.
minor comments (2)
  1. [Abstract] The abstract and §4 refer to “cross-evaluation test pass rate” without a concise definition or pointer to the exact protocol used to generate and execute the cross-evaluated test suites.
  2. [§4] Figure captions and table headers in the experimental section would benefit from explicit column definitions (e.g., what “feature preservation” counts as a preserved feature) to improve reproducibility.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the positive assessment of the work's significance and for the constructive comments. We address each major comment below and describe the revisions we will make to strengthen the claims regarding the documentation blueprint and baseline controls.

read point-by-point responses

  1. Referee: [§3] §3 (Documentation Generation and Blueprint Usage): the central claim attributes repository-wide compilation and the 93.26% feature-preservation gain to the architecture-aware documentation serving as an effective migration blueprint, yet the manuscript reports no quantitative fidelity metric (e.g., API extraction precision/recall against ground-truth headers or human-rated coverage of cross-module invariants) and no ablation that removes the documentation component while retaining the agentic repair loops and test feedback.

    Authors: We agree that a quantitative fidelity metric for the generated documentation and an ablation isolating its contribution would provide stronger support for the central claim. In the revised manuscript we will add (i) precision/recall metrics for API and module-structure extraction against ground-truth headers on a representative subset of the eight repositories and (ii) an ablation in which the agentic loops and test-feedback harness operate without the architecture-aware documentation. These additions will be reported in an expanded §3 and §5. revision: yes

  2. Referee: [§4.2] §4.2 (Baseline Comparisons): the reported superiority over the agentic Claude Code baseline (93.26% vs. 52.52% feature preservation) does not specify whether the baseline was given equivalent access to source-derived architectural documentation or the same iterative repair and test-execution harness; without this control, the performance delta cannot be confidently attributed to the documentation-guided mechanism.

    Authors: The agentic Claude Code baseline was run with the identical iterative repair and test-execution harness used by RustPrint but without access to the source-derived architectural documentation. We will revise §4.2 to state this configuration explicitly and to clarify that the documentation blueprint is the sole differing component. If the referee considers an additional controlled run necessary, we can perform it in the revision. revision: yes

Circularity Check

0 steps flagged

No circularity: empirical evaluation on external benchmarks

full rationale

The paper describes an agentic migration system (RustPrint) that generates architecture-aware documentation from C repositories and uses it to guide LLM agents for translation, compilation checking, and repair. All load-bearing claims rest on direct experimental measurements across eight real-world repositories (11K–84K LoC), including repository-wide compilation success, feature preservation (93.26%), and cross-evaluation test pass rates (95.17%), compared against independent baselines (Self-Repair, EvoC2Rust, agentic Claude Code). No equations, fitted parameters, self-citations, or uniqueness theorems are invoked to derive results; the architecture-aware documentation is treated as an input artifact whose effectiveness is measured externally rather than assumed by construction. The work is therefore self-contained against external benchmarks.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 1 invented entities

The approach rests primarily on the domain assumption that LLMs can reliably interpret and act on architecture-aware documentation for large-scale code changes; no free parameters or invented physical entities are introduced.

axioms (1)
  • domain assumption Large language models can effectively interpret architecture-aware documentation to coordinate repository-level code planning, implementation, and repair.
    This assumption underpins the agentic use of the generated blueprint and is invoked throughout the framework description.
invented entities (1)
  • Architecture-aware documentation as migration blueprint no independent evidence
    purpose: Captures module structure, data flow, APIs, and design rationale to guide agents in producing faithful Rust translations.
    Core new artifact introduced by the framework; no independent evidence outside the paper's experiments is provided.

pith-pipeline@v0.9.0 · 5798 in / 1612 out tokens · 74214 ms · 2026-05-20T21:14:55.923131+00:00 · methodology

discussion (0)

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

Lean theorems connected to this paper

Citations machine-checked in the Pith Canon. Every link opens the source theorem in the public Lean library.

What do these tags mean?
matches
The paper's claim is directly supported by a theorem in the formal canon.
supports
The theorem supports part of the paper's argument, but the paper may add assumptions or extra steps.
extends
The paper goes beyond the formal theorem; the theorem is a base layer rather than the whole result.
uses
The paper appears to rely on the theorem as machinery.
contradicts
The paper's claim conflicts with a theorem or certificate in the canon.
unclear
Pith found a possible connection, but the passage is too broad, indirect, or ambiguous to say the theorem truly supports the claim.

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.