PaperlayerView exact revision on arXiv

Source-linked AI summary

A Survey on Automated Program Repair Techniques

Kai Huang, Zhengzi Xu, Su Yang, Hongyu Sun, Xuejun Li, Zheng Yan, Yuqing Zhang

arXiv:2303.18184v3cs.SE

TL;DR

Software defects make repair a costly and time-consuming part of software maintenance, while prior APR surveys have not covered many recent data-driven advances. This survey traces APR through four patch-generation approaches and compares tools using common criteria. It summarizes trade-offs among approaches and discusses challenges and future opportunities, including LLMs and further empirical study.

  • Problem

    Software defects require tedious, complex repair, and prior APR surveys have not yet covered many recent data-driven advances.

    Source: §1 · p. 2

  • Method

    The survey organizes APR by four patch-generation approaches, proposes common criteria for comparing tools, and reviews related research, challenges, and directions.

    Source: §1 · p. 2, §8 · p. 46

  • Results

    The survey describes trade-offs: templates target specific defect classes, while learning-based approaches offer flexibility across languages and defect types but retain limitations.

    Source: §5.5.1 · pp. 20, 22

  • Takeaways & Limitations

    The authors highlight LLM opportunities for APR and the importance of more empirical studies in future research.

    Source: §8 · p. 46

    Current neural networks struggle with long sequences, and out-of-vocabulary issues limit learning-based APR capabilities.

    Source: §5.4.4 · p. 20

Abstract

from arXiv · show

With the rapid development and large-scale popularity of program software, modern society increasingly relies on software systems. However, the problems exposed by software have also come to the fore. Software defect has become an important factor troubling developers. In this context, Automated Program Repair (APR) techniques have emerged, aiming to automatically fix software defect problems and reduce manual debugging work. In particular, benefiting from the advances in deep learning, numerous learning-based APR techniques have emerged in recent years, which also bring new opportunities for APR research. To give researchers a quick overview of APR techniques' complete development and future opportunities, we revisit the evolution of APR techniques and discuss in depth the latest advances in APR research. In this paper, the development of APR techniques is introduced in terms of four different patch generation schemes: search-based, constraint-based, template-based, and learning-based. Moreover, we propose a uniform set of criteria to review and compare each APR tool, summarize the advantages and disadvantages of APR techniques, and discuss the current state of APR development. Furthermore, we introduce the research on the related technical areas of APR that have also provided a strong motivation to advance APR development. Finally, we analyze current challenges and future directions, especially highlighting the critical opportunities that large language models bring to APR research.

1 INTRODUCTION

Software defects make repair a costly, persistent part of software maintenance, while recent data-driven advances are not fully covered by prior APR surveys. This survey revisits APR’s development, offers a taxonomy and comparison criteria, and discusses current challenges and future directions.

1 INTRODUCTION

  • Software defects persist across the lifecycle and make repair a tedious, complex task for engineers.The introduction cites substantial harm from software failures and reports an estimated $2.08 trillion U.S. cost of poor software quality in 2020.Source: §1 · p. 2
  • Prior surveys have not covered many recent data-driven advances, motivating this survey’s focus on deep learning and current APR research.The authors also propose criteria for comparing APR tools across multiple dimensions.Source: §1 · p. 2
  • The survey classifies APR by patch-generation scheme into search-based, constraint-based, template-based, and learning-based approaches.It reviews the approaches in time order and discusses learning-based techniques across bug, error, and vulnerability repair.Source: §1 · p. 2
  • The survey identifies issues including unfair experimental comparisons, dataset overlap and quality, and challenges for industrial APR applications.It highlights LLM opportunities and the need for more empirical studies.Source: §1 · p. 3

2 PAPER SELECTION

The authors assembled APR papers from community and literature collections, supplemented by a 2022 search, then manually selected representative works. The final selection emphasizes recent data-driven research and is bounded by page limits and possible omissions.

