CURE: Code-Aware Neural Machine Translation for Automatic Program Repair

Abstract

Automatic program repair (APR) is crucial to improve software reliability. Recently, neural machine translation (NMT) techniques have been used to fix software bugs automatically. While promising, these approaches have two major limitations. Their search space often does not contain the correct fix, and their search strategy ignores software knowledge such as strict code syntax. Due to these limitations, existing NMT-based techniques underperform the best template-based approaches. We propose CURE, a new NMT-based APR technique with three major novelties. First, CURE pre-trains a programming language (PL) model on a large software codebase to learn developer-like source code before the APR task. Second, CURE designs a new code-aware search strategy that finds more correct fixes by focusing on compilable patches and patches that are close in length to the buggy code. Finally, CURE uses a subword tokenization technique to generate a smaller search space that contains more correct fixes.Our evaluation on two widely-used benchmarks shows that CURE correctly fixes 57 Defects4J bugs and 26 QuixBugs bugs, outperforming all existing APR techniques on both benchmarks.

Beep: Fine-grained Fix Localization by Learning to Predict Buggy Code Elements

“…We provide in Table 6 the performance of our repair pipelines on the four defect benchmarks. We also compare their performance against the results of 26 APR techniques reported in recent literature [28]. Due to space limitation, we only include in this Overall, we find that our pipelines can both achieve 100% precision: all generated patches that passed the test suite were found to be correct.…”

“…Because the performance of fault localization can severely impact repair performance [52], researchers act on this step to improve the pipeline: e.g., ACS [96] uses predicate switching [103] while SimFix [27] applies a test case purification approach [98] to refine the fault localization results, respectively. In recent works [28,60], the assessment of the actual patch generation step of APR has been done by assuming that the fault localization at the line is perfect. Nevertheless, even in such cases, the patch generation is challenged since it often partially touches the relevant code elements [51].…”

“…To assess the correctness of APR-generated patches, we adopt the open patch correctness assessment rules provided by Liu et al [55], where 15 rules are explicitly defined to illustrate how to identify an APR-generated patch as correct when comparing it with the ground-truth develop-written patch provided in benchmark datasets. Such rules are publicly available at https://github.com/TruX-DTF/APR-Efficiency and are widely used in the patch correctness validation of APR works [28,60,82,86,99].…”

“…➤ SequenceR [19], DLFix [46], CoCoNut [60], and CURE [28] work at the line level, thus requiring as input the exact buggy statement, an information granularity that current fault localization inaccurately provides. In contrast, our repair pipeline only targets buggy methods, a granularity that is more accessible to off-the-shelf fault localization tools [12,59].…”

A Quick Repair Facility for Debugging

“…Finally, they validate the patches to identify those that yield repaired programs passing the test suite and are promising to be correct. Current techniques differ primarily in patch generation step using various approaches based on genetic programming [38], repair patterns (e.g., [44]), search (e.g., [3,27,76,82]), conditional synthesis (e.g., [47,84]), program state analysis [13], bytecode mutation [20], and machine learning (e.g., [14,28,40]). ROSE's repair generation is based on a combination of efficient prior approaches based on patterns [44], search [80], and machine learning [14].…”