iFixR: Bug Report driven Program Repair
Not on the map. Why?
Abstract (arXiv)
Issue tracking systems are commonly used in modern software development for collecting feedback from users and developers. An ultimate automation target of software maintenance is then the systematization of patch generation for user-reported bugs. Although this ambition is aligned with the momentum of automated program repair, the literature has, so far, mostly focused on generate-and-validate setups where fault localization and patch generation are driven by a well-defined test suite. On the one hand, however, the common (yet strong) assumption on the existence of relevant test cases does not hold in practice for most development settings: many bugs are reported without the available test suite being able to reveal them. On the other hand, for many projects, the number of bug reports generally outstrips the resources available to triage them. Towards increasing the adoption of patch generation tools by practitioners, we investigate a new repair pipeline, iFixR, driven by bug reports: (1) bug reports are fed to an IR-based fault localizer; (2) patches are generated from fix patterns and validated via regression testing; (3) a prioritized list of generated patches is proposed to developers. We evaluate iFixR on the Defects4J dataset, which we enriched (i.e., faults are linked to bug reports) and carefully-reorganized (i.e., the timeline of test-cases is naturally split). iFixR generates genuine/plausible patches for 21/44 Defects4J faults with its IR-based fault localizer. iFixR accurately places a genuine/plausible patch among its top-5 recommendation for 8/13 of these faults (without using future test cases in generation-and-validation).
Key facts. Cited by 11 papers in the map (data through 7 Oct 2026). First posted on arXiv 12 Jul 2019.
Builds on
No reference list yet.
Built on by
Citing papers per year: 2022: 2; 2023: 2; 2024: 4; 2025: 2; 2026: 1.
11 papers.
- 2024AutoCodeRover: Autonomous Program Improvementcited by 272
- 2023Baldur: Whole-Proof Generation and Repair with Large Language Modelscited by 118
- 2025Towards an Understanding of Context Utilization in Code Intelligencecited by 10
- 2024Enhancing Automated Program Repair with Solution Designcited by 8
- 2022Is this Change the Answer to that Problem? Correlating Descriptions of Bug and Code Changes for Evaluating Patch Correctnesscited by 7
- 2024Automated Program Repair: Emerging trends pose and expose problems for benchmarkscited by 7
- 2025REFINE: Enhancing Program Repair Agents through Context-Aware Patch Refinementcited by 6
- 2022Using Developer Discussions to Guide Fixing Bugs in Softwarecited by 3
- 2026On the Role of Fault Localization Context for LLM-Based Program Repaircited by 3
- 2023Automated Repair of Declarative Software Specifications in the Era of Large Language Modelscited by 1
- 2024NARRepair: Non-Autoregressive Code Generation Model for Automatic Program Repaircited by 0
- 2026On the Role of Fault Localization Context for LLM-Based Program Repair7 Apr 2026
- 2025REFINE: Enhancing Program Repair Agents through Context-Aware Patch Refinement4 Oct 2025
- 2025Towards an Understanding of Context Utilization in Code Intelligence11 Apr 2025
- 2024Enhancing Automated Program Repair with Solution Design22 Aug 2024
- 2024NARRepair: Non-Autoregressive Code Generation Model for Automatic Program Repair24 Jun 2024
- 2024Automated Program Repair: Emerging trends pose and expose problems for benchmarks8 May 2024
- 2024AutoCodeRover: Autonomous Program Improvement8 Apr 2024
- 2023Automated Repair of Declarative Software Specifications in the Era of Large Language Models19 Oct 2023
- 2023Baldur: Whole-Proof Generation and Repair with Large Language Models8 Mar 2023
- 2022Using Developer Discussions to Guide Fixing Bugs in Software11 Nov 2022
- 2022Is this Change the Answer to that Problem? Correlating Descriptions of Bug and Code Changes for Evaluating Patch Correctness8 Aug 2022