arXiv:2604.17016v1 [cs.SE] 18 Apr 2026
HELO-APR: Enhancing Low-Resource Program Repair through Cross-Lingual Knowledge Transfer ZHIPENG WANG, State Key Laboratory for Novel Software Technology, Nanjing University, China BOYANG YANG, School of Artificial Intelligence (School of Software), Yanshan University, China YIDONG WAN, State Key Laboratory for Novel Software Technology, Nanjing University, China LIUYE GUO, State Key Laboratory for Novel Software Technology, Nanjing University, China YOU LV, Jiangsu University, China TAO ZHENG, State Key Laboratory for Novel Software Technology, Nanjing University, China ZHUOWEI WANG∗ , School of Computer Science and Technology, Guangdong University of Technology, China
TIEKE HE∗ , State Key Laboratory for Novel Software Technology, Nanjing University, China Large Language Models (LLMs) perform well on automatic program repair (APR) for high-resource programming languages (HRPLs), but their effectiveness drops sharply in low-resource programming languages (LRPLs), due to a lack of sufficient verified buggy-fixed pairs for APR training. To address this challenge, we propose HELO-APR (H igh-resource Enabled LOw-resource APR), a two-stage APR framework that enables cross-lingual transfer of repair knowledge from HRPLs to LRPLs. HELO-APR (1) constructs high-quality LRPL training data by synthesizing LRPL buggy-fixed pairs from HRPL counterparts, preserving defect type consistency while ensuring the synthesized code is idiomatic, and then (2) adopts a curriculum learning strategy that progressively performs HRPL repair learning, cross-lingual repair alignment, and LRPL repair adaptation, improving repair effectiveness in LRPLs. Using C++ as the source HRPL and Ruby and Rust as the target LRPLs, experiments on xCodeEval show that HELO-APR consistently outperforms strong baselines, increasing Pass@1 from 31.32% to 48.65% on DeepSeek-Coder-6.7B and from 1.67% to 11.97% on CodeLlama-7B, while improving syntactic validity by raising the average target compilation rate on CodeLlama from 49.77% to 91.98%. On Defects4Ruby, HELO-APR increases BLEU-4 from 61.20 to 66.79 and ROUGE-1 from 76.76 to 83.59 on CodeLlama-7B, indicating higher similarity to developer patches in real-world settings. Finally, we conduct ablation studies to assess the necessity of each core component. These results suggest that verified cross-lingual supervision provides a reusable approach for improving LLM-based repair in low-resource languages. ∗ Corresponding authors
Authors’ Contact Information: Zhipeng Wang, [email protected], State Key Laboratory for Novel Software Technology, Nanjing University, Nanjing, China; Boyang Yang, [email protected], School of Artificial Intelligence (School of Software), Yanshan University, Qinhuangdao, China; Yidong Wan, [email protected], State Key Laboratory for Novel Software Technology, Nanjing University, Nanjing, China; Liuye Guo, [email protected], State Key Laboratory for Novel Software Technology, Nanjing University, Nanjing, China; You Lv, [email protected], Jiangsu University, Zhenjiang, China; Tao Zheng, [email protected], State Key Laboratory for Novel Software Technology, Nanjing University, Nanjing, China; Zhuowei Wang, [email protected], School of Computer Science and Technology, Guangdong University of Technology, Guangzhou, China; Tieke He, [email protected], State Key Laboratory for Novel Software Technology, Nanjing University, Nanjing, China. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected]. © 2026 Copyright held by the owner/author(s). Publication rights licensed to ACM. ACM 2994-970X/2026/7-ARTXX https://doi.org/XXXXXXX.XXXXXXX Proc. ACM Softw. Eng., Vol. X, No. ISSTA, Article XX. Publication date: July 2026.
XX:2
Wang et al.
STAGE 2: Model Fine-tuning
STAGE 1:LRPL Dataset Construction
HRPL Bug-Fix Pairs
Code Translation
Defect Injection CodeLLaMA
LRPL Bug-Fix Pairs
+
Challenge 1: Non-Transferable Defects
Challenge 2: Idiomatic Structural Obscuration C-Style Loop
HRPL (e.g., C++)
int arr[5]; int *ptr = arr; *(ptr+10) = 0; //BUG
LRPL (e.g., Ruby) Absent Features # No direct pointer arithmetic
for ( int i = 0; i < n; i++ ){ ... arr[i] ... Structural Anchors } Idiomatic Translation
Defect
Defect relies on variable i
Ruby Functional Iterator array.each do |item| ... ? item ... end
Missing Anchors for Defect Injection
Challenge 3: Validation Absence Synthesized Ruby Bug-Fix Pair def calc(data) res = 0 # ... return res end
DeepSeek-Coder
Challenge 4: Neglected Cross-Lingual Alignment HRPL Bug-Fix Pairs
Missing Test Cases
def calc(data) res = 0 # ... return 0 # BUG end
Neglected Alignment (Repair Knowledge)
CodeLLaMA
DeepSeek-Coder
LRPL Bug-Fix Pairs
Fig. 1. Overview of the cross-lingual APR workflow (upper) and four critical challenges limiting its effectiveness (lower): (1) Non-Transferable Defects, (2) Idiomatic Structural Obscuration, (3) Validation Absence, and (4) Neglected Cross-Lingual Repair Alignment.
ACM Reference Format: Zhipeng Wang, Boyang Yang, Yidong Wan, Liuye Guo, You Lv, Tao Zheng, Zhuowei Wang, and Tieke He. 2026. HELO-APR: Enhancing Low-Resource Program Repair through Cross-Lingual Knowledge Transfer. Proc. ACM Softw. Eng. X, ISSTA, Article XX (July 2026), 21 pages. https://doi.org/XXXXXXX.XXXXXXX
1
Introduction
LLMs have advanced automated program repair (APR), but effectiveness still varies substantially across programming languages [8, 14, 15, 19, 21, 25, 26, 30, 31]. LLMs perform well in high-resource programming languages (HRPLs), such as Python, Java, and C++ [22, 23, 30], but remain weaker in low-resource programming languages (LRPLs), such as Ruby and Rust [2, 18, 20]. A primary driver is data scarcity: LRPLs lack sufficient validated buggy-fixed pairs to support learning robust repair patterns [33]. To mitigate this gap, prior work has mainly focused on two directions. One direction constructs synthetic buggy-fixed data. For example, Wong et al. [20] construct buggy-fixed pairs by collecting LLM-generated buggy codes and synthesizing fixes with stronger LLMs. Although this pipeline scales, it is constrained by the generator’s capabilities. Synthesized defects are often simplistic or repetitive (e.g., generic syntax errors) and fail to capture the semantic complexity of real-world bugs. Another direction leverages high-resource data for transfer. Baltaji et al. [2] fine-tune LLMs on HRPL buggy-fixed pairs and apply them to LRPLs, motivated by the intuition that repair logic (e.g., for off-by-one errors) is shared across different programming languages. While such HRPL-only training can yield modest improvements, its effectiveness remains limited. Our preliminary analysis (§5.1) suggests that a key factor is syntactic interference: when repairing target-language code, LLMs fine-tuned only on source languages sometimes generate source-language patches, which fail to compile under the target-language toolchain. For example, after fine-tuning CodeLlama on 10,000 C++ samples and evaluating on Ruby, 31.58% of the top-1 patches are syntactically valid C++ rather than Ruby. Proc. ACM Softw. Eng., Vol. X, No. ISSTA, Article XX. Publication date: July 2026.
HELO-APR: Enhancing Low-Resource Program Repair through Cross-Lingual Knowledge Transfer
XX:3
To bridge the gap between the lack of diversity in synthetic data and the syntactic interference introduced by direct transfer, we propose a third direction: translating HRPL buggy-fixed pairs into LRPLs and leveraging them for LLM fine-tuning (as illustrated in Figure 1). This approach combines the realistic complexity of HRPL data with the correct syntax of the target language. However, realizing this workflow is non-trivial. Specifically, during dataset construction, we encounter three challenges: (1) Non-Transferable Defects, where certain source-language defects do not exist in the target language; (2) Idiomatic Structural Obscuration, where abstract syntax patterns hide the structural anchors required for defect injection; and (3) Validation Absence, which prevents verifying defect behavior due to missing test cases. In addition, training solely on synthetic data during fine-tuning is insufficient. As reflected in the fourth challenge, standard fine-tuning ignores the parallel relationship between HRPL and target LRPL data, leading to (4) Neglected Cross-Lingual Repair Alignment. To address these challenges, we propose HELO-APR, a two-stage approach for improving automated program repair in LRPLs. First, for dataset construction, we synthesize high-fidelity LRPL buggy-fixed pairs. We apply Transferability Analysis to pre-filter source samples with non-transferable defects, followed by a structure-constrained translation and injection strategy that preserves defect injection anchors during translation, enabling reliable defect reproduction while maintaining idiomatic LRPL code. Finally, a test-driven verification step is employed to select high-quality buggy-fixed pairs for subsequent training. Second, for model fine-tuning, we address the challenge of Neglected Cross-Lingual Repair Alignment via a curriculum learning-based strategy that explicitly leverages the consistency of repair behaviors across parallel HRPL-LRPL data. Specifically, the model is trained across three progressive stages: HRPL repair learning, cross-lingual repair alignment (using synthesized parallel pairs to bridge linguistic gaps), and LRPL repair adaptation, enabling effective knowledge transfer to LRPLs. Contributions. This paper makes the following contributions: • Data. We construct a cross-lingual parallel repair dataset spanning one HRPL (C++) and two LRPLs (Ruby and Rust), maintaining defect consistency while ensuring idiomatic code in the target LRPLs • Method. We propose HELO-APR, a two-stage approach that includes: (1) LRPL Dataset Construction, which synthesizes high-fidelity LRPL buggy-fixed pairs; and (2) Cross-Lingual Knowledge Transfer, which applies a three-stage curriculum to progressively transfer repair knowledge from HRPLs to LRPLs. • Evaluation. We show that HELO-APR substantially improves repair performance for LRPLs, increasing Pass@1 on DeepSeek-Coder-6.7B by 55.33% relatively (from 31.32% to 48.65%) and over 7 times on CodeLlama-7B (from 1.67% to 11.97%) compared to zero-shot baselines. • Analysis. We conduct ablation studies to isolate the impact of keycomponents and evaluate generalization on a repository-level benchmark, Defects4Ruby. 2
LRPL Dataset Construction
To alleviate the severe scarcity of high-quality buggy-fixed data in LRPLs, we propose an automated pipeline that synthesizes buggy-fixed pairs in LRPLs from HRPLs. The overall pipeline consists of two high-level stages. First, we translate fixed programs from HRPLs into LRPLs while preserving both functional correctness and code naturalness (§2.1). Second, we inject defects into the translated LRPL programs by referencing the corresponding defects in HRPLs, yielding LRPL buggy-fixed Proc. ACM Softw. Eng., Vol. X, No. ISSTA, Article XX. Publication date: July 2026.
XX:4
Wang et al.
CPP Fixed Code
CPP Buggy Code
... void printReverse(const vector<int>& arr) { for (int i = arr.size() - 1; i >= 0; i--) { cout << arr[i] << " "; } } ...
... void printReverse(const vector<int>& arr) { for (int i = arr.size() - 1; i > 0; i--) { cout << arr[i] << " "; } } ...
Stage1 Translation of Fixed HRPL Programs Step1 Transferability Analysis
Step2 Structure-Constrained Translation
Step3 Correctness Verification
Translation:Guide LLM using ΔDiff
Extract Defect Descriptor
Test Case Generation
Defect-Related Regions (Structure-Constrained)
Coverage Filtering (Threshold: >90% coverage)
Defect-Irrelevant Regions (No-Constrained)
Defect Descriptor(Ddesc)
ΔDiff: ... for (int i = arr.size() - 1; i > 0; i--) { for (int i = arr.size() - 1; i >= 0; i--) { ...
Test Case
Ruby Fixed Code Candidate ... def print_reverse(arr) (arr.size - 1).downto(0) do |i| print "#{arr[i]} " end end ...
Type: Off-by-one RootCause: Strict inequality caauses premature loop termination, excluding the 0-th index.
Transferability Assessment
"Input": [1, 2, 3, 4, 5], "Output": (Oracle from HRPL) [5, 4, 3, 2, 1]
Test Execution
Anchor PRESERVED: Loop boundary '0' is visible. Ready for Bug Injection.
Pass
Verified Ruby Fixed Code
Stage2 Defect Injection into Translated Programs Step4 Defect Injection
Step5 Defect Behavior Assessment Defect Behavior Definition
Ruby Buggy Code Candidate
Verified Ruby Fixed Code
... def print_reverse(arr) (arr.size - 1).downto(1) do |i| print "#{arr[i]} " end end ...
Trigger_Condition: Array Length >=1 Expected_Failure: Missing the last element (index 0)
1. 2.
Input Set Construction
Bug-Triggering Inputs: [1, 2, 3, 4, 5] Regression Inputs:[]
Consistency Evaluation & Selection Defect Consistency
Defect Descriptor(Ddesc)
Regression Consistency
Verified Ruby Buggy Code
Fig. 2. LRPL Dataset Construction.
pairs that faithfully reproduce the defect behaviors exhibited in HRPLs (§2.2). Figure 2 provides an overview of the workflow. 2.1
Translation of Fixed HRPL Programs
The goal of this stage is to map a fixed HRPL program 𝑃ℎ𝑟𝑝𝑙 to a target LRPL program 𝑃𝑙𝑟𝑝𝑙 . Unlike general code translation tasks, this process requires not only functional correctness but also the preservation of defect injection anchors necessary for subsequent injection. However, satisfying this dual requirement is challenging due to significant differences between languages. Taking HRPLs and typical LRPLs as examples, systemic differences in memory models, type systems, and control structures present two fundamental obstacles, corresponding to the first two challenges illustrated in Figure 1: Proc. ACM Softw. Eng., Vol. X, No. ISSTA, Article XX. Publication date: July 2026.
HELO-APR: Enhancing Low-Resource Program Repair through Cross-Lingual Knowledge Transfer
XX:5
Non-transferable Defects. Certain HRPL defects are rooted in features absent from the target languages, such as pointer arithmetic, manual memory management, or undefined behaviors in C++. Such defects cannot be reliably reproduced in LRPLs and must therefore be filtered out prior to the process. Idiomatic Structural Obscuration. Even for transferable defects, syntactic idioms in LRPLs can obscure the structures required for defect injection. For instance, some LRPLs provide higher-level abstractions, such as Ruby’s each and map iterators, instead of explicit control-flow constructs. LLMs tend to adopt these idioms during translation to improve readability, which can inadvertently eliminate explicit loop boundaries, index variables, or branching conditions that serve as critical “structural anchors” for defect injection. For example, translating a C-style loop (e.g., for (int i = 0; i < n; i++)) into a functional iterator preserves functional behavior but compromises the structural fidelity required for accurate defect injection. To address these challenges, we design a three-stage translation process: (1) Transferability Analysis: filters out HRPL defects reliant on non-transferable language features (e.g., pointer arithmetic) to ensure reproducibility in the target LRPL. (2) Structure-Constrained Translation: guides the LLM to preserve structural anchors required for defect injection within defect-relevant regions, thereby mitigating anchor loss caused by idiomatic abstraction. (3) Correctness Verification: validates the target code using automatically generated test cases to guarantee functional correctness. 2.1.1 Transferability Analysis. Prior to translation, it is essential to determine whether a specific defect in the source HRPL is reproducible in the target LRPL. To achieve this, we analyze the 𝑏𝑢𝑔𝑔𝑦 𝑓 𝑖𝑥𝑒𝑑 differences between the buggy version 𝑃𝑠𝑟𝑐 and the fixed version 𝑃𝑠𝑟𝑐 to extract key defect attributes. As shown in Figure 2, this process formalizes the defect into a concise descriptor: (1) 𝐷𝑑𝑒𝑠𝑐 = ⟨Type, RootCause, Δ𝑑𝑖 𝑓 𝑓 ⟩ Here, Type and RootCause represent the defect type and the underlying reason, respectively (e.g., “Off-by-one” and “Incorrect relational operator ‘<=’ ”). Crucially, Δ𝑑𝑖 𝑓 𝑓 denotes the Patch, capturing the exact code changes. Based on this descriptor, we employ an LLM to assess the transferability of the defect. The LLM evaluates whether the defect characteristics defined in Δ𝑑𝑖 𝑓 𝑓 are transferable to the target LRPLs. For instance, if Δ𝑑𝑖 𝑓 𝑓 contains pointer arithmetic or manual memory management specific to C++, the defect is deemed non-transferable and filtered out. Only defects rooted in language-agnostic logic proceed to the subsequent structure-constrained translation stage. 2.1.2 Structure-Constrained Translation. After identifying transferable cases, we translate the 𝑓 𝑖𝑥𝑒𝑑 𝑓 𝑖𝑥𝑒𝑑 correct HRPL version 𝑃𝑠𝑟𝑐 into the target LRPL program 𝑃𝑡𝑔𝑡 . Unlike traditional code translation, this task requires not only functional equivalence but also the preservation of structural anchors that are essential for subsequent defect injection. Consequently, we formulate the translation process as a structure-constrained translation task. Specifically, we employ an LLM to generate the target LRPL program. To ensure that the generated code supports subsequent defect injection, we utilize the patch Δ𝑑𝑖 𝑓 𝑓 within 𝐷𝑑𝑒𝑠𝑐 to distinguish between regions that require structural preservation and those where idiomatic adaptation is permitted. Accordingly, we implement two types of constraints based on the regions involved: • Defect-Related Regions (Δ𝑑𝑖 𝑓 𝑓 Scope): For code segments within Δ𝑑𝑖 𝑓 𝑓 , we prioritize preserving structural anchors required for defect injection over idiomatic rewriting. For example, when the fix involves a boundary condition (e.g., i < n), we preserve the corresponding Proc. ACM Softw. Eng., Vol. X, No. ISSTA, Article XX. Publication date: July 2026.
XX:6
Wang et al.
defect-controlling anchor. Refactoring into higher-level abstract iteration constructs is permitted only when the defect-controlling anchor can be explicitly retained; otherwise, such refactoring is avoided to prevent anchor loss. • Defect-Irrelevant Regions (Complement of Δ𝑑𝑖 𝑓 𝑓 ): For code segments outside Δ𝑑𝑖 𝑓 𝑓 , we allow idiomatic rewriting without structural constraints, since these parts do not trigger the defect. This improves the naturalness and readability of the translated code. 𝑓 𝑖𝑥𝑒𝑑
This strategy ensures that the generated 𝑃𝑡𝑔𝑡 retains the structural anchors essential for defect injection while maintaining overall code naturalness. Subsequently, we employ a test-driven verification process (§2.1.3) to screen for functionally correct translation candidates. 2.1.3 Correctness Verification. In this subsection, we verify the generated target program through a two-step process: 1) automated test generation, and 2) translation validation. This ensures the target program behaves consistently with the HRPL version. 𝑓 𝑖𝑥𝑒𝑑 (1) Automated Test Generation. Leveraging the correct HRPL program 𝑃𝑠𝑟𝑐 , we use a test generator 𝐺𝑡𝑒𝑠𝑡 to construct a test suite 𝑆𝑡𝑒𝑠𝑡 . The goal is to cover defect-relevant execution paths and mitigate the risk of “pseudo-equivalence” caused by insufficient testing. The workflow consists of two steps: (1) Test Case Generation: We prompt an LLM to generate diverse inputs based on the pro𝑓 𝑖𝑥𝑒𝑑 gram structure. For each input, we execute 𝑃𝑠𝑟𝑐 and record the program outputs, forming language-agnostic input-output pairs. (2) Quality Filtering: Generated test cases are filtered using coverage-based criteria. Following Cassano et al. [5], we require both line and branch coverage, measured by gcov (GCC), to exceed a threshold 𝜏 (set to 90%); test cases failing to meet this requirement are discarded. 𝑓 𝑖𝑥𝑒𝑑
𝑆𝑡𝑒𝑠𝑡 ⊆ 𝐺𝑡𝑒𝑠𝑡 (𝑃𝑠𝑟𝑐
),
Cov𝑙𝑖𝑛𝑒 (𝑆𝑡𝑒𝑠𝑡 ) ≥ 𝜏 ∧ Cov𝑏𝑟𝑎𝑛𝑐ℎ (𝑆𝑡𝑒𝑠𝑡 ) ≥ 𝜏 .
(2)
The filtered suite 𝑆𝑡𝑒𝑠𝑡 serves as the reference oracle for subsequent verification. (2) Translation Validation. We validate the translated program using 𝑆𝑡𝑒𝑠𝑡 . To improve robustness, we perform up to 𝑚 translation attempts. In each attempt 𝑗, the LLM produces a candidate program (𝑗) 𝑃𝑐𝑎𝑛𝑑 , which is executed on 𝑆𝑡𝑒𝑠𝑡 . We select the first candidate that passes all tests: (𝑗) 𝑗 ★ = min{ 𝑗 ∈ {1, . . . , 𝑚} | 𝑃𝑎𝑠𝑠 (𝑃𝑐𝑎𝑛𝑑 , 𝑆𝑡𝑒𝑠𝑡 ) },
2.2
𝑓 𝑖𝑥𝑒𝑑
𝑃𝑡𝑔𝑡
(𝑗 ) = 𝑃𝑐𝑎𝑛𝑑 . ★
(3)
Defect Injection into Translated Programs 𝑓 𝑖𝑥𝑒𝑑
𝑏𝑢𝑔𝑔𝑦
Given the verified target program 𝑃𝑡𝑔𝑡 , our objective is to construct a buggy counterpart 𝑃𝑡𝑔𝑡 whose observable behavior matches the defect behavior exhibited by the original HRPL program. Rather than replicating syntactic edits, we aim to preserve the defect’s behavioral manifestation in the LRPL. To this end, we generate defect candidates guided by the defect descriptor 𝐷𝑑𝑒𝑠𝑐 and evaluate them using defect behavior assessment. 2.2.1 Defect Injection. Guided by the defect type (𝑇𝑦𝑝𝑒), root cause (𝑅𝑜𝑜𝑡𝐶𝑎𝑢𝑠𝑒), and the patch 𝑓 𝑖𝑥𝑒𝑑 (Δ𝑑𝑖 𝑓 𝑓 ) contained in 𝐷𝑑𝑒𝑠𝑐 , we inject defects into the target program 𝑃𝑡𝑔𝑡 . Since the same defect logic can be implemented in multiple ways in the target language, we generate a set of candidate buggy programs: C = {𝑃1, 𝑃2, . . . , 𝑃𝑛 } (4) Each candidate 𝑃𝑖 ∈ C aims to reproduce the original defect behavior, while its correctness is determined through subsequent validation. Proc. ACM Softw. Eng., Vol. X, No. ISSTA, Article XX. Publication date: July 2026.
HELO-APR: Enhancing Low-Resource Program Repair through Cross-Lingual Knowledge Transfer
XX:7
2.2.2 Defect Behavior Assessment. After generating the candidate set C, we select the candidate that best reproduces the defect behavior of the original HRPL program while minimizing unintended regressions, evaluated along two complementary dimensions: defect consistency and regression consistency. (1) Defect Behavior Definition. We characterize each defect using a behavioral specification derived from the defect descriptor 𝐷𝑑𝑒𝑠𝑐 . Specifically, an LLM generates a structured defect behavior description: 𝐵 defect = ⟨TriggerCondition, ExpectedFailure⟩. (5) Here, TriggerCondition specifies the input conditions under which the defect is activated, and ExpectedFailure describes the expected observable failure pattern (e.g., crash, exception, or incorrect output). (2) Input Set Construction. Guided by 𝐵 defect , we use an LLM to generate test inputs that are likely to trigger or not trigger the defect, and execute each input on both the buggy and fixed HRPL programs to compare their observable behaviors. We then construct two disjoint input sets: • Bug-Triggering Inputs (𝑆 trigger ): inputs 𝑡 on which the buggy and fixed HRPL programs exhibit different observable behaviors, 𝑏𝑢𝑔𝑔𝑦
𝑆 trigger = { 𝑡 | 𝑃𝑠𝑟𝑐
𝑓 𝑖𝑥𝑒𝑑
(𝑡) ≠ 𝑃𝑠𝑟𝑐
(𝑡) },
(6)
indicating that the defect is activated under these inputs. • Regression Inputs (𝑆 reg ): inputs 𝑡 on which both versions exhibit identical observable behaviors, 𝑏𝑢𝑔𝑔𝑦
𝑆 reg = { 𝑡 | 𝑃𝑠𝑟𝑐
𝑓 𝑖𝑥𝑒𝑑
(𝑡) = 𝑃𝑠𝑟𝑐
(𝑡) }.
(7)
Bug-triggering inputs are essential for defect reproduction; if no input in 𝑆 trigger can be generated, the instance is discarded. Regression inputs are optional and may not exist for all instances. (3) Consistency Evaluation. For each candidate program 𝑃𝑖 ∈ C, we evaluate its behavior on the constructed input sets: • Defect Consistency. On bug-triggering inputs, the candidate is expected to exhibit a failure behavior consistent with ExpectedFailure. Since observable failure manifestations may differ across programming languages, we assess consistency using a behavioral equivalence relation rather than strict output equality. Specifically, two executions are considered equivalent if they exhibit the same failure category (e.g., crash, exception, or incorrect output). The defect consistency score is defined as: ∑︁ 𝑏𝑢𝑔𝑔𝑦 𝑁 defect (𝑃𝑖 ) = 1 𝑃𝑖 (𝑡) ≡ 𝑃𝑠𝑟𝑐 (𝑡) , (8) 𝑡 ∈𝑆 trigger
where ≡ denotes behavioral equivalence under the above failure criteria. • Regression Consistency. On regression inputs, the candidate is expected to preserve the correct 𝑓 𝑖𝑥𝑒𝑑 behavior of the fixed target program 𝑃𝑡𝑔𝑡 . We quantify regression consistency as: ∑︁ 𝑓 𝑖𝑥𝑒𝑑 𝑁 reg (𝑃𝑖 ) = 1 𝑃𝑖 (𝑡) = 𝑃𝑡𝑔𝑡 (𝑡) . (9) 𝑡 ∈𝑆 reg
(4) Final Selection. Since only candidates that successfully reproduce the defect behavior are meaningful, we rank candidates using a two-level criterion that prioritizes defect consistency and uses regression consistency as a secondary criterion. Formally, the final buggy program is selected as: 𝑏𝑢𝑔𝑔𝑦 𝑃𝑡𝑔𝑡 = arg max 𝑁 defect (𝑃𝑖 ), 𝑁 reg (𝑃𝑖 ) . (10) 𝑃𝑖 ∈ C
Proc. ACM Softw. Eng., Vol. X, No. ISSTA, Article XX. Publication date: July 2026.
XX:8
Wang et al.
STAGE 1: HRPL Repair Learning
STAGE 2: Cross-Lingual Repair Alignment Aligning repair behaviors via cross-lingual parallel data.
Acquiring strong repair capabilities from HRPLs. FROZEN Base Models
Adapting the model for independent LRPL repair. FROZEN Base Models
FROZEN Base Models
�
Fine-tuning Repair Adapter （Trainable）
Fine-tuning Repair Adapter （Trainable）
Fine-tuning with Data Training Data Format (Stage 1)
�
�
Fine-tuning Repair Adapter （Trainable）
### Instruction: Fix a buggy C++ program to solve ...
STAGE 3: LRPL Repair Adaptation
Fine-tuning with Data
Fine-tuning with Data Training Data Format (Stage 2)
Training Data Format (Stage 3) ### Instruction: Fix a buggy Ruby program to solve ...
### Input:
### Instruction: Fix a buggy Ruby program by referring to the corresponding C++ bug fix pair to solve ... ### Input:
### Response:
### Response:
### Response:
### Input:
Fig. 3. Three-stage curriculum learning framework of HELO-APR. The model is progressively trained via HRPL repair learning, cross-lingual repair alignment using parallel data, and LRPL repair adaptation. The backbone is frozen throughout training, and only repair adapters are fine-tuned to enable efficient and stable knowledge transfer.
3
Cross-Lingual Knowledge Transfer
Although the dataset construction framework in §2 mitigates the scarcity of high-quality LRPL buggy-fixed pairs, constructing verified LRPL training data remains costly. Under such strict data constraints, effectively transferring repair knowledge from HRPLs to LRPLs becomes critical. A naive solution is to directly fine-tune an LLM on the synthesized LRPL dataset. However, this approach is suboptimal, as it fails to exploit the semantic alignment between HRPL and LRPL programs and therefore underutilizes the rich repair supervision available in HRPLs. To address this limitation, we propose a three-stage curriculum learning framework that progressively transfers repair knowledge from HRPLs to LRPLs. The key intuition is to first establish robust repair reasoning in a high-resource setting, then explicitly align repair behaviors across languages using parallel buggy-fixed pairs, and finally adapt the model to independently perform LRPL repair. By decoupling semantic repair logic from language-specific syntax, this curriculum enables effective and stable cross-lingual knowledge transfer. The overall workflow is illustrated in Figure 3. 𝑏𝑢𝑔𝑔𝑦
𝑓 𝑖𝑥𝑒𝑑
Problem Formulation. Let D𝑠𝑟𝑐 = {(𝑃𝑠𝑟𝑐 , 𝑃𝑠𝑟𝑐 )} denote the HRPL buggy-fixed dataset, 𝑏𝑢𝑔𝑔𝑦 𝑓 𝑖𝑥𝑒𝑑 and let D𝑡𝑔𝑡 = {(𝑃𝑡𝑔𝑡 , 𝑃𝑡𝑔𝑡 )} denote the synthesized LRPL dataset. For instances where both HRPL and LRPL pairs are successfully constructed and verified, we form a parallel dataset D𝑝𝑎𝑟𝑎 = 𝑏𝑢𝑔𝑔𝑦 𝑓 𝑖𝑥𝑒𝑑 𝑏𝑢𝑔𝑔𝑦 𝑓 𝑖𝑥𝑒𝑑 {(𝑃𝑠𝑟𝑐 , 𝑃𝑠𝑟𝑐 , 𝑃𝑡𝑔𝑡 , 𝑃𝑡𝑔𝑡 )}. Let 𝜃 denote the trainable parameters of the repair adapters, while the backbone parameters are frozen throughout training. Training proceeds sequentially: parameters learned in Stage 𝑘 are used to initialize Stage 𝑘+1. Each stage minimizes a negative log-likelihood (NLL) objective defined on its corresponding dataset. Stage 1: HRPL Repair Learning. In the first stage, we train the repair adapters on HRPL repair data to learn strong repair reasoning in a high-resource setting. Specifically, the model is trained to Proc. ACM Softw. Eng., Vol. X, No. ISSTA, Article XX. Publication date: July 2026.
HELO-APR: Enhancing Low-Resource Program Repair through Cross-Lingual Knowledge Transfer 𝑏𝑢𝑔𝑔𝑦
XX:9 𝑓 𝑖𝑥𝑒𝑑
generate the fixed program given the buggy HRPL program (Input: 𝑃𝑠𝑟𝑐 → Output: 𝑃𝑠𝑟𝑐 ). This stage equips the model with general repair capabilities for complex semantic defects. However, due to strong coupling with HRPL-specific syntax, these capabilities exhibit limited transferability to LRPLs, motivating the subsequent alignment stage. The training objective is: 𝑓 𝑖𝑥𝑒𝑑 𝑏𝑢𝑔𝑔𝑦 Linit (𝜃 ) = −E (𝑃 𝑏𝑢𝑔𝑔𝑦 ,𝑃 𝑓 𝑖𝑥𝑒𝑑 )∼D log 𝑃𝜃 (𝑃𝑠𝑟𝑐 | 𝑃𝑠𝑟𝑐 ) . (11) 𝑠𝑟𝑐
𝑠𝑟𝑐
𝑠𝑟𝑐
Stage 2: Cross-Lingual Repair Alignment. The second stage explicitly aligns repair behaviors across languages using the parallel dataset D𝑝𝑎𝑟𝑎 . We adopt a demonstration-based fine-tuning strategy, in which the HRPL buggy-fixed pair serves as a repair demonstration for guiding LRPL repair. Concretely, the model is conditioned on the HRPL buggy code, its corresponding fix, and the 𝑏𝑢𝑔𝑔𝑦 𝑓 𝑖𝑥𝑒𝑑 𝑏𝑢𝑔𝑔𝑦 LRPL buggy code, and is trained to generate the LRPL fix (Input: 𝑃𝑠𝑟𝑐 , 𝑃𝑠𝑟𝑐 , 𝑃𝑡𝑔𝑡 → Output: 𝑓 𝑖𝑥𝑒𝑑
𝑃𝑡𝑔𝑡 ). This formulation encourages the transfer of repair knowledge while preventing direct copying of source-language syntax. The alignment objective is defined as: 𝑓 𝑖𝑥𝑒𝑑 𝑏𝑢𝑔𝑔𝑦 𝑓 𝑖𝑥𝑒𝑑 𝑏𝑢𝑔𝑔𝑦 Lalign (𝜃 ) = −E (𝑃 𝑏𝑢𝑔𝑔𝑦 ,𝑃 𝑓 𝑖𝑥𝑒𝑑 ,𝑃 𝑏𝑢𝑔𝑔𝑦 ,𝑃 𝑓 𝑖𝑥𝑒𝑑 )∼D log 𝑃𝜃 (𝑃𝑡𝑔𝑡 | 𝑃𝑠𝑟𝑐 , 𝑃𝑠𝑟𝑐 , 𝑃𝑡𝑔𝑡 ) . (12) 𝑠𝑟𝑐
𝑠𝑟𝑐
𝑡𝑔𝑡
𝑝𝑎𝑟𝑎
𝑡𝑔𝑡
Stage 3: LRPL Repair Adaptation. In the final stage, we adapt the model to the LRPL repair setting by fine-tuning the repair adapters exclusively on LRPL data, without any HRPL demonstrations. The model is trained to independently generate the fixed LRPL program given the buggy LRPL program 𝑏𝑢𝑔𝑔𝑦 𝑓 𝑖𝑥𝑒𝑑 (Input: 𝑃𝑡𝑔𝑡 → Output: 𝑃𝑡𝑔𝑡 ). This stage removes the model’s reliance on source-language context and enables direct application to LRPL repair tasks. The adaptation objective is: 𝑓 𝑖𝑥𝑒𝑑 𝑏𝑢𝑔𝑔𝑦 Ladapt (𝜃 ) = −E (𝑃 𝑏𝑢𝑔𝑔𝑦 ,𝑃 𝑓 𝑖𝑥𝑒𝑑 )∼D log 𝑃𝜃 (𝑃𝑡𝑔𝑡 | 𝑃𝑡𝑔𝑡 ) . (13) 𝑡𝑔𝑡
4 4.1
𝑡𝑔𝑡
𝑡𝑔𝑡
Evaluation Research Questions
We evaluate HELO-APR by answering the following research questions: RQ1 (Effectiveness): How effective is HELO-APR compared to existing baselines on low-resource program repair benchmarks? RQ2 (Dataset Construction): How do different components of the proposed dataset construction pipeline (i.e., Transferability Analysis, Structure-Constrained Translation & Injection, and Test-Driven Verification) contribute to the quality of the synthesized LRPL dataset? RQ3 (Cross-Lingual Knowledge Transfer): How does each stage in the proposed curriculum learning framework contribute to the final repair performance? RQ4 (Generalizability): How well does HELO-APR generalize to real-world software development scenarios? 4.2
Dataset
Dataset Overview. Our experiments involve three data sources serving distinct roles in the proposed approach. Specifically, we use (i) HRPL data from xCodeEval for synthesizing LRPL buggy-fixed training pairs, (ii) LRPL benchmarks from xCodeEval for controlled evaluation under low-resource settings, and (iii) a real-world LRPL dataset, Defects4Ruby [6], for external validation in practical software development scenarios. HRPL Source Data (xCodeEval) [12]. We select C++ as the HRPL due to the availability of abundant high-quality submissions. From the APR task of xCodeEval, we randomly sample 10,000 𝑏𝑢𝑔𝑔𝑦 𝑓 𝑖𝑥𝑒𝑑 C++ buggy-fixed pairs (𝑃𝑠𝑟𝑐 , 𝑃𝑠𝑟𝑐 ) from the training split. These pairs are used to translate Proc. ACM Softw. Eng., Vol. X, No. ISSTA, Article XX. Publication date: July 2026.
XX:10
Wang et al.
𝑓 𝑖𝑥𝑒𝑑
𝑏𝑢𝑔𝑔𝑦
𝑃𝑠𝑟𝑐 into LRPL and inject the defect derived from (𝑃𝑠𝑟𝑐 training pairs (§2).
𝑓 𝑖𝑥𝑒𝑑
, 𝑃𝑠𝑟𝑐
) to synthesize LRPL buggy-fixed
Controlled LRPL Benchmark (xCodeEval). To evaluate repair performance under controlled low-resource settings, we adopt the Compact Set of xCodeEval for two LRPLs: Ruby and Rust. This benchmark enables systematic comparison across methods under consistent problem settings. Real-World Evaluation Dataset (Defects4Ruby). To assess the generalizability of HELO-APR beyond contest-style benchmarks, we further conduct experiments on Defects4Ruby [6], a largescale collection of real-world Ruby buggy-fixed pairs mined from GitHub projects. This dataset is used solely for external validation. 4.3
Baselines
To evaluate the effectiveness of HELO-APR, we compare it against four baseline methods: (1) Zero-Shot Learning: The base LLM is prompted to repair buggy code directly without any parameter updates. This baseline reflects the model’s inherent capability on LRPLs[17]. (2) HRPLs-Only: The model is fine-tuned solely on the HRPL dataset and then evaluated on LRPL benchmarks. This baseline captures the performance achievable without leveraging any synthesized LRPL data[5]. (3) Wong et al.[20] : LRPL buggy code is first generated by the base model based on problem descriptions from the source data (HRPL). DeepSeek-V3.2-Chat is then employed to synthesize the corresponding repair rationales and fixed code. The model is subsequently fine-tuned on these verified buggy-fixed pairs. (4) LANTERN [14]: LANTERN is a multi-agent framework for cross-lingual program repair. For buggy LRPL programs that cannot be directly repaired, it translates them into a suitable HRPL selected by an LLM-based analyzer, performs repair in the target language, and back-translates successful fixes. Failed attempts are iteratively refined based on previous outputs. Unlike HELOAPR, it requires no additional training but incurs higher inference cost due to its multi-step pipeline. For a fair comparison, each iteration in LANTERN is treated as an independent inference step, ensuring a comparable inference budget with HELO-APR. 4.4
Evaluation Metrics
We employ two metrics to evaluate both the functional correctness and the syntactic validity of the generated patches. Pass@k. Following standard practice [14], we use Pass@k as the primary metric to evaluate repair performance. Pass@k measures the probability that at least one of the top-𝑘 generated patches passes all unit tests, and is computed using the unbiased estimator: " Pass@k :=
E
Problems
1−
𝑛−𝑐 𝑘 𝑛 𝑘
# ,
(14)
where 𝑛 is the number of generated candidates per problem, 𝑐 is the number of test-passing candidates under the ExecEval environment, and 𝑘 denotes the candidate budget. In our experiments, we set 𝑛 = 5 and report Pass@1, Pass@3, and Pass@5. Compilation Rate (CR). We use the compilation rate to assess the syntactic correctness of generated patches. It measures the percentage of top-1 generated patches that compile (for Rust) or parse successfully (for Ruby) in the ExecEval environment[12], independent of their functional correctness. Proc. ACM Softw. Eng., Vol. X, No. ISSTA, Article XX. Publication date: July 2026.
HELO-APR: Enhancing Low-Resource Program Repair through Cross-Lingual Knowledge Transfer
XX:11
Table 1. Main Results on xCodeEval. We report Pass@k (k=1, 3, 5), Target Compilation Rate (CR𝑇 ), and Source/C++ Compilation Rate (CR𝑆 ). High CR𝑆 indicates syntactic interference. Best results (for performance metrics) in each backbone are highlighted in bold. Ruby
Method P@1
P@3
P@5
Rust CR𝑇
CR𝑆
P@1
P@3
P@5
Average CR𝑇
CR𝑆
P@1
P@3
P@5
CR𝑇
CR𝑆
1.16 3.47 4.62 28.32 2.31 4.05 5.20 29.48 4.05 7.51 9.25 49.71 3.79 5.80 9.20 71.56 11.56 18.50 19.65 86.13
0.00 0.00 0.00 0.00 0.00
1.67 3.90 5.87 49.77 0.00 4.10 6.83 8.33 45.39 15.79 5.12 9.02 10.97 69.75 0.00 3.67 4.90 7.40 85.11 0.00 11.97 17.92 19.58 91.98 0.00
37.57 49.71 54.91 74.57 42.77 50.87 52.02 77.46 45.09 52.02 56.65 82.66 38.15 56.64 63.01 76.90 55.49 60.12 62.43 87.28
0.00 0.00 0.00 0.00 0.00
31.32 44.83 51.00 84.19 35.32 42.62 44.28 84.40 39.42 46.91 51.55 90.09 34.36 49.83 56.75 88.45 48.65 55.14 58.00 92.87
Backbone A: CodeLlama-7B-Instruct Zero-Shot 2.17 4.33 7.12 HRPLs-Only 5.88 9.60 11.46 Wong et al. 6.19 10.53 12.69 LANTERN 3.55 4.00 5.60 HELO-APR 12.38 17.34 19.50
71.21 0.00 61.30 31.58 89.78 0.00 98.66 0.00 97.83 0.00
Backbone B: DeepSeek-Coder-6.7B-Instruct Zero-Shot 24.77 38.08 43.65 92.88 HRPLs-Only 27.86 34.37 36.53 91.33 Wong et al. 33.75 41.80 46.44 97.52 LANTERN 30.56 43.00 50.50 100.00 HELO-APR 41.80 50.15 53.56 98.45
4.5
0.00 4.64 0.00 0.00 0.00
0.00 2.32 0.00 0.00 0.00
Implementation Details
Model Selection. For dataset construction (§2), DeepSeek-V3.2-Chat is used for translation and defect injection. Specifically, we generate 𝑚 = 5 candidates for structure-constrained translation, and similarly generate 𝑛 = 5 candidates for defect injection. For cross-lingual knowledge transfer (§3), we adopt two backbone models: CodeLlama-7B-Instruct and DeepSeek-Coder-6.7B-Instruct. Training Configuration. Models are fine-tuned with QLoRA, employing 4-bit NF4 quantization with double quantization enabled. The backbone parameters are frozen, and only LoRA adapters are fine-tuned. The LoRA rank is set to 𝑟 = 8 with 𝛼 = 16. Fine-tuning uses a global batch size of 32 and a maximum sequence length of 8192 tokens. The AdamW optimizer is applied with a learning rate of 1 × 10−4 and a learning rate schedule with 30 warmup steps. Inference and Evaluation. All evaluations use a temperature of 𝑇 = 1.0. For Pass@1, we report the top-1 sample under this setting, while for Pass@k (𝑘 > 1), multiple samples are drawn to estimate performance under larger candidate budgets. All generated patches are executed within the isolated ExecEval sandbox. Infrastructure. All experiments are conducted on a cluster equipped with 8 × NVIDIA A100 (40GB) GPUs. 5 5.1
Evaluation Results RQ1: Effectiveness
To evaluate the overall effectiveness of HELO-APR, we compare it against four representative baselines. We report Pass@k (𝑘 ∈ {1, 3, 5}) to assess repair success under different candidate budgets, together with target compilation rate (CR𝑇 ) and source-language compilation rate (CR𝑆 ) to quantify syntactic validity and cross-lingual syntactic interference. Table 1 presents the detailed results. The results demonstrate the superiority of HELO-APR in three key aspects: Proc. ACM Softw. Eng., Vol. X, No. ISSTA, Article XX. Publication date: July 2026.
XX:12
Wang et al.
(1) Superior Overall Effectiveness. As evidenced in Table 1, HELO-APR consistently outperforms all baselines across both target languages and backbone models. In terms of functional correctness (Pass@k), HELO-APR achieves substantial gains: on the CodeLlama backbone, it more than doubles the Pass@1 of the strongest baseline, Wong et al. (11.97% vs. 5.12%), and maintains a clear lead on DeepSeek-Coder (48.65% vs. 39.42%). This superiority extends to compilation rate (𝐶𝑅𝑇 ), where HELO-APR achieves near-perfect compilation rates (e.g., avg. 91.98% on CodeLlama), significantly surpassing LANTERN. (85.11%) and demonstrating robust repair capabilities under strict constraints. (2) Effective Mitigation of Cross-Lingual Syntactic Interference. Table 1 shows that HRPLsOnly suffers from syntax interference, while HELO-APR effectively mitigates this problem. First, HRPLs-Only fails to stop the source syntax from leaking. It has a high Source Compilation Rate (𝐶𝑅𝑆 ) of 31.58%, which means nearly one-third of the generated patches are actually C++ code. Correspondingly, its Target Compilation Rate (𝐶𝑅𝑇 ) drops to only 61.30%. In contrast, using the same source data, HELO-APR reduces 𝐶𝑅𝑆 to 0.00% and raises 𝐶𝑅𝑇 to 97.83%, which is higher than all other baselines. This indicates that HELO-APR fixes the interference issue: it learns the repair logic but strictly follows the target language rules. (3) Importance of High-Resource Reference Data. Comparing HELO-APR with Wong et al. highlights the value of using C++ (HRPL) data as a reference. Wong et al. relies on LLMs to generate buggy-fixed pairs from scratch, lacking the guidance of existing HRPL buggy-fixed pairs. In contrast, HELO-APR uses high-quality C++ pairs as a reference to synthesize the corresponding LRPL training data. This guidance leads to superior performance. For example, on the Ruby task (CodeLlama), HELO-APR achieves Pass@1/3/5 scores of 12.38%, 17.34%, and 19.50%, consistently outperforming Wong et al. (6.19%, 10.53%, and 12.69%). This comparison highlights the benefits of using HRPL buggy-fixed pairs as references: they provide stronger supervision than generating pairs from scratch and improve LRPL repair. (4) Advantage over Training-Free Translation Pipelines. Comparing HELO-APR with LANTERN highlights the advantage of training-based cross-lingual knowledge transfer over multi-agent translation pipelines. As shown in Table 1, HELO-APR consistently outperforms LANTERN across all metrics, especially on the CodeLlama backbone. This gap indicates that translation-based repair without targeted fine-tuning is insufficient for smaller open-source LLMs, as repair knowledge in the target language remains weak even after translation. In contrast, HELO-APR internalizes cross-lingual repair knowledge through curriculum-driven fine-tuning, leading to more accurate and stable LRPL repair. Meanwhile, although LANTERN requires no additional training, its iterative pipeline of translation, repair, and back-translation introduces significantly higher inference cost. Answer to RQ1 (1) HELO-APR consistently outperforms baselines across all Pass@k metrics (𝑘 = 1, 3, 5) while maintaining high Compilation Rates (e.g., 97.83% on Ruby with CodeLlama). (2) HELO-APR mitigates cross-lingual syntactic interference by eliminating source-language leakage (CR𝑆 reduced to 0.00%), in contrast to HRPLs-Only. (3) Leveraging HRPL buggy-fixed pairs yields stronger LRPL repair performance than Wong et al. (which generates buggy-fixed pairs from scratch), demonstrating the potential of leveraging HRPL data to improve LRPL repair. (4) Compared with the training-free multi-agent approach LANTERN, HELO-APR achieves consistently better repair performance while avoiding the high inference cost associated with iterative translation-based pipelines.
Proc. ACM Softw. Eng., Vol. X, No. ISSTA, Article XX. Publication date: July 2026.
HELO-APR: Enhancing Low-Resource Program Repair through Cross-Lingual Knowledge Transfer
5.2
XX:13
RQ2: LRPLs Dataset Construction
In this section, we investigate how different components of the proposed dataset construction pipeline contribute to the quality of the synthesized LRPL dataset. Specifically, we first analyze the individual impact of each pipeline component through controlled ablation studies (RQ2.1), and then conduct a focused quality analysis to interpret the observed performance differences (RQ2.2). 5.2.1 Contribution of Individual Pipeline Components (RQ2.1). To analyze the contribution of each component in the dataset construction, we compare HELO-APR with four ablated variants, each removing or modifying a specific functional module. Since dataset quality cannot be directly observed, we assess the contribution of each component indirectly through its downstream impact on repair performance under controlled training settings, following common practice in learningbased APR. Impact of Transferability Analysis. • w/o Transferability Analysis: This variant removes the transferability analysis. Instead of excluding samples whose defects rely on non-transferable language features (e.g., pointer arithmetic), it translates all samples without filtering. This ablation evaluates whether transferability analysis is necessary. Impact of Translation & Injection Strategy. HELO-APR applies structural constraints only to defect-related regions. To verify this design, we compare this strategy with two extreme approaches: one with no constraints and one with global structural constraints. • w/o Structure Constraints: This variant removes all structural constraints and simply prompts the LLM to translate the code and inject defects directly. • w/ Global Structure Constraints: This variant enforces structure constraints over the entire program by conservatively assuming that all code regions may contain defect injection anchors. As a result, any rewriting that could remove or obscure such anchors is globally suppressed, even in defect-irrelevant regions. Impact of Verification. • w/o Test Verification: This variant removes all verification steps, including Correctness Verification and Defect Behavior Assessment. This ablation evaluates the role of the verification phase in improving dataset quality. Results and Analysis: Table 2 presents the results of our ablation study. Performance is evaluated under two settings:(1) training exclusively on the synthesized data (Dataset-Only), and (2) continuing to apply the Cross-Language Knowledge Transfer pipeline (Full-Pipeline). The results confirm that each component of the proposed pipeline is essential. Impact of Transferability Analysis. Table 2 shows that the performance difference between the w/o Transferability Analysis variant and HELO-APR is marginal in the Dataset-Only setting. For instance, on Rust with the DeepSeek backbone under the Dataset-Only setting, the baseline performs comparably to HELO-APR (Pass@1: 44.51% vs. 45.09%). However, in the Full-Pipeline setting, this difference becomes substantially larger. Taking Rust as an example, HELO-APR clearly outperforms the baseline (Pass@1: 45.66% vs. 55.49%; Pass@5: 54.91% vs. 62.43%). This indicates that nontransferable defects introduce semantic noise that has a limited impact when learning LRPL repair patterns in isolation. However, during cross-lingual knowledge transfer, such noise interferes with the semantic alignment between HRPL-LRPL buggy-fixed pairs, significantly impairing alignment effectiveness. Therefore, filtering non-transferable defects is a critical prerequisite for effective cross-lingual repair knowledge transfer. Proc. ACM Softw. Eng., Vol. X, No. ISSTA, Article XX. Publication date: July 2026.
XX:14
Wang et al.
Table 2. Ablation Study on Data Construction Strategies. We evaluate the impact of Transferability Analysis, Translation & Injection Strategies, and Verification. Backbone A: CodeLlama-7B Strategy
Lang.
Dataset-Only
P@3
P@5
w/o Transferability Ruby Analysis Rust
9.91 6.36
14.24 15.48 11.56 12.72
10.53 15.17 17.03 7.51 12.14 13.29
33.44 42.72 46.13 44.51 50.87 52.60
37.77 46.13 48.30 45.66 51.45 54.91
Ruby Rust
8.67 6.36
12.38 14.24 10.40 11.56
10.84 16.72 18.27 8.09 13.29 14.45
32.82 40.87 45.20 43.35 48.55 52.02
38.08 47.68 49.23 49.71 55.49 57.23
w/ Global Structure Ruby Constraints Rust
8.05 5.78
12.69 13.62 8.67 9.83
8.98 9.83
14.86 17.65 9.83 10.40
25.39 34.06 36.84 32.95 41.04 45.66
31.58 41.80 43.34 46.24 51.45 52.02
w/o Test Verification
Ruby Rust
0.62 0.58
0.93 1.16
0.62 0.58
0.62 1.16
4.64 2.89
4.95 2.89
HELO-APR
Ruby Rust
10.22 15.17 16.72 12.38 17.34 19.50 8.09 12.14 13.87 11.56 18.50 19.65
0.93 1.73
P@1
P@3
5.57 3.47
P@5
Full-Pipeline
P@3
0.93 1.73
P@1
Dataset-Only
P@1
w/o Structure Constraints
P@5
Full-Pipeline
Backbone B: DeepSeek-Coder-6.7B
5.88 4.05
P@1
P@3
5.57 4.05
P@5
5.88 4.62
36.53 44.89 47.99 41.80 50.15 53.56 45.09 51.45 53.76 55.49 60.12 62.43
Impact of Translation & Injection Strategy. Table 2 reveals a clear performance hierarchy among translation strategies. HELO-APR consistently outperforms the w/o Structure Constraints baseline, which also significantly outperforms the w/ Global Structure Constraints variant. For example, on the DeepSeek-Ruby task under the Full-Pipeline setting, HELO-APR achieves 41.80% (Pass@1) and 53.56% (Pass@5), compared to 38.08% and 49.23% for the unconstrained approach and 31.58% and 43.34% for global structural constraints. These results indicate that selectively constraining defect-related regions is critical for synthesizing high-quality data, whereas enforcing global structural constraints is harmful. We further analyze this phenomenon using representative Ruby examples in §5.2.2. Impact of Verification. As shown in Table 2, removing the verification phase results in a catastrophic degradation of repair performance across all languages and backbones. For example, on CodeLlama-Ruby, Pass@1 drops to 0.62% and Pass@5 to 0.93%, while on Rust, the model becomes nearly ineffective (Pass@5: 1.73%); even with the stronger DeepSeek backbone, all Pass@k scores remain below 6%. This collapse stems from two complementary factors: without Correctness Verification, the synthesized training data frequently contains functionally invalid programs, causing the model to learn erroneous repair patterns; without Defect Behavior Assessment, mismatches between synthesized LRPL defects and their HRPL counterparts break the semantic alignment required for effective cross-lingual knowledge transfer.
Proc. ACM Softw. Eng., Vol. X, No. ISSTA, Article XX. Publication date: July 2026.
HELO-APR: Enhancing Low-Resource Program Repair through Cross-Lingual Knowledge Transfer
XX:15
Answer to RQ2.1 Each component of the LRPL dataset construction pipeline is critical to synthesizing high-quality training data: (1) Transferability Analysis filters out defects that cannot be reproduced in LRPLs. Without this step, non-transferable samples introduce semantic inconsistency between HRPL-LRPL pairs, significantly impairing cross-lingual knowledge transfer. (2) Structure-Constrained Translation & Injection applies constraints only to defect-related regions, which consistently leads to better repair performance than both w/o Structure Constraints and w/ Global Structure Constraints. (3) Test-Driven Verification serves as a necessary quality-control mechanism. Removing this step leads to a substantial performance degradation, as verification is essential for ensuring both functional correctness and defect consistency. 5.2.2 Interpreting Dataset Quality: Semantic Fidelity vs. Code Naturalness (RQ2.2). In §5.2.1, we observed a clear performance hierarchy among different dataset construction strategies: HELOAPR > w/o Structure Constraints > w/ Global Structure Constraints. To further characterize how the quality of the synthesized LRPL datasets varies across different construction strategies, we conduct a focused analysis along two complementary dimensions: Defect Semantic Fidelity and Code Naturalness. Metric 1: Defect Semantic Fidelity. This metric evaluates whether synthesized LRPL buggy-fixed pairs faithfully reproduce the defect semantics and execution behavior of their HRPL counterparts. We randomly sampled 500 instances from the generated corpora. Each sample was independently evaluated by three Ph.D. students proficient in Ruby using a 3-point ordinal scale: • Score 3 (High Fidelity): The synthesized pair precisely reproduces the defect logic and trigger conditions of the HRPL source, with an identical root cause. • Score 2 (Partial Fidelity): The synthesized pair preserves the defect type but deviates in trigger conditions or observable side effects. • Score 1 (No Fidelity): The synthesized pair fails to reproduce the intended defect, e.g., by being functionally correct, syntactically invalid, or exhibiting an unrelated defect. The final score for each sample was determined by majority agreement, and we report the average score for each strategy. Metric 2: Code Naturalness. This metric measures the extent to which synthesized code adheres to idiomatic conventions of the target language. We employ RuboCop, a widely adopted static analyzer for Ruby, focusing on the Style/* category, which comprises over 80 rules capturing stylistic and idiomatic consistency. We quantify code naturalness using Style Violation Density (SVD): SVD =
#(Style Cop Violations) × 1000 Total LOC
(15)
Lower SVD values indicate closer adherence to community-adopted Ruby idioms. Results and Analysis. Table 3 summarizes the evaluation results. Regarding Defect Semantic Fidelity, both HELO-APR (2.66) and w/ Global Structure Constraints (2.64) achieve substantially higher scores than the unconstrained strategy (2.24), indicating that introducing structural constraints helps preserve defect semantics during translation and defect injection. In contrast, Code Naturalness exhibits an opposite trend. Applying structural constraints globally results in a markedly higher SVD (89.52), suggesting that strict global preservation of source structure leads to non-idiomatic, source-language-biased Ruby code. By selectively constraining Proc. ACM Softw. Eng., Vol. X, No. ISSTA, Article XX. Publication date: July 2026.
XX:16
Wang et al.
Table 3. Comparison of defect semantic fidelity and code naturalness across different dataset construction strategies. Strategy
Semantic Fidelity ↑ Style Violation Density (SVD) ↓
w/o Structure Constraints w/ Global Structure Constraints HELO-APR
68.84 89.52 69.96
2.24 2.64 2.66
Table 4. Ablation study on different training stages. M2 examines the effect of removing HRPL Repair Learning (Stage 1), while M3 investigates the impact of removing Cross-Lingual Repair Alignment (Stage 2). M4 corresponds to the full HELO-APR curriculum. Ruby
Method
Rust
Average
P@1 (%) P@3 (%)
P@5 (%)
P@1 (%)
P@3 (%) P@5 (%)
P@1 (%)
P@3 (%) P@5 (%)
10.22 10.84 11.46 12.38
15.17 16.41 15.79 17.34
16.72 17.03 17.03 19.50
8.09 9.83 9.83 11.56
12.14 15.61 16.76 18.50
13.87 16.18 17.92 19.65
9.16 10.34 10.65 11.97
13.66 16.01 16.28 17.92
15.30 16.61 17.48 19.58
36.53 38.39 37.46 41.80
44.89 47.06 46.44 50.15
47.99 50.77 49.85 53.56
45.09 48.55 49.71 55.49
51.45 54.91 54.91 60.12
53.76 56.07 56.65 62.43
40.81 43.47 43.59 48.65
48.17 50.99 50.68 55.14
50.88 53.42 53.25 58.00
Backbone A: CodeLlama-7B M1: Direct Finetuning (S3 Only) M2: w/o HRPL Repair Learning (S2 → S3) M3: w/o Cross-Lingual Repair Alignment (S1 → S3) M4: HELO-APR (Full stages) Backbone B: DeepSeek-Coder-6.7B M1: Direct Finetuning (S3 Only) M2: w/o HRPL Repair Learning (S2 → S3) M3: w/o Cross-Lingual Repair Alignment (S1 → S3) M4: HELO-APR (Full stages)
only defect-related regions, HELO-APR maintains a low violation density (69.96), comparable to the unconstrained baseline (68.84), while retaining high semantic fidelity. Answer to RQ2.2 The performance differences observed in RQ2.1 can be explained by a trade-off between defect semantic fidelity and code naturalness: (1) Defect semantic fidelity. Introducing structural constraints helps preserve defect semantics during translation and defect injection. Accordingly, both HELO-APR and globally constrained translation achieve substantially higher fidelity scores than the unconstrained strategy. (2) Code naturalness. Applying structural constraints globally degrades code naturalness, producing non-idiomatic target-language code. By contrast, selectively constraining only defect-related regions allows HELO-APR to maintain code naturalness at a level comparable to unconstrained translation. (3) Overall trade-off. By balancing high semantic fidelity with high code naturalness, HELOAPR achieves the most favorable data quality, which explains its superior downstream repair performance. 5.3
RQ3: Impact of Cross-Language Knowledge Transfer
To investigate the impact of cross-language knowledge transfer and assess the necessity of each training stage in HELO-APR, we conduct a comprehensive ablation study. We design four experimental settings (M1-M4) that progressively remove individual stages from the proposed three-stage curriculum, disentangling the effects of HRPL Repair Learning (Stage 1), Cross-Lingual Repair Alignment (Stage 2), and LRPL Adaptation (Stage 3). Ablation Settings. Proc. ACM Softw. Eng., Vol. X, No. ISSTA, Article XX. Publication date: July 2026.
HELO-APR: Enhancing Low-Resource Program Repair through Cross-Lingual Knowledge Transfer
XX:17
• M1: Target-Only Baseline (S3 Only). The model is fine-tuned exclusively on the synthesized LRPL dataset (D𝑡𝑔𝑡 ), without any prior cross-language knowledge transfer. • M2: w/o HRPL Repair Learning (S2 → S3). This variant skips HRPL repair learning (Stage 1) and starts directly from cross-lingual repair alignment using parallel data (D𝑝𝑎𝑟𝑎 ), followed by LRPL adaptation. • M3: w/o Cross-Lingual Repair Alignment (S1 → S3). This variant performs sequential fine-tuning on HRPL data (D𝑠𝑟𝑐 ) and LRPL data (D𝑡𝑔𝑡 ), omitting the explicit alignment stage. • M4: HELO-APR (Full Pipeline). This setting employs the complete three-stage curriculum (S1 → S2 → S3) to fully enable cross-language knowledge transfer. To ensure a fair comparison across M1-M4, we adopt an early-stopping-based convergence criterion instead of a fixed training schedule. This design prevents bias caused by under- or overtraining and ensures that observed performance differences primarily reflect the effectiveness of different curriculum strategies. The quantitative results are summarized in Table 4. Overall Impact of Cross-Language Knowledge Transfer. As shown in Table 4, the full model M4 (HELO-APR) consistently achieves the best performance across all backbones and evaluation metrics. For example, with the DeepSeek-Coder-6.7B backbone, M4 attains an average Pass@1 of 48.65%, substantially outperforming the target-only baseline M1 (40.81%). This consistent improvement across different 𝑘 values indicates that the proposed curriculum effectively enhances the model’s ability to retrieve correct fixes under limited and extended candidate budgets. Effect of HRPL Repair Learning (Stage 1). Comparing M2 with the full model M4, we observe a consistent performance degradation when HRPL repair learning is removed. On DeepSeek-Coder6.7B, omitting Stage 1 results in a drop of 5.18% in Pass@1 and a noticeable reduction in Pass@5. Similar trends are observed with the CodeLlama backbone. These results indicate that HRPL repair learning provides a necessary foundation of general repair capabilities; without this stage, the model lacks sufficient repair knowledge to fully benefit from subsequent training. Effect of Cross-Lingual Repair Alignment (Stage 2). The results for M3 further highlight the critical role of explicit cross-lingual alignment. Despite being trained on abundant HRPL data, models without Stage 2 exhibit a substantial performance drop. For instance, removing this stage reduces Pass@1 by 5.06% on DeepSeek-Coder-6.7B. This finding suggests that HRPL repair knowledge alone is insufficient for effective LRPL repair. By explicitly aligning repair behaviors across languages using parallel buggy-fixed pairs, Stage 2 enables the model to transfer learned repair capabilities into the target language, thereby substantially improving repair performance. Answer to RQ3 Our ablation study demonstrates that effective cross-language knowledge transfer requires a carefully designed multi-stage curriculum. (1) HRPL Repair Learning (Stage 1) provides a necessary foundation of general repair knowledge but is not sufficient on its own for effective LRPL repair. (2) Cross-Lingual Repair Alignment (Stage 2) plays a pivotal role by explicitly aligning repair behaviors across languages, enabling HRPL repair knowledge to be effectively realized in LRPLs. (3) Combining both stages with LRPL adaptation yields the best performance across all backbones and metrics, confirming that cross-language knowledge transfer is maximized only under the full curriculum. Proc. ACM Softw. Eng., Vol. X, No. ISSTA, Article XX. Publication date: July 2026.
XX:18
Wang et al.
Table 5. Generalization results on a randomly sampled subset (1000 instances) of Defects4Ruby. We report BLEU-4 and ROUGE-1 for real-world Ruby program repair. Best results for each metric and backbone are highlighted in bold.
Method Zero Shot HELO-APR
5.4
CodeLlama-7B
DeepSeek-Coder-6.7B
BLEU-4
ROUGE-1
BLEU-4
ROUGE-1
61.20 66.79
76.76 83.59
58.13 73.93
71.70 87.60
RQ4: Generalizability to Real-World Development Scenarios
To evaluate whether repair knowledge learned through cross-lingual training generalizes beyond synthetic benchmarks, we assess HELO-APR on real-world Ruby bugs from Defects4Ruby. Unlike xCodeEval, this benchmark consists of bugs written and fixed by human developers, reflecting realistic development scenarios. We randomly sample 1000 buggy-fixed pairs for evaluation and compare the base model against the same backbone fine-tuned with HELO-APR. Following common practice on Defects4Ruby, we adopt text-based similarity metrics, including BLEU-4 and ROUGE-1, to measure the overlap between generated patches and developer-written fixes. All experiments are conducted with two backbones: CodeLlama-7B and DeepSeek-Coder-6.7B. As shown in Table 5, HELO-APR consistently outperforms the Zero-Shot baseline on Defects4Ruby across both backbones. In particular, it improves BLEU-4 and ROUGE-1 on CodeLlama7B (61.20→66.79, 76.76→83.59) and achieves larger gains on DeepSeek-Coder-6.7B (58.13→73.93, 71.70→87.60). These results indicate that patches generated by HELO-APR exhibit higher textual overlap and stylistic proximity to developer-written fixes. Although text-based similarity metrics do not directly measure functional correctness, the consistent improvements provide supportive external evidence that cross-lingual repair knowledge leads to outputs better aligned with the textual and stylistic characteristics of real-world patches. Answer to RQ4 On Defects4Ruby, HELO-APR consistently outperforms the Zero-Shot baseline on text-based similarity metrics across both backbones. This provides supportive external evidence that crosslingual repair knowledge improves the alignment between generated patches and developerwritten fixes in real-world settings. 6
Threats to Validity
Internal Validity. Internal validity concerns whether the observed improvements can be attributed to HELO-APR rather than experimental confounders. Different curriculum variants may converge at different rates; under a fixed training schedule, some variants may underfit while others overfit, potentially biasing performance comparisons. To mitigate this risk, we adopt an early-stoppingbased convergence criterion for all variants, ensuring evaluation near their respective convergence points and reducing the influence of training-time differences. In addition, the results may be influenced by the choice of model scale as part of the experimental setting. Our experiments are conducted on 7B-scale models, and the effectiveness of HELO-APR on larger models has not yet been validated, which may limit the generalizability of our findings. Proc. ACM Softw. Eng., Vol. X, No. ISSTA, Article XX. Publication date: July 2026.
HELO-APR: Enhancing Low-Resource Program Repair through Cross-Lingual Knowledge Transfer
XX:19
Nevertheless, 7B models are representative in efficiency-sensitive and deployment-constrained scenarios, and thus our results still carry practical significance. External Validity. External validity concerns the extent to which our findings extend beyond xCodeEval, whose competition-based data distribution differs from real-world software development. To provide external evidence beyond synthetic benchmarks, we directly evaluate models trained on xCodeEval on Defects4Ruby without additional fine-tuning. Although this evaluation relies on text-based similarity metrics rather than functional correctness, the consistent improvements indicate that HELO-APR produces patches more closely aligned with developer-written fixes in real-world settings. 7 7.1
Related Work LLM-Based Program Repair
LLMs have significantly advanced APR, leading to successive paradigm shifts [10, 27, 29, 34]. Early work formulated APR as conditional sequence generation using NMT-style or clozing-style models [9], exemplified by TFix [3], VulRepair [7], and AlphaRepair [22]. More recent approaches adopt conversational repair, enabling iterative reasoning over bugs and patches via natural language interaction [13, 23]. Building on this trend, agentic APR further leverages multiple LLM agents to collaboratively perform localization, patch generation, and validation [1, 4, 16, 24, 28, 35]. Despite these advances, LLM-driven APR research has largely focused on high-resource programming languages [33]. For low-resource programming languages (LRPLs) such as Kotlin, Ruby, and PHP, APR remains underexplored, and the scarcity of high-quality parallel buggy-fixed corpora further limits the applicability of state-of-the-art LLM-based repair techniques [11, 32]. 7.2
Program Repair for LRPLs
APR for LRPLs is mainly constrained by the scarcity of high-quality buggy–fixed corpora [14, 33]. Existing work addresses this limitation from several directions. Some approaches transfer repair knowledge by directly fine-tuning on HRPL corpora or multilingual code models, but often suffer from syntactic interference [2]. Others leverage LLMs to synthesize buggy–fixed pairs for data augmentation [20], though the generated defects are frequently shallow or unreliable. Related work combines cross-language code translation with downstream repair to reuse HRPL repair capabilities, but this pipeline heavily depends on translation quality and is less effective for relatively small, open-source LLMs [14]. In addition, meta-learning-based methods support few-shot adaptation to LRPL defects, yet still require a non-trivial amount of labeled LRPL data [18]. In contrast, HELO-APR transfers repair knowledge from HRPLs to LRPLs in a more reliable manner. It constructs cross-lingual parallel buggy–fixed pairs via a principled LRPL data generation strategy and employs a curriculum learning–based cross-lingual knowledge transfer pipeline with an explicit repair alignment stage, enabling more robust knowledge transfer to LRPLs. 8
Conclusion
This paper presents HELO-APR, a two-stage cross-lingual supervision framework that converts abundant HRPL repair signals into verified LRPL training data and transfers them via curriculum fine-tuning. On xCodeEval with C++ as the source HRPL and Ruby and Rust as the target LRPLs, HELO-APR improves average Pass@1 from 31.32% to 48.65% on DeepSeek-Coder-6.7B and from 1.67% to 11.97% on CodeLlama-7B. It also strengthens syntactic validity by raising the average target compilation rate on CodeLlama from 49.77% to 91.98%, reflecting substantially reduced cross-lingual syntactic interference. On Defects4Ruby, HELO-APR produces patches with higher textual similarity to developer-written fixes, increasing BLEU-4 from 61.20 to 66.79 and ROUGE-1 Proc. ACM Softw. Eng., Vol. X, No. ISSTA, Article XX. Publication date: July 2026.
XX:20
Wang et al.
from 76.76 to 83.59 on CodeLlama-7B. These results suggest that verified cross-lingual supervision can serve as a scalable recipe for unlocking LLM repair capabilities in low-resource settings. The same principle may extend beyond APR to other code tasks where target-language supervision is scarce, by synthesizing and validating task-specific cross-lingual training signals and explicitly aligning behaviors across languages. References [1] Antonis Antoniades, Albert Örwall, Kexun Zhang, Yuxi Xie, Anirudh Goyal, and William Wang. 2025. SWE-Search: Enhancing Software Agents with Monte Carlo Tree Search and Iterative Refinement. arXiv:2410.20285 [cs.AI] https://arxiv.org/abs/2410.20285 [2] Razan Baltaji, Saurabh Pujar, Martin Hirzel, Louis Mandel, Luca Buratti, and Lav R Varshney. 2025. Cross-lingual Transfer in Programming Languages: An Extensive Empirical Study. Transactions on Machine Learning Research (2025). [3] Berkay Berabi, Jingxuan He, Veselin Raychev, and Martin Vechev. 2021. Tfix: Learning to fix coding errors with a text-to-text transformer. In International Conference on Machine Learning. PMLR, 780–791. [4] Islem Bouzenia, Premkumar Devanbu, and Michael Pradel. 2024. RepairAgent: An Autonomous, LLM-Based Agent for Program Repair. arXiv:2403.17134 [cs.SE] https://arxiv.org/abs/2403.17134 [5] Federico Cassano, John Gouwar, Francesca Lucchetti, Claire Schlesinger, Anders Freeman, Carolyn Jane Anderson, Molly Q Feldman, Michael Greenberg, Abhinav Jangda, and Arjun Guha. 2024. Knowledge transfer from high-resource to low-resource programming languages for code llms. Proceedings of the ACM on Programming Languages 8, OOPSLA2 (2024), 677–708. [6] Meghdad Dehghan, Mohammadreza Saeidi, Rohit Dandamudi, Jie JW Wu, Fatemeh H Fard, and Gema Rodrıguez-Pérez. 2025. Defects4Ruby: Benchmarking and Analyzing Bug Detection and Repair for Ruby Using Language Models. https://jie-jw-wu.github.io/assets/ICPC_2025_RENE.pdf [7] Michael Fu, Chakkrit Tantithamthavorn, Trung Le, Van Nguyen, and Dinh Phung. 2022. VulRepair: a T5-based automated software vulnerability repair. In Proceedings of the 30th ACM joint european software engineering conference and symposium on the foundations of software engineering. 935–947. [8] Soneya Binta Hossain, Nan Jiang, Qiang Zhou, Xiaopeng Li, Wen-Hao Chiang, Yingjun Lyu, Hoan Nguyen, and Omer Tripp. 2024. A deep dive into large language models for automated bug localization and repair. Proceedings of the ACM on Software Engineering 1, FSE (2024), 1471–1493. [9] Jinru Hua, Mengshi Zhang, Kaiyuan Wang, and Sarfraz Khurshid. 2018. Towards practical program repair with on-demand candidate generation. In Proceedings of the 40th international conference on software engineering. 12–23. [10] Nan Jiang, Thibaud Lutellier, and Lin Tan. 2021. Cure: Code-aware neural machine translation for automatic program repair. In 2021 IEEE/ACM 43rd International Conference on Software Engineering (ICSE). IEEE, 1161–1173. [11] Sathvik Joel, Jie Wu, and Fatemeh Fard. 2024. A survey on llm-based code generation for low-resource and domainspecific programming languages. ACM Transactions on Software Engineering and Methodology (2024). [12] Mohammad Abdullah Matin Khan, M Saiful Bari, Xuan Long Do, Weishi Wang, Md Rizwan Parvez, and Shafiq Joty. 2023. xcodeeval: A large scale multilingual multitask benchmark for code understanding, generation, translation and retrieval. arXiv preprint arXiv:2303.03004 (2023). [13] Jiaolong Kong, Mingfei Cheng, Xiaofei Xie, Shangqing Liu, Xiaoning Du, and Qi Guo. 2024. Contrastrepair: Enhancing conversation-based automated program repair via contrastive test case pairs. arXiv preprint arXiv:2403.01971 (2024). [14] Wenqiang Luo, Jacky Wai Keung, Boyang Yang, Jacques Klein, Tegawende F Bissyande, Haoye Tian, and Bach Le. 2025. Unlocking LLM Repair Capabilities in Low-Resource Programming Languages Through Cross-Language Translation and Multi-Agent Refinement. arXiv preprint arXiv:2503.22512 (2025). [15] Wenqiang Luo, Jacky Wai Keung, Boyang Yang, He Ye, Claire Le Goues, Tegawende F Bissyande, Haoye Tian, and Bach Le. 2026. When fine-tuning llms meets data privacy: An empirical study of federated learning in llm-based program repair. ACM Transactions on Software Engineering and Methodology 35, 3 (2026), 1–46. [16] Yingwei Ma, Qingping Yang, Rongyu Cao, Binhua Li, Fei Huang, and Yongbin Li. 2025. Alibaba lingmaagent: Improving automated issue resolution via comprehensive repository exploration. In Proceedings of the 33rd ACM International Conference on the Foundations of Software Engineering. 238–249. [17] Farhad Pourpanah, Moloud Abdar, Yuxuan Luo, Xinlei Zhou, Ran Wang, Chee Peng Lim, Xi-Zhao Wang, and QM Jonathan Wu. 2022. A review of generalized zero-shot learning methods. IEEE transactions on pattern analysis and machine intelligence 45, 4 (2022), 4051–4070. [18] Weishi Wang, Yue Wang, Steven Hoi, and Shafiq Joty. 2023. Towards low-resource automatic program repair with meta-learning and pretrained language models. In Proceedings of the 2023 Conference on Empirical Methods in Natural Language Processing. 6954–6968.
Proc. ACM Softw. Eng., Vol. X, No. ISSTA, Article XX. Publication date: July 2026.
HELO-APR: Enhancing Low-Resource Program Repair through Cross-Lingual Knowledge Transfer
XX:21
[19] Zhipeng Wang, Tieke He, Ruoyu Zhao, and Tao Zheng. 2025. Exploration and Improvement of Capabilities of LLMs in Code Refinement Task. International Journal of Software & Informatics 15, 2 (2025). [20] Kyle Wong, Alfonso Amayuelas, Liangming Pan, and William Yang Wang. 2025. Investigating the transferability of code repair for low-resource programming languages. In Findings of the Association for Computational Linguistics: NAACL 2025. 3410–3432. [21] Chunqiu Steven Xia, Yuxiang Wei, and Lingming Zhang. 2023. Automated program repair in the era of large pre-trained language models. In 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE). IEEE, 1482–1494. [22] Chunqiu Steven Xia and Lingming Zhang. 2022. Less training, more repairing please: revisiting automated program repair via zero-shot learning. In Proceedings of the 30th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering. 959–971. [23] Chunqiu Steven Xia and Lingming Zhang. 2024. Automated program repair via conversation: Fixing 162 out of 337 bugs for $0.42 each using ChatGPT. In Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis. 819–831. [24] Boyang Yang, Zijian Cai, Fengling Liu, Bach Le, Lingming Zhang, Tegawendé F Bissyandé, Yang Liu, and Haoye Tian. 2025. A Survey of LLM-based Automated Program Repair: Taxonomies, Design Paradigms, and Applications. arXiv preprint arXiv:2506.23749 (2025). [25] Boyang Yang, Haoye Tian, Weiguo Pian, Haoran Yu, Haitao Wang, Jacques Klein, Tegawendé F Bissyandé, and Shunfu Jin. 2024. Cref: An llm-based conversational software repair framework for programming tutors. In Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis. 882–894. [26] Boyang Yang, Haoye Tian, Jiadong Ren, Hongyu Zhang, Jacques Klein, Tegawende Bissyande, Claire Le Goues, and Shunfu Jin. 2025. Morepair: Teaching llms to repair code via multi-objective fine-tuning. ACM Transactions on Software Engineering and Methodology (2025). [27] John Yang, Carlos E Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan, and Ofir Press. 2024. Swe-agent: Agent-computer interfaces enable automated software engineering. Advances in Neural Information Processing Systems 37 (2024), 50528–50652. [28] He Ye, Aidan ZH Yang, Chang Hu, Yanlin Wang, Tao Zhang, and Claire Le Goues. 2025. Adversarial Reasoning for Repair Based on Inferred Program Intent. arXiv preprint arXiv:2505.13008 (2025). [29] Mingyue Yuan, Jieshan Chen, Zhenchang Xing, Aaron Quigley, Yuyu Luo, Tianqi Luo, Gelareh Mohammadi, Qinghua Lu, and Liming Zhu. 2024. DesignRepair: Dual-Stream Design Guideline-Aware Frontend Repair with Large Language Models. arXiv preprint arXiv:2411.01606 (2024). [30] Wei Yuan, Quanjun Zhang, Tieke He, Chunrong Fang, Nguyen Quoc Viet Hung, Xiaodong Hao, and Hongzhi Yin. 2022. CIRCLE: Continual repair across programming languages. In Proceedings of the 31st ACM SIGSOFT international symposium on software testing and analysis. 678–690. [31] Jialu Zhang, José Pablo Cambronero, Sumit Gulwani, Vu Le, Ruzica Piskac, Gustavo Soares, and Gust Verbruggen. 2024. Pydex: Repairing bugs in introductory python assignments using llms. Proceedings of the ACM on Programming Languages 8, OOPSLA1 (2024), 1100–1124. [32] Jipeng Zhang, Jianshu Zhang, Yuanzhe Li, Renjie Pi, Rui Pan, Runtao Liu, Zheng Ziqiang, and Tong Zhang. 2025. Bridge-Coder: Transferring Model Capabilities from High-Resource to Low-Resource Programming Language. In Findings of the Association for Computational Linguistics: ACL 2025. 10865–10882. [33] Quanjun Zhang, Chunrong Fang, Yuxiang Ma, Weisong Sun, and Zhenyu Chen. 2023. A survey of learning-based automated program repair. ACM Transactions on Software Engineering and Methodology 33, 2 (2023), 1–69. [34] Quanjun Zhang, Chunrong Fang, Weisong Sun, Yan Liu, Tieke He, Xiaodong Hao, and Zhenyu Chen. 2024. Appt: Boosting automated patch correctness prediction via fine-tuning pre-trained models. IEEE Transactions on Software Engineering 50, 3 (2024), 474–494. [35] Yuntong Zhang, Haifeng Ruan, Zhiyu Fan, and Abhik Roychoudhury. 2024. Autocoderover: Autonomous program improvement. In Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis. 1592–1604.
Proc. ACM Softw. Eng., Vol. X, No. ISSTA, Article XX. Publication date: July 2026.