{"id":"07f2c7f8-863d-4cd9-8c60-b38844f655e2","arxiv_id":"2603.02617","paper_version":4,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"high","formal_verification":"none","parameter_count":5,"one_line_summary":"Combining build-trace-derived skeletons with a knowledge base of historical translation pairs raises C-to-Rust compilation pass rates and lowers unsafe-code ratios, but on general benchmarks functional-correctness scores actually decrease relative to C2Rust.","lead":"His2Trans is a framework that translates C projects to Rust by first rebuilding a compilable Rust skeleton from the project's real build traces, then using a knowledge base of past C-to-Rust translation pairs to guide the remaining function-by-function translation. On tested OpenHarmony modules it reports 97.51% incremental compilation success under its best configuration, but the version's abstract claims 100%, and on general benchmarks its test pass rate (58.18%) trails C2R","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The self-evolving knowledge base accepts pairs on compilation success alone (Algorithm 2 line 12), and with FC at 58.18% on general benchmarks, a large share of accumulated 'accepted' pairs may be behavior-changing — the central correctness claim is not actually validated.","rationale":"The reader identified the same weakest assumption: compilation success is not semantic equivalence. I agree this is the most load-bearing point. The paper's own data (FC ~58% on general benchmarks) shows a large share of compiled outputs are behaviorally wrong, and the algorithm feeds those outputs back into the knowledge base, creating a feedback loop that can amplify rather than correct errors. The concern is not about disagreement with consensus; it's an internal inconsistency: the framework claims to 'preserve observable behavior' while its acceptance criterion never checks behavior. A revised acceptance gate—or at least an evaluation of the accumulated KB's semantic fidelity—is needed. The reader's CONDITIONAL verdict is appropriate; my concern reinforces it rather than changing it. I did not find a more load-bearing issue: the abstract/body number discrepancy is important but addressable by revision; the in-distribution evaluation limits generalization but doesn't invalidate the in-domain claims; the lack of artifacts is a reproducibility concern, not a correctness concern. The compilation-acceptance issue is the one that, if it lands, undermines the core mechanism.","tokens_in":19546,"tokens_out":6374,"duration_ms":59460,"concrete_test":"Re-run RQ4 with one change: when accumulating pairs into the KB (Algorithm 2 line 12), include only pairs whose translated Rust passes the original unit tests (or a differential test against the C version). Keep everything else identical; translate Group B (host, appverify_lite) with this test-filtered KB. If FC on Group B is higher than the 37.50% reported with the compile-only KB, or if AvgRepair is not lower, the compilation-only accumulation is polluting the KB; if the numbers are unchanged, the concern is not load-bearing.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim that His2Trans 'preserves observable behavior' rests on an acceptance gate that only checks compilation. Algorithm 2 line 12 accumulates a pair into K as soon as CompileAndInstall returns ok; functional tests are not part of that gate (§2.3.4). The mining pipeline (Algorithm 1) also aligns file/function pairs via BM25 and semantic-similarity heuristics, with no equivalence check. This is not merely a theoretical gap: Table 6 reports FC = 58.18% (Claude) and 47.27% (DeepSeek) on the general-purpose benchmarks, meaning roughly 40–50% of the compiled, i.e., 'accepted', translations fail the projects' own tests. Under the accumulation rule, those failing versions are exactly the pairs inserted into K. A wrong-but-compiling translation therefore becomes a reusable API or fragment rule for all later, dependent translations. RQ4's measured benefit (+0.87% ICompRate, −60.69% AvgRepair) reflects only compilation efficiency; it never measures whether the accumulated rules improve or corrupt semantic correctness. The paper's Section 5 threats acknowledge domain bias and test adequacy but never flag that compilation acceptance is not a behavioral equivalence gate—which is the assumption on which the entire self-evolving loop depends. Until accepted pairs are filtered by differential or test-based equivalence, the headline claim that knowledge-guided migration 'preserv[es] observable behavior' is unsupported, and the KB may be a vector for silently changing program semantics.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"His2Trans is a project-level C-to-Rust migration framework designed for build-complex, partially migrated ecosystems. It first reconstructs a compilable Rust project skeleton from build traces, then translates function bodies bottom-up using LLMs while retrieving API- and fragment-level rules from a knowledge base mined from historical C/Rust migration pairs. Compiler-feedback repair is used iteratively, and successfully compiled translation pairs are accumulated back into the knowledge base. The evaluation reports a 97.51% incremental compilation pass rate on five OpenHarmony modules, mixed C/Rust builds without observed interface mismatches, and, on nine general-purpose benchmarks, 95.74% ICompRate and a reduction in unsafe ratio from 67.93% (C2Rust) to 43.91% (Claude backend), with functional correctness of 58.18%/47.27% depending on the backend. RQ4 reports that accumulated knowledge reduces average repair rounds by about 60% on unseen OpenHarmony modules. The paper's central claim is that skeleton-first translation combined with historical knowledge reuse is an effective, practical strategy for gradual C-to-Rust migration.","tokens_in":20000,"tokens_out":6472,"duration_ms":56315,"significance":"If the full-text results are accurate, the skeleton-first build-trace recovery is a genuinely useful architectural contribution: it addresses the 'dependency hell' problem that blocks project-level translation, and the mixed C/Rust interoperability evidence is a step beyond isolated function-level evaluation. The paper also ships a code link, uses a zero-human-intervention protocol, and includes detailed ablations (RQ3, RQ4) on knowledge and repair effects. However, the semantic-correctness validation is insufficient for the strength of the claims. The knowledge accumulation loop accepts pairs on compilation success alone, but the paper's own functional correctness results show that a large fraction of compiled outputs fail tests. The abstract also reports numbers that do not match Section 4. These issues affect load-bearing claims about 'preserving observable behavior' and require substantive revision.","major_comments":[{"comment":"The knowledge base accumulates a pair as soon as CompileAndInstall returns ok; no test or differential equivalence check is part of this gate. Section 3.3 says acceptance criteria are 'compilation success and downstream project-level test outcomes where available,' but Algorithm 2 never invokes tests. Table 6 shows FC = 58.18% (Claude) and 47.27% (DeepSeek) on general benchmarks, meaning a large fraction of compiled outputs fail tests, yet those outputs are exactly the pairs inserted into K. A wrong-but-compiling translation thus becomes a reusable API/fragment rule for later translations. RQ4's +0.87% ICompRate and -60.69% AvgRepair measure only compilation efficiency, not semantic correctness. The claim that His2Trans preserves observable behavior is therefore unsupported unless accepted pairs are filtered by test/differential equivalence or the claims are reframed.","section":"§2.3.4, Algorithm 2 line 12"},{"comment":"The abstract reports 100.00% ICompRate, 94.92% Test Pass Rate, and 16.35% Unsafe Ratio on 'ten OpenHarmony modules,' and 100%/100%/8.59% on 'eight open-source C projects.' Section 4 reports 97.51% ICompRate, 75% FC, and 37.09% Unsafe on five OpenHarmony modules, and 95.74%/58.18%/43.91% on nine general-purpose benchmarks. Both the numbers and the project counts differ. Since the abstract is the paper's headline evidence, this discrepancy must be resolved before the full-text results can be reliably assessed.","section":"Abstract vs. Section 4 (Tables 5-6)"},{"comment":"The KB is mined from OpenHarmony's historical C/Rust migrations, and the principal evaluation of the KB benefit (RQ1, RQ4) is on OpenHarmony modules. Although the evaluated modules are excluded from KB construction, the KB's rules are still drawn from the same ecosystem, so the in-domain tests cannot separate knowledge-reuse benefits from domain overlap. RQ2's cross-domain stress test shows why this matters: FC drops to 58.18%/47.27%, below C2Rust's 94.55%. An out-of-ecosystem industrial evaluation, or an ablation that runs RQ1 with the KB withheld, would isolate the claimed contribution of historical knowledge reuse.","section":"§2.1, §3.1, §3.2"},{"comment":"In the actual retrieval setting, Pred-Rep achieves ICompRate 82.50% and AvgRepair 1.55, both worse than Base-Rep (90.00%, 1.52); only ground-truth rules improve repair efficiency. Thus the paper's own ablation shows that automatically retrieved rules do not yet provide a clear benefit under the repair loop; the knowledge-reuse advantage is demonstrated mainly with oracle knowledge. The interpretation in §4.3.2 acknowledges this, but the general claim that historical knowledge reuse is effective should be calibrated to the automatically mined KB rather than the ground-truth setting.","section":"§4.3, Table 7"}],"minor_comments":[{"comment":"The abstract says 'ten OpenHarmony modules' and 'eight open-source C projects,' while Table 4 lists five industrial modules and nine general-purpose projects. Align the counts and metric names.","section":"Abstract / Table 4"},{"comment":"Use a single term for the correctness metric: the abstract says 'Test Pass Rate,' while Section 3 defines 'Functional Correctness (FC).' Define both or standardize.","section":"Metrics"},{"comment":"The claim that 'every test that passes in the fully translated version also still passes in the mixed version' should include the actual per-module test counts, because the fully translated version of appverify_lite fails before test execution.","section":"§4.1.3"},{"comment":"The test-suite adequacy threat does not mention the compilation-only acceptance gate. This omission is important given that the knowledge accumulation loop depends on that gate.","section":"§5 Threats to Validity"},{"comment":"His2Trans warning counts on OpenHarmony modules are far higher than C2Rust's (e.g., 315.40 vs. 45.00 for the best configuration). The main text's warning-benefit claim is made only for RQ2, but the contrast should be stated explicitly to avoid overgeneralization.","section":"Table 5"}],"recommendation":"major_revision","confidential_remarks":"The abstract/full-text discrepancy is severe enough that I would ask the authors to confirm which set of numbers is canonical before any further review. The compilation-gate problem is the deeper scientific issue: the self-evolving KB may accumulate behavior-changing translations, and the RQ4 results do not address this. I see a strong engineering contribution, but the behavioral-preservation claims need either new validation or careful restatement."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Short version: this paper is worth reading. His2Trans is a real system that combines two ideas that have been floating around — build-trace-recovered project skeletons (EvoC2Rust has skeleton-first, but not from actual build traces) and historical retrieval of C/Rust translation pairs — and the combination, plus the accumulation loop, is new enough. The evaluation is a cut above the usual LLM-translation papers: they report compile pass rates, test pass rates, unsafe ratios, warnings, repair rounds, and they actually run mixed C/Rust builds on the OpenHarmony modules. The skeleton-first design demonstrably fixes a real failure mode: C2Rust and EvoC2Rust basically die on the OH modules, while His2Trans gets 97.51% ICompRate with Claude. The RQ3 ablation is also well done: one-shot generation without repair gets 42.5%, with repair 90%, so the compiler-feedback loop is doing real work.\n\nThe soft spots are proportionate but they matter. First, the arXiv metadata abstract is not the full-text abstract: it claims 100% / 94.92% / 16.35% on OpenHarmony and 100% on eight open-source projects, but Section 4 reports 97.51% ICompRate, 75% FC, ~37% unsafe on five OH modules and nine general projects. That discrepancy needs to be fixed before this goes anywhere. Second, and more importantly, the knowledge accumulation loop accepts a pair as soon as it compiles (Algorithm 2, line 12). No differential testing, no behavioral check. The paper's own numbers show why this matters: on the general benchmarks, FC is 58.18% (Claude) and 47.27% (DeepSeek), so roughly 40-50% of the compiled outputs fail the projects' tests. Those failing-but-compiling translations are exactly what gets fed back into the KB. The paper acknowledges domain bias and test adequacy in Section 5, but never flags this equivalence-gate problem. Third, the OpenHarmony evaluation is in-distribution with the mined KB (same ecosystem), and the paper only excludes the evaluated modules from KB construction — it doesn't show transfer to a held-out ecosystem with real migration history.\n\nNone of these sink the paper. The framework's main contribution — making compile feasibility high on build-complex, partially migrated code — is supported. The semantic-correctness claim is weaker: the low FC on general benchmarks is honestly reported, but the KB accumulation risk means the self-evolving story should be read as an efficiency improvement, not a correctness guarantee. The authors should add a held-out-ecosystem experiment, filter accepted pairs by tests, and fix the abstract. That's revision, not rejection.\n\nFor a reader working on migration or program repair, this is worth a serious referee. I'd bring it to our reading group and cite the skeleton-first result.","headline":"A genuinely useful skeleton-first C-to-Rust migration framework with an honest evaluation, but the self-evolving knowledge base accumulates on compilation success alone and the paper never confronts what that does to semantic correctness.","tokens_in":20462,"tokens_out":4066,"would_cite":true,"duration_ms":33698,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"His2Trans claims that reconstructing a compilable Rust skeleton from real build traces before translating function bodies, and reusing accepted C/Rust translation pairs, makes incremental C-to-Rust migration practical in build-complex, part","keywords":["C-to-Rust migration","incremental compilation","knowledge reuse","build traces","skeleton-first translation","compiler-guided repair","unsafe code","partially migrated ecosystems"],"falsifier":"Run the translated Rust and original C on the same inputs—through differential fuzzing or property-based testing—and check whether outputs and observable side effects match; if a substantial fraction of compilation-accepted functions diverge on inputs the original handles, the compilation-as-acceptance assumption is false and the knowledge accumulation loop becomes a bug-propagation loop.","tokens_in":19443,"feed_emoji":"🦀","tokens_out":6165,"duration_ms":49763,"temperature":0.7,"pith_summary":"The paper argues that project-level C-to-Rust migration fails because build-critical context is lost when translating files in isolation, and because reusable knowledge from past migrations is ignored. His2Trans addresses both by first reconstructing a compilable project-level Rust skeleton from build traces, with placeholder bodies, and then translating function bodies bottom-up, guided by API-level and fragment-level rules mined from previously accepted C/Rust translation pairs. The framework claims high incremental compilation pass rates, a substantial reduction in unsafe code relative to a rule-based transpiler baseline, and support for mixed C/Rust builds without interface mismatches. If these results hold, automated gradual migration becomes a realistic engineering option for long-lived ecosystems with migration history rather than a function-level toy problem.","feed_headline":"Skeleton-first C-to-Rust migration hits 97.5% compile success","feed_subtitle":"Reusing accepted C/Rust pairs cuts unsafe code and repair rounds in partially migrated codebases.","key_machinery":"The load-bearing machinery has three parts. (1) Project-Level Skeleton Graph: a typed module-and-dependency graph recovered from build traces (compile commands, preprocessing, symbol extraction); it makes implicit build context explicit as Rust references and compiles with placeholder bodies, turning global build failures into localized repair tasks. (2) Knowledge base of API-Level and Fragment-Level rules: mined from historical C/Rust repositories via file-level and function-level retrieval and reranking, these rules tell the translator which Rust interface to call and which local idiom to use, instead of letting the model invent APIs. (3) Compiler-feedback repair loop with knowledge accumu","core_discovery":"The central discovery is that 'dependency hell' in project-level C-to-Rust translation can be largely defused by making the build itself the first-class context. Before any function body is generated, His2Trans runs the real build, preprocesses each translation unit under its actual compile flags, and recovers the concrete type definitions, global symbols, signatures, and module dependencies that the compiler would see. These are assembled into a Project-Level Skeleton Graph whose placeholder bodies compile, so every later function translation is a localized insertion into an already valid crate rather than a leap over unknown interfaces. Translation is scheduled bottom-up along the dependen","pith_inferences":["The acceptance gate is compilation success, not behavioral equivalence; a compiled but semantically divergent function fed back into the knowledge base could propagate a wrong pattern to all later translations. Differential testing or property-based testing on the translated output would be a natural strengthening.","The framework's benefit likely scales with the richness of the target ecosystem's migration history; greenfield migrations without historical C/Rust pairs would lose most of the knowledge-reuse advantage and rely on the skeleton and repair loop alone.","The reported repair-round reduction suggests the knowledge base acts as a consistency prior as much as a correctness boost; its main value may be in keeping long-lived ecosystems stylistically coherent rather than in unlocking hard semantic cases, which remain at roughly 75% functional correctness on the industrial modules."],"forward_implications":["If the framework's results hold, gradual C-to-Rust migration becomes a build-driven process: first stabilize the skeleton, then fill bodies, rather than a one-shot rewrite.","Mixed C/Rust coexistence is supported: translated Rust modules link with untranslated C modules without observed FFI mismatches, and tests that pass fully translated also pass in mixed builds.","Historical knowledge reuse substantially reduces repair cost: accumulating accepted pairs cuts average repair rounds on unseen modules by about 60%, making long-lived migration more economical.","Cross-domain transfer is partial: on general-purpose benchmarks the framework keeps high compilation feasibility and lowers unsafe code, but functional correctness trails a rule-based transpiler, implying the approach is strongest when the target ecosystem shares migration history with the knowledge base.","The unsafe ratio drops significantly (e.g., 24 percentage points relative to a rule-based transpiler on general benchmarks), meaning the output is closer to idiomatic safe Rust."],"fun_headline_variants":["Build-first skeleton graph makes C-to-Rust translation modular","C-to-Rust migration: compile skeleton before translating functions","His2Trans: project-scale C-to-Rust with 100% compile pass","Defuse dependency hell: build-first C-to-Rust translation","Knowledge-guided C-to-Rust: reuse past migrations for safer code"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"The framework treats compilation success as the gate for accepting a translated function and feeds accepted pairs back into the knowledge base, so a compiled but behaviorally wrong Rust function becomes a reusable rule that can mislead all later translations.","fun_headline_variants_meta":{"raw":{"variants":["Build-first skeleton graph makes C-to-Rust translation modular","C-to-Rust migration: compile skeleton before translating functions","His2Trans: project-scale C-to-Rust with 100% compile pass","Defuse dependency hell: build-first C-to-Rust translation","Knowledge-guided C-to-Rust: reuse past migrations for safer code"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000549,"raw_usage":{"total_tokens":2480,"prompt_tokens":791,"completion_tokens":1689,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":535,"completion_tokens_details":{"reasoning_tokens":1614}},"tokens_in":535,"tokens_out":1689,"duration_ms":9900,"temperature":1.0,"reasoning_tokens":1614,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-02T19:17:38.003955+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the translated Rust and original C on the same inputs—through differential fuzzing or property-based testing—and check whether outputs and observable side effects match; if a substantial fraction of compilation-accepted functions diverge on inputs the original handles, the compilation-as-acceptance assumption is false and the knowledge accumulation loop becomes a bug-propagation loop.","supporting_citations":[],"review_version":1}