2 PAPER SELECTION

  • The authors searched APR community and literature collections, then supplemented them with 2022 searches of Google Scholar, DBLP, and arXiv.They focused mainly on papers published up to December 2022 and removed duplicates across the sources.Source: §2 · p. 3
  • They excluded papers of six pages or fewer, then manually selected representative works to illustrate APR technique characteristics or development trends.The authors note that page limits and possible omissions from manual review mean the survey cannot cover every typical work.Source: §2 · p. 3
  • The survey retained more data-driven works because prior surveys had reviewed traditional APR techniques, ultimately selecting 140 works.The selection forms the main body of the survey.Source: §2 · p. 4

3 APR GENERAL PROCESS

The paper describes APR as a pipeline that takes a defective program and produces one or more candidate patches. Its taxonomy focuses on patch-generation techniques, while fault localization and patch validation have distinct roles in the process.

3 APR GENERAL PROCESS

  • APR commonly proceeds through fault localization, patch generation, and patch validation, taking a defective program as input and producing candidate patches.The paper uses “defect” broadly to include bug, error, fault, and vulnerability.Source: §3 · p. 4
  • Fault localization identifies potential defect locations, often by reusing existing FL tools or methods.These locations guide APR tools toward making targeted fixes.Source: §3 · p. 4
  • Patch generation produces candidate fixes, while patch validation filters candidates to identify plausible and correct patches.Because not all generated candidates repair the defect, validation checks for incorrect or invalid patches.Source: §3 · p. 4
  • The paper classifies APR by patch-generation technique because generation and validation are usually the main research focus, and generation is central to APR tools.Fault localization is treated as a separate research area.Source: §3 · p. 4

4 EVALUATION CRITERIA FOR APR TOOLS

The survey proposes a uniform framework for comparing APR tools across four dimensions and 12 metrics. It analyzes tools qualitatively because differing benchmarks and limited efficiency studies prevent a uniform quantitative view.

4 EVALUATION CRITERIA FOR APR TOOLS

  • The criteria cover Approach Design, Repair Ability, Repair Quality, and Repair Efficiency across 12 metrics.The framework is presented as a uniform view for reviewing and comparing APR tools.Source: §4 · p. 4, Table 1 · p. 5
  • Approach Design and Repair Ability are assessed qualitatively, while Repair Quality and Repair Efficiency are quantitative dimensions.The survey compares tools only qualitatively, summarizing features from existing literature.Source: §4 · pp. 4–5
  • Different test benchmarks and the limited number of APR tools examining repair efficiency prevent a uniform view of quantitative metrics.The authors say quantitative analysis requires dedicated large-scale empirical studies.Source: §4 · p. 5

5 APR TECHNIQUES RESEARCH PROGRESS

The survey classifies APR techniques by patch-generation approach, reviews their development in time order, and summarizes their comparative strengths and limitations.

5 APR TECHNIQUES RESEARCH PROGRESS

  • APR techniques are grouped into search-based, constraint-based, template-based, and learning-based categories, with tools compared qualitatively by approach design and repair ability.The section also previews a time-ordered review and a summary of the approaches’ pros and cons.Source: §5 · p. 6

5.1 Search-based

Search-based APR spans heuristic strategies from game-based repair to code-similarity search. The section traces their approaches and repair limits.

5.1 Search-based

  • Search-based methods explore a predefined patch space, using heuristics to locate buggy code and strategies such as mutation, selection, and test execution to find patches.The survey traces these methods from early work in 2005 to GenProg and SimFix.Source: §5.1 · p. 6

5.1.1 Repair as a Game.

  • Early game-based repair treated fixes as winning strategies, but the reviewed approaches had inefficient, repetitive fixes and limited repair ability.They do not support multi-type or multi-language fixes, and support for complex multi-hunk and multi-fault fixes is unclear.Source: §5.1.1 · p. 6

5.1.2 Biological Engineering.

  • GenProg localizes genetic search to statements executed by failing tests; its reported experiments fixed 16 C programs across eight defect types.RSRepair later outperformed GenProg in repair effectiveness and efficiency by discarding failed test cases and executing fewer tests.Source: §5.1.2 · pp. 7–8
  • Code Phage transfers donor code, ARJA optimizes patch changes and tests, and bug-inducing-commit information was used in a strategy that outperformed CapGen.The surveyed biological-engineering approaches generally lacked automated learning capabilities; most did not state whether multi-hunk and multi-fault fixes were supported.Source: §5.1.2 · p. 8

5.1.3 Target Value Search.

  • SPR’s target-value search checks whether parameter values let a transformation schema produce a successful fix, using meaningful modifications to selectively search the space.SPR includes its own fault-localization algorithm and supports multi-type fixes, but does not support multi-language fixes.Source: §5.1.3 · pp. 8–9

5.1.4 Code Similarity.

  • Similarity-based repair reuses code or patches to reduce search space, progressing from token matching and code context to patch-information-guided search.CRSearcher reported about 50% repair-time savings; SimFix fixed 14 more errors than ssFix.Source: §5.1.4 · p. 9
  • Later similarity tools refined matching and search: sharpFix uses statement-level local and method-level global searches, while VarFix uses test-passing edit combinations.VarFix can fix multi-line and multi-type bugs and performs well in large-scale programs.Source: §5.1.4 · p. 9
  • Similarity-based repair cannot generate a valid fix when no repair pattern is found, and reviewed tools use existing knowledge rather than learning repair knowledge themselves.The section also notes unresolved support for multi-hunk and multi-fault fixes in several tools.Source: §5.1.5 · p. 10, §5.1.4 · p. 10

5.2 Constraint-based

Constraint-based APR formulates repair as solving specifications, including test-derived constraints and formal specifications. The surveyed approaches trade reduced search for dependence on suitable constraints.

5.2 Constraint-based

  • Constraint-based methods turn repair into a constraint-solving problem, using specifications to prune infeasible choices and find expression-level variations satisfying test-derived constraints.Nopol and SemFix use test cases as implicit program specifications.Source: §5.2 · p. 10

5.2.1 Contract-based.

  • AutoFix uses contracts to guide fault localization and repair, combining static and dynamic analysis; JAID replaces manual contracts with abstract states constructed from source code.AutoFix works only on Eiffel and requires developers to write contracts, whereas JAID supports Java and is described as more adaptable.Source: §5.2.1 · p. 10

5.2.2 Constraint Solvers.

  • Test-driven solvers generate constraints from tests: SemFix uses symbolic execution, DirectFix adds component-based synthesis for multi-line bugs, and Angelix uses lightweight constraints to address scalability.Nopol instead uses value replacement with SMT for if-conditional bugs and shows potential for large-scale repair.Source: §5.2.2 · p. 11

5.2.3 Combination of Syntactic and Semantic Approaches.

  • Semantic code search encodes codebase data as SMT constraints, while S3 combines syntactic and semantic guidance to generate patches and mitigate overfitting.pAPRika uses unit tests as constraints on mutations to generate fixes in a real-time IDE plugin.Source: §5.2.2 · p. 11, §5.2.3 · p. 11
  • Test-driven constraints can overfit and do not suit bugs that are difficult to test deterministically, motivating formal specifications such as contracts and behavioral specifications.The survey identifies multiple newer formal-specification approaches as an active area of interest.Source: §5.2.4 · p. 11

5.2.4 New Formal Specifications.

  • Formal specifications support repair beyond test cases: FootPatch uses Separation Logic, Maple combines templates with constraint solving, and ExtractFix synthesizes constraints from vulnerability-exploit execution.ExtractFix combines control- and data-dependency analysis for fault localization and supports multi-hunk fixes.Source: §5.2.4 · pp. 11–12
  • Constraint-based approaches reduce search and computational cost while improving repair quality, but depend heavily on formulated specifications and do not automate acquisition of empirical repair knowledge.The survey also notes syntactic-semantic combinations, formal specifications beyond tests, and real-time APR tools as lines of innovation.Source: §5.2.5 · p. 12

5.3 Template-based

Template-based APR uses predefined fix patterns to generate candidate patches. The survey covers their manual origins, automated mining, specialized repair settings, and continuing limitations.

5.3 Template-based

  • Template-based repair addresses the large search spaces of heuristic methods by selecting predefined fix templates after fault localization to generate candidate patches.Templates may be manually extracted or automatically mined; the survey cites an empirical study finding these tools most effective among the compared schemes.Source: §5.3 · p. 12

5.3.1 Manually Extracted Templates.

  • PAR created ten templates by examining open-source patches and generated more acceptable patches than GenProg.relifix instead derived code transformations from manual inspection of 73 real software regressions and used program-version and test-history information.Source: §5.3.1 · pp. 12–13
  • Early manually extracted-template tools lacked multi-language support and did not explore multi-hunk or multi-fault repair; relifix targeted specific defect types.The reviewed tools relied on existing fault-localization tools and did not focus on context-aware generation.Source: §5.3.1 · p. 13

5.3.2 Automatically Mining Templates.

  • HDRepair pioneered automated fix-pattern extraction using graph mining, while Genesis inferred 108 code transformations from 577 sampled transformations.CNN-based pattern mining informed AVATAR, which partially fixed 11 bugs with multiple faulty code fragments.Source: §5.3.2 · p. 13
  • FixMiner mines repair patterns with AST-level code-change and context information; iFixR uses bug reports to guide repair, while TBar prioritizes among selected patterns.iFixR’s patch generation depends directly on bug-report quality; TBar’s pattern prioritization addresses cases where one fault matches multiple templates.Source: §5.3.2 · p. 13
  • HERCULES targets multi-hunk repair by associating multiple bug locations for simultaneous fixes, a capability the survey contrasts with Angelix.The survey describes this as a contribution to mitigating the multi-hunk repair problem.Source: §5.3.2 · p. 14
  • PraPR performs repair at bytecode level, supporting multiple JVM languages and offering higher scalability than source-code-level approaches.The survey presents bytecode-level repair as a route to multi-language repair scenarios.Source: §5.3.2 · p. 14
  • Template-based APR evolved from manual extraction to automated mining across patches, project histories, and defect reports, improving fix quality and efficiency.Noisy data, template-granularity trade-offs, and lack of continuous learning limit coverage, especially for complex or non-repetitive defects.Source: §5.3.3 · p. 14

5.4 Learning-based

Learning-based APR uses repair examples to learn empirical knowledge and guide automated fixes. Its development spans bug, programming-error, and vulnerability repair, while current models still face limitations in capturing program structure and semantics.

5.4 Learning-based

  • Learning-based APR uses neural models to learn repair knowledge from many defect samples, extending template selection toward learning higher-level repair knowledge.These approaches are also called data-driven repair solutions.Source: §5.4 · pp. 14–15

5.4.1 Software Bug Repair.

  • Bug repair progressed from NMT bug-fix pairs [125] to syntax-aware and pretrained models, then LLM and hybrid tools; these approaches still rely on context, and multi-fault repair remains unexplored.Reported approaches include grammar-constrained generation, pretraining and fine-tuning, direct LLM fix generation, and combinations with fault localization or templates.Source: §5.4.1 · pp. 15–17

5.4.2 Programming Error Repair.

  • 71.7% repair accuracy on DeepFix followed DrRepair combined with BIFI, compared with DrRepair’s 68.2%; later work explored context-aware repair and LLMs.BIFI trains a breaker on realistic bad code to generate examples closer to real-world errors.Source: §5.4.2 · pp. 18–19

5.4.3 Security Vulnerability Repair.

  • Vulnerability repair transfers bug-fixing knowledge to small-sample settings, and VulRepair’s LLM fine-tuning outperformed VRepair; vulnerability localization and multi-defect repair remain underexplored.VRepair and VulRepair support multi-hunk repair, while SeqTrans is limited to single-line repair.Source: §5.4.3 · p. 19

5.5 APR Development Summary and Discussion

This section reviews APR’s development, capabilities, and limitations, and discusses unresolved evaluation and pipeline issues alongside research directions involving LLMs, datasets, repair scope, and learning paradigms. It also reports a preliminary finding that code abstraction does not significantly improve most tested LLM-based APR tools.

5.5.1 Summary.

  • APR approaches evolved from heuristic search through constraints and templates to learning, with each addressing predecessors’ limits but retaining tradeoffs that motivate integration.Search is limited by large search spaces and compute; constraints can be inflexible, templates have coverage and extraction costs, and learning-based repair depends on training data and remains difficult to interpret. Formal specifications can mitigate test-suite overfitting, while templates can improve efficiency and patch quality over random mutations.Source: §5.5.1 · pp. 20, 22

5.5.2 Discussion.

  • APR tools commonly target Java and C, while many traditional tools support only one language; the survey also identifies programming errors and emerging vulnerability repair as expanding problem areas.It calls for cross-disciplinary work and combining deep learning with traditional APR to improve language scalability and address varied code problems.Source: §5.5.2 · p. 23
  • Multi-hunk repair remains a major challenge because most APR tools target single-hunk bugs, and existing multi-hunk approaches address only limited cases.Complex dependencies across code lines make multi-hunk fixing difficult; the paper identifies it as a continuing research direction.Source: §5.5.2 · p. 23
  • APR evaluation faces limited benchmark data and possible single-benchmark overfitting, while more accurate fault localization is associated with less patch overfitting.The authors recommend diverse benchmarks across languages and defect types, and further work on fault localization and other factors affecting repair quality.Source: §5.5.2 · pp. 23–24
  • Learning-based APR tools outperform traditional tools on Defects4J, but their data-driven repairs remain less interpretable than human fixes and may be difficult to deploy industrially.The paper attributes their repair capability to the large volume of open-source project data available for learning.Source: §5.5.2 · p. 24
  • Learning-based APR preprocessing, code representations, and context-aware inputs lack systematic comparisons, leaving their effects on repair quality and suitability for LLMs uncertain.Token sequences are concise and widely used but can miss code structure and dependencies; trees and graphs can represent these features more richly, and task-appropriate representations and prompts need further study.Source: §5.5.2 · pp. 24–26
  • Code abstraction did not significantly improve repair performance for most tested LLMs, possibly because it removes semantic cues and LLMs are pretrained on raw code.The authors therefore suggest that additional code-processing steps may not be needed for LLM repair.Source: Table 5 · p. 25, §5.5.2 · p. 25
  • Subword-level tokenization has become more popular in recent APR work and is considered suitable for programming-language tasks, though it has limitations.The survey contrasts its recent use with earlier reliance on word-level tokenizers and begins to examine reasons for the shift.Source: §5.5.2 · p. 26
  • Subword tokenizers alleviate OOV problems but can lengthen sequences, potentially reducing repair ability; their effects need uniform empirical comparison.Further work is needed on tokenization and simpler code representations, since models, including LLMs, can struggle with longer input/output sequences.Source: §5.5.2 · p. 27
  • Different candidate counts and runtime limits can undermine APR comparisons, while patch filtering and ranking lack uniform evaluation and beam search is not syntax-aware.The discussion also identifies a need for effective post-processing in traditional APR, where it can help reduce patch overfitting.Source: §5.5.2 · pp. 27–28
  • VulRepair selected fine-tuned CodeT5 using loss scores and obtained 44% repair accuracy; preliminary experiments found BLEU-based evaluation could improve repair accuracy by up to 55%.Source: §5.5.2 · p. 30
  • Test suites and manual checks are inefficient and can miss overfitting, while exact match may undervalue valid repairs when multiple fixes exist for one bug.The authors suggest more optimized validation, including correctness assessment or automated validation tools.Source: §5.5.2 · p. 28
  • Inconsistent training datasets can make APR comparisons unfair, while train-test overlap can leak repair knowledge and inflate apparent results.The authors call for uniform training data and deeper overlap detection across datasets and benchmarks.Source: §5.5.2 · pp. 30–31
  • Manual inspection found 38 invalid VulRepair samples (0.45%) and 671,497 invalid or incorrect CoCoNut samples (20.71%), potentially impairing learning and increasing training overhead.The CoCoNut samples had identical bug and fix code; the VulRepair samples lacked corresponding fix code.Source: §5.5.2 · p. 31
  • Unified APR across defect types and languages remains a research direction, including whether repair knowledge can transfer between defects or programming languages.Learning-based multi-language tools use multiple models, multi-task or continual learning, or multilingual LLMs; cross-domain repair knowledge remains underexplored.Source: §5.5.2 · pp. 31–32
  • Multi-hunk repair has improved, but iterative, holistic, and synchronous approaches retain limitations; multi-bug repair and systematic study of repair quality and efficiency remain open.Iterative repair can expand the search space and use incorrect context; synchronous repair depends on ASTs and one-to-one bug-fix locations, while multi-bug scenarios challenge model input/output limits.Source: §5.5.2 · pp. 32–34
  • Repair-quality assessment is incomplete and lacks uniform metrics, with prior work examining overfitting [50] [72] [142] [157] [164], side effects, and acceptability or maintainability.Large-scale empirical comparisons of repair quality across APR families are also lacking.Source: §5.5.2 · p. 34
  • Efficiency comparisons lack a fair uniform basis because tools use different settings; prior studies assess time, cloud-based money cost, and energy use [89], while learning-based tools lack in-depth study.Future studies should compare APR techniques in a uniform experimental benchmark environment.Source: §5.5.2 · pp. 34–35
  • The survey leaves quality and efficiency evaluation to empirical studies, since accurate assessment requires uniform settings and manual review; future work should compare technique strengths and weaknesses.The authors provide assessment perspectives in Section 4 as a reference, while noting the lack of uniform metrics and principles.Source: §5.5.2 · p. 35
  • NMT is the most popular learning paradigm for APR [18] [50] [72] [156], but its need for many labeled bug-fix pairs and limited use of project-wide code leave its suitability unresolved.The authors consider NMT practical but not necessarily optimal, and call for further work to address these limitations.Source: §5.5.2 · p. 35
  • Pre-trained models can support unsupervised cloze-style repair; AlphaRepair [142] uses CodeBERT and achieved the best results on Defects4J, suggesting LLM pre-training has potential for APR.Unlike NMT, this approach predicts fix code from context rather than translating bug code to fix code, motivating exploration of new learning paradigms.Source: §5.5.2 · p. 35

6 RELATED ADVANCE WORK

The section reviews related advances in APR evaluation, fault localization, patch correctness assessment, and programming language models. It describes evaluation frameworks and technical approaches while identifying areas needing further study.

6.1 APR Evaluation

  • Evaluation studies expanded from counting fixed defects to broader quality metrics, but large-scale comparisons remain limited and learning-based APR evaluation needs deeper study.Benchmark overfitting supports testing tools on multiple benchmarks; E-APR used nine significant features to reveal strengths and weaknesses of APR techniques.Source: §6.1 · p. 36

6.2 Fault Localization

  • Fault localization methods trade fine-grained defect detection for resource use: dynamic methods are resource intensive, while static methods are faster but less fine-grained.The survey also notes that fault localization quality affects repair and describes combined dynamic-static and multiple-fault approaches.Source: §6.2 · p. 36

6.3 Patch Correctness Assessment

  • Patch correctness assessment uses static patch characteristics or dynamic approaches that often rely on automated test generation to sort and filter candidate patches.One reported approach prevented 56.3% of incorrect patches; an empirical analysis found shortcomings across nine APCA techniques and proposed combining methods.Source: §6.3 · p. 37

6.4 Programming Language Model

  • Programming-language models must account for code syntax and logical structure as well as data- and control-flow dependencies, and large code-trained models have shown effective APR results.The survey identifies continued development of large language models trained on code as a direction for advancing programming-language tasks and APR.Source: §6.4 · p. 37

7 CHALLENGES AND DIRECTIONS

After reviewing APR's evolution and state-of-the-art work, the authors identify key challenges and future directions for APR research.

7 CHALLENGES AND DIRECTIONS

  • The discussion draws on the survey of APR techniques' evolution and its analysis of state-of-the-art work.Source: §7 · p. 37
  • The section identifies key challenges in APR research.Source: §7 · p. 37
  • The section presents future directions for APR research.Source: §7 · p. 37

7.1 Existing Challenges

The survey highlights persistent challenges in patch correctness and quality, repair efficiency and scalability, datasets, and industrial deployment. It notes that test-suite coverage, invalid patches, limited dataset quality, and practical deployment needs constrain repair systems.

7.1 Existing Challenges

  • Test cases may miss defects, so a patch that passes them is not necessarily correct; the survey reports no mature, effective solution to patch overfitting.Overfitting is affected by fault localization, patch generation, post-processing, and validation, so mitigation requires progress across these techniques.Source: §7.1.1 · pp. 37–38

7.1.1 Patch Overfitting Problem.

  • Comprehensive repair-quality studies remain limited, although quality includes avoiding new defects and patch correctness, maintainability, and acceptability.The survey calls for more in-depth research on repair quality.Source: §7.1.2 · p. 38

7.1.2 Repair Quality Problem.

  • Repair-efficiency research lacks large-scale cost studies, and invalid patches from all repair techniques affect efficiency.Learning-based repair costs have not been explored in depth; the survey says efficiency constraints limit large-scale APR deployment.Source: §7.1.3 · p. 38

7.1.3 Repair Efficiency Problem.

  • Most APR tools support only single-language and single-hunk fixes and have not been tested on complex multi-fault tasks, limiting scalability and generality.Data-driven approaches offer potential for broader fixes, but challenges remain and general-purpose large-scale repair systems are lacking.Source: §7.1.4 · p. 38

7.1.4 Generic Fixes Problem.

  • Learning-based APR research has dataset concerns, including benchmark overfitting, data quality, and uncertainty about repairing beyond experimental datasets.The survey notes that even Defects4J patch data may need optimization and calls for larger datasets and quality corrections.Source: §7.1.5 · p. 39

7.1.5 Dataset Quality Problem.

  • Industrial APR remains difficult: real environments may lack bug-exposing tests, tools can be hard to integrate and review, and large projects pose repair challenges.An empirical report found industrial application status not promising; current tools also lack explored cross-file fixes and non-source-level repair capabilities.Source: §7.1.6 · pp. 39–40

7.2 Improvement Directions

The survey identifies improvement needs across search, representations, localization and testing, patch quality, and learning-based and LLM approaches. It also highlights gaps in datasets, complex repairs, and empirical evaluation.

7.2.1 Exploring the Fitness Function.

  • Search-based APR may benefit from optimized search strategies, but studies disagree on whether finer-grained fitness improves repair results, leaving its effect unresolved.The survey associates optimized search strategies with faster candidate-patch discovery.Source: §7.2.1 · p. 40, §7.2.2 · p. 40

7.2.2 Search Strategy Optimization.

  • Code representations should capture concise context and rich dependencies, while context reduction and PL-aware tokenization address the sequence-length limits that constrain model repair.The survey points to dependency analysis for removing irrelevant context and tokenizers that limit sequence length while retaining PL syntax and mitigating OOV.Source: §7.2.3 · p. 40, §7.2.9 · p. 42, §7.2.10 · p. 42

7.2.4 FL Techniques Research.

  • Future APR should improve fault localization and test quality, since localization accuracy remains unsatisfactory and weak or flaky tests can admit incorrect patches.The survey also recommends improving patch validation efficiency and accuracy.Source: §7.2.4 · p. 41, §7.2.5 · p. 41, §7.2.12 · p. 42

7.2.5 Test Techniques Improvement.

  • Patch-quality work should favor simpler patches and stronger validation, while practical post-processing strategies remain underexplored.The survey identifies efficiency and accuracy as two goals for validation and notes that practical post-processing strategies are not yet established.Source: §7.2.6 · p. 41, §7.2.11 · p. 42, §7.2.12 · p. 42

7.2.6 Patch Quality Enhancement.

  • The survey points to OSS repair knowledge, AI methods, hybrid APR, and LLMs as opportunities spanning patch generation, localization, filtering, ranking, validation, and new learning paradigms.It also notes that fine-tuning LLMs lacks large-scale empirical study and that suitable representations and evaluation metrics remain unclear.Source: §7.2.7 · p. 41, §7.2.8 · p. 41, §7.2.15 · p. 43

7.2.15 LLM for Mroe PL Task.

  • Dataset quality and overlap need further assessment, while cross-domain and cross-language repair could benefit from transferring knowledge and understanding defect root causes.The survey raises meta-learning as a possible approach to transferring repair knowledge between defect domains and programming languages.Source: §7.2.16 · p. 43, §7.2.17 · p. 43, §7.2.18 · p. 44

7.2.18 Defect Root Cause Understand.

  • Multi-hunk and multi-fault repairs remain difficult, and APR still lacks uniform criteria for assessing repair quality and efficiency.The survey highlights bugs with one location but multiple fix locations as a particular multi-hunk challenge; it also calls for deeper empirical study of multi-fault repairs.Source: §7.2.19 · p. 44, §7.2.20 · p. 44, §7.2.21 · p. 44

7.2.23 Conducting More Comprehensive Empirical Studies.

  • More empirical studies are needed to compare learning-based and traditional APR on overfitting, assess learning-based design choices fairly, and evaluate LLMs across repair tasks.The survey also calls for uniform metrics to examine repair quality and efficiency and for investigation of multi-fault scenarios.Source: §7.2.23 · p. 45

8 CONCLUSION

The conclusion presents APR as a rapidly developing, multidisciplinary field, with deep learning contributing to recent growth. It summarizes four technique categories and highlights LLMs and further empirical studies among future directions.

8 CONCLUSION

  • APR research spans software bugs, programming errors, and security vulnerabilities, while also drawing on programming-language processing and knowledge from multiple domains.The conclusion frames these connections as part of building automated systems for productivity improvement.Source: §8 · p. 46
  • The survey traces four APR categories and discusses development trends, technical details, LLM opportunities, and the need for more empirical studies.The categories are search-based, constraint-based, template-based, and learning-based.Source: §8 · p. 46

A APR WORKS

The appendix presents tables of APR works across technique categories and explains conventions used to describe tools and their results.

A APR WORKS

  • The appendix provides tabular summaries of APR works, including search-based, constraint-based, template-based, and learning-based approaches.The supplied passages identify Tables 10–13 as summaries of these categories.Source: A APR WORKS · p. 46, Table 10 · p. 46, Table 11 · p. 46
  • The tables classify defect types and bug-line complexity, and report benchmark results as correct/plausible patch counts or repair accuracy.The survey defines x/y as correct patches over plausible patches and z% as repair accuracy; error-repair results use Full Repair where available.Source: A APR WORKS · p. 47

B APR DATASETS

The appendix investigates and summarizes datasets relevant to APR tasks.

B APR DATASETS

Related papers

Loading 2303.18184v3…