Paper deep dive
A Study on the Impact of Fault localization Granularity for Repository-Scale Code Repair Tasks
Joseph Townsend, Chandresh Pravin, Kwun Ho Ngan, Matthieu Parizy
Intelligence
Status: succeeded | Model: google/gemini-3.1-flash-lite-preview | Prompt: intel-v1 | Confidence: 94%
Last extracted: 4/2/2026, 3:24:24 AM
Summary
This study investigates the impact of fault localization granularity (line-level, function-level, and file-level) on repository-scale automatic program repair (APR). By modifying the Agentless framework to use ground-truth localization data (the 'perfect localization' assumption), the authors evaluate performance on the SWE-Bench-Mini dataset using the Qwen3-Coder-30B model. Findings indicate that function-level granularity generally yields the highest repair rates, though performance is task-dependent, suggesting that optimal granularity may vary based on issue complexity.
Entities (4)
Relation Signals (2)
Agentless â utilizes â Qwen3-Coder-30B
confidence 95% ¡ For the code repair phase, we employ Qwen3-Coder-30B as the coding language model
Function-level granularity â yieldshighestrepairrateon â SWE-Bench-Mini
confidence 90% ¡ function-level granularity yields the highest repair rate against line-level and file-level.
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Automatic program repair can be a challenging task, especially when resolving complex issues at a repository-level, which often involves issue reproduction, fault localization, code repair, testing and validation. Issues of this scale can be commonly found in popular GitHub repositories or datasets that are derived from them. Some repository-level approaches separate localization and repair into distinct phases. Where this is the case, the fault localization approaches vary in terms of the granularity of localization. Where the impact of granularity is explored to some degree for smaller datasets, not all isolate this issue from the separate question of localization accuracy by testing code repair under the assumption of perfect fault localization. To the best of the authors' knowledge, no repository-scale studies have explicitly investigated granularity under this assumption, nor conducted a systematic empirical comparison of granularity levels in isolation. We propose a framework for performing such tests by modifying the localization phase of the Agentless framework to retrieve ground-truth localization data and include this as context in the prompt fed to the repair phase. We show that under this configuration and as a generalization over the SWE-Bench-Mini dataset, function-level granularity yields the highest repair rate against line-level and file-level. However, a deeper dive suggests that the ideal granularity may in fact be task dependent. This study is not intended to improve on the state-of-the-art, nor do we intend for results to be compared against any complete agentic frameworks. Rather, we present a proof of concept for investigating how fault localization may impact automatic code repair in repository-scale scenarios. We present preliminary findings to this end and encourage further research into this relationship between the two phases.
Tags
Links
- Source: https://arxiv.org/abs/2604.00167v1
- Canonical: https://arxiv.org/abs/2604.00167v1
Trouble viewing inline? Open PDF directly â
Full Text
67,656 characters extracted from source content.
Expand or collapse full text
A Study on the Impact of Fault localization Granularity for Repository-Scale Code Repair Tasks JOSEPH TOWNSEND â , Fujitsu Research of Europe, UK CHANDRESH PRAVIN â , Fujitsu Research of Europe, UK KWUN HO NGAN â , Fujitsu Research of Europe, UK MATTHIEU PARIZY, Fujitsu Research of Europe, UK Automatic program repair (APR) can be a difficult and demanding task, especially when it comes to resolving complex issues at a repository-level. Resolution often includes issue reproduction, fault localization, code repair, testing and validation. Issues of this scale can be commonly found in popular GitHub repositories or datasets that are derived from them such as SWE-Bench [14]. Some repository-level approaches separate localization and repair into distinct phases. Where this is the case, the fault localization (FL) approaches vary in terms of the granularity of localization. For example, some of these frameworks will identify specific methods or functions responsible for an issue [7,28], others will narrow down to specific code lines or segments of lines [18,20,33]. Some even localize to entire files before passing this information on to the repair agent [27,32]. However, there does not appear to have been much effort towards an empirical study of what level of granularity is most beneficial for the repair tasks. Where the impact of granularity is explored to some degree for smaller datasets, not all isolate this issue from the separate question of localization accuracy by testing code repair under the assumption of perfect fault localization. To the best of the authorsâ knowledge, no repository-scale studies have explicitly investigated granularity under this assumption, nor conducted a systematic empirical comparison of granularity levels in isolation. We propose a framework for performing such tests by modifying the localization phase of the Agentless framework [33] to retrieve ground-truth localization data and include this as context in the prompt fed to the repair phase. We show that under this configuration and as a generalization over the SWE-Bench-Mini dataset, function-level granularity yields the highest repair rate against line-level and file-level. However, a deeper dive suggests that the ideal granularity may in fact be task dependent. This study is not intended to improve on the state-of-the-art for SWE-Bench-Mini or any other dataset, nor do we intend for results to be compared against any complete agentic frameworks. Rather, we present a proof of concept for investigating how fault localization may impact automatic code repair in repository-scale scenarios. We present preliminary findings to this end and encourage further research into this relationship between the two phases. CCS Concepts:⢠Computing methodologiesâNatural language processing; Neural networks;⢠Software and its engineering â Software testing and debugging. Additional Key Words and Phrases: Automated Program Repair, Large Language Models, Software Engineering, Knowledge Represen- tation, Context Engineering 1 Introduction Over the past decade, automated program repair (APR) has advanced significantly from its origins, fuelled by more capable program-analysis tools, the emergence of large language models, and rapid progress across machine learning as a whole. â Equal contribution to this research. Authorsâ Contact Information: Joseph Townsend, joseph.townsend@fujitsu.com, Fujitsu Research of Europe, London, UK; Chandresh Pravin, chandresh. pravin@fujitsu.com, Fujitsu Research of Europe, London, UK; Kwun Ho Ngan, kwun.hongan@fujitsu.com, Fujitsu Research of Europe, London, UK; Matthieu Parizy, parizy.matthieu@fujitsu.com, Fujitsu Research of Europe, London, UK. 1 arXiv:2604.00167v1 [cs.SE] 31 Mar 2026 2Joseph Townsend, Chandresh Pravin, Kwun Ho Ngan, and Matthieu Parizy Great efforts are being made to perform repository-level code repair with the help of LLM-based agents, especially in popular, highly competitive challenges such as SWE-Bench [14]. This scale of repair is highly important because unlike many of the smaller datasets used to evaluate code repair methods [2,8], repository-level repair tasks are derived from genuine code issues encountered by software developers in their daily tasks. The scale of issues represented by smaller datasets tends to be limited to single functions or files, and may only require correction of single code lines in order to be resolved. Some of these repository-level approaches separate localization and repair into distinct phases by providing different instructions in the prompt or even by using different agents. Where this is the case, the fault localization approaches vary in terms of the granularity of localization. For example, some of these frameworks will identify specific methods or functions responsible for an issue [7,28], others will narrow down to specific code lines or segments of lines [18,20,33]. Some even localize to entire files before passing this information on to the repair agent [27,32]. However, there does not appear to have been much effort towards an empirical study of what level of granularity is most beneficial for the repair tasks. Many fault localization approaches merit themselves on high localization scores, but in repair tasks, a high or even perfect localization score has no value if it does not influence the repair agent in the generation of a patch which resolves the initial issue. Thus, we argue that before investigating new means of fault localization for the purposes of program repair, it is prudent to first explore suitable means of presenting perfect fault localization data to the repair agent, which is possible using ground truths provided in fault localization datasets. In other words, if there is no format under which the ground truths of localization data influence the repair agent in generating patches more successfully, then there is no value in attempting to model fault localization for that dataset until the shortfalls of the repair agent have been addressed. To the authorsâ knowledge, the literature does not explore this in detail either. While code-line level fault localization is uncommon in repository-level tasks, it is more commonly applied to smaller datasets that donât capture the realism of repository-scale tasks derived from genuine source code. Where developers do intend to upscale the scope of fine-grained methods from some of these smaller datasets to larger, more realistic contexts, we encourage them to first consider experiments such as these "perfect localization" tests. We are not trying to argue that there is no place for fine-grained localization, only that there is a case for more methodical exploration of its application (or that of any granularity of localization) to real-world tasks before further development. Section 2 provides a review of background material, observing that despite a variety of fault-localization guided APR methods being proposed for repository-scale tasks, very few test the perfect localization hypothesis to back-up the validity of treating these two tasks as separate phases, and also that very little effort is made to confirm a suitable level of granularity. Section 3 presents a proof of concept for performing such tests by modifying the localization phase of the Agentless framework [33] to retrieve ground-truth localization data and including this as context in the prompt fed to the repair phase (which in our case is Qwen3-Coder-30B [35]). We also bypass Agentlessâ patch validation phase to eliminate the influence of the re-ranking process on the final resolve rate, thus isolating the impact of localization granularity even further. Section 4 presents the findings, namely that under this configuration at least function-level granularity yields the highest resolve rate for the SWE-Bench-Mini subset of the SWE-Bench Verified benchmark overall, but a deeper dive suggests that the ideal granularity may in fact be task-dependent. Section 5 highlights the limitations and the boundaries which are critical in the automatic program repair (APR) but will not be assessed in this work. Section 6 proposes further variations of our study to expand the scope of these experiments and observe whether or not the same findings hold. Section 7 concludes. A Study on the Impact of Fault localization Granularity for Repository-Scale Code Repair Tasks3 2 Background Automated program repair (APR) pipelines typically involve multiple stages, including issue reproduction, fault localization (FL), patch generation, and validation. Fault localization and patch generation are two critical components that are commonly delegated to separate agents or distinct passes in large-scale repository-level repair [29,40,47]. The recent emergence of LLM-based approaches have further supplemented this design using multi-agent and multi- phase pipelines [24,33]. These approaches can be broadly classified into two frameworks: procedural frameworks that decompose the code repair task into a fixed sequence of discrete steps [36], and agentic frameworks that use LLMs to plan and execute code repair steps with access to tools such as code search and test execution [3,38]. Although alternative approaches such as fine-tuning and generate-and-validate strategies exist, our discussion centers on fault localization and patch generation as two core components that appear across a broad range of APR systems, rather than suggesting a rigid two-stage pipeline [22]. The primary standard by which the field measures progress is SWE-Bench [14], which has become the benchmark for evaluating LLM-based APR systems on a realistic repository-level scale [39]. Despite this, the granularity and representation of localization information remains an open question [5], with little empirical evidence presented for these design choices [17, 36, 43]. Numerous APR systems illustrate the two-stage fault-localization and patch-generation pipeline [21,36]. Agent- less [33] follows a hierarchical localization process, first narrowing to suspicious files, then to relevant classes or functions, and finally to fine-grained edit locations before passing these to its repair phase. AutoCodeRover [46] takes a software-engineering-oriented approach, using structured code search over AST representations at the class and method level, supplemented by method-level spectrum-based fault localization where a test suite is available. MASAI [1] decomposes the task across multiple specialised sub-agents, with its localization sub-agent tasked specifically with identifying files to edit via multi-step reasoning over the issue description. By contrast SWE-Agent [38] adopts a more agentic approach where the fault localization is not a discrete step but emerges from an iterative interaction through a command-line interface. Whilst all of these methods approach the bug repair task through some form of fault localization prior to patch generation, the granularity at which the localization signal is first derived and then propagated to the patch generation phase differs across frameworks [36,42], from file-level in some instances, to function and edit locations in others. Importantly, in no case is this choice empirically justified. This inconsistency suggests that granularity of localization is treated as an implementation detail rather than a principled design decision, and motivates a more systematic investigation. The variation in localization granularity across APR systems is not only a question of localization precision, rather, a fundamental question on what information the model requires to generate a patch successfully. Coarser granularity, such as file-level localization, provides the repair agent with broad surrounding context at the cost of specificity, requiring the model to identify the precise edit location independently [25,41]. Finer granularity, such as line-level localization, provides high specificity but may omit contextually relevant code (e.g., call sites, dependency definitions, or test constraints) presented in way that the repair agent requires to generate a correct patch [23,31,44]. The granularity of localization therefore mediates a trade-off between specificity and context that has direct implications for repair agent performance, independent of how accurately the localization was derived. This trade-off has received substantial attention in the fault localization literature but almost exclusively as a property of the localization step itself, evaluated in terms of precision and recall at file, method, or line level [26]. In contrast, we consider localization granularity not only as the spatial scope of the identified region (e.g., file, function, or line), but also as how that region is presented to the repair agent, in terms of the amount and structure of code context provided. 4Joseph Townsend, Chandresh Pravin, Kwun Ho Ngan, and Matthieu Parizy The question then of how these factors affect the downstream repair agent, rather than the localization phase alone, has been largely overlooked previously [42]. To the extent that granularity is not discussed in APR systems at all, it is treated as a fixed architectural choice rather than a variable with measurable downstream impact on patch generation success. This distinction motivates a direct empirical investigation of how different granularities of ground-truth localization information influence repair outcomes, independently of any localization method. One possible but under-explored explanation for this inconsistency is that LLMs used for code repair exhibit an implicit bias toward the granularity of code at which they were pre-trained or instruction-tuned [10,16]. Open code generation LLMs show that, where this information is available, are typically trained on file and repository-level granularities with extended sequences and infilling tasks. DeepSeek-Coder [9,11], for instance, uses repo-level pretraining, whilst StarCoder2 [19] is trained using repository-level context with file-level fill-in-the-middle transformations. InCoder [10] is trained to generate full code files by means of masking file-level code. Qwen3-Coder-Next [6], on the other hand, shows examples of function/class level bug synthesis to scale up their agentic training procedure, which follows from the Qwen2.5-Coder [13] using file-and-repo-level training. Whilst evidence from code generation settings suggests that fine-tuning data granularity influences downstream task performance [16], whether this effect holds for large-scale repository-level APR has yet to be tested. Our work isolates this question by removing the localization error as a source of bias, providing a direct empirical evaluation of the effects of granularity on patch-generation success, independent of any localization method. 3 Method Motivated by a lack of empirical justification for choice of granularity in repository-scale APR, we describe our method for performing such an evaluation at three levels: line-level, function-level and file-level. Furthermore, key to our approach is to adopt the perfect localization assumption so that analysis of the impact of each granularity can be concentrated purely on the repair phase. 3.1 Dataset We evaluate on the SWE-Bench Mini dataset 1 , which is a subset of 50 instances from the larger SWE-Bench Verified 2 set, containing 500 instances each derived from human-verified GitHub issue resolutions across 12 popular, open-source python repositories. SWE-Bench Miniâs 50 instances are taken from only 2 repositories: django 3 and sphinx-doc 4 . Each instance contains both the broken code before repair and the solution code (i.e. the pull request). Both datasets are vetted by humans, so the ground truth patches which form the basis of the localized context in our perfect localization assumption can be assumed relevant to the issues to be solved. 3.2 Architecture We chose Agentless [33] to orchestrate the patch generation pipeline as a simple architecture that enabled us to focus on the changes we were interested in. It is sequential in nature, enabling the isolation of individual phases and avoiding the complexity of agentic interactions found in environments such as OpenHands [30] and SWE-Agent [38]. We bypass Agentlessâ fault localization phase to provide ground truth localizations to the repair phase, thus imple- menting the "perfect localization" assumption necessary to investigate the effect of localization on code repair. How we 1 https://huggingface.co/datasets/MariusHobbhahn/swe-bench-verified-mini 2 https://w.swebench.com/verified.html 3 https://github.com/django/django 4 https://github.com/sphinx-doc/sphinx A Study on the Impact of Fault localization Granularity for Repository-Scale Code Repair Tasks5 Fig. 1. A modified version of the Agentless framework [33] was designed to conduct the experiments. The file localization and patch validation phase from the original work were bypassed such that a replacement script derives perfect localization data from the ground truth patches to produce the raw generated patches for SWEBench evaluation in order to concentrate the study on the effect of localization granularity. obtain the ground truth localizations and feed these into the repair phase are covered in section 3.3. For the code repair phase, we employ Qwen3-Coder-30B [35] as the coding language model, deployed via vLLM v0.15.1 [15]. Finally, we also bypass Agentlessâ patch validation phase, selecting the first patch generated by default. The motivation for this to isolate the influence of the localization phase independently of any re-ranking. 3.3 Localization We adopt the "perfect localization" assumption, in which fault localization data is taken from the ground truth and injected into the repair prompt. This assumption has been criticised on the grounds that it is unrealistic [4]. While we do agree with this point, we believe the assumption is necessary when attempting to isolate and inspect other aspects of an APR methodâs performance. In our special case of attempting to identify an appropriate level of localization granularity for an APR agent, it would be a distraction if the accuracy of the localization method for each granularity were called into question. Thus, by adopting the perfect localization assumption, we isolate the granularity as the only variable. For an evaluation of FL and APR in concert, we would absolutely encourage the use of genuine localization. We obtain the ground truth localizations based on the code diffs generated for an issueâs code base before and after (i.e. the ground truth repair solution) repair in the dataset. For line-level, this is therefore each exact line that is changed in the diff. For function-level, we use any function or class that contains lines from the line-level analysis, and for file-level we use any files that contain modified functions or classes. Note also that while we acknowledge the difference between a method and a function, for reporting purposes we refer to both as âfunctionâ and treat them and any classes that contain them likewise in the experiments. Figure 2 provides examples of how the three degrees of localization would manifest for two erratic lines in a hypothetical repository of two files. 6Joseph Townsend, Chandresh Pravin, Kwun Ho Ngan, and Matthieu Parizy Fig. 2. Fault localization at various levels of granularity, demonstrated in a hypothetical repository containing two sorting methods. The actual fault is in the mergeSort method of merge_sort.py, where n should be replaced with m. At line-level granularity, only these two code lines are provided as context for the repair phase, indicated by the yellow highlight. At function-level, the entire function is provided. And at file-level, the entire merge_sort.py is provided. Table 1. Resolved rates and corresponding standard deviation (í) for code repair using Qwen3-Coder under the Agentless framework on the SWE-Bench-Mini dataset. Repair prompts are derived from ground-truth fault localization at different granularities. Results are averaged over 10 trials. Granularity Resolved Unresolved Completed Resolved Rate (%) í (Rate) Line21.826.848.643.62.6 Function22.827.250.045.61.5 File21.327.548.842.61.6 Given a set of fault localizations, there is also the question of how best to inject these into the prompt. Since it is known that LLMs struggle with counting [34,37,45], we did not consider the option of simply listing line numbers for the repair phase to address in the prompt. Instead we included the actual code lines/functions (plus the 10 lines before and after, for context) as code snippets. The prompt templates may be found in the appendix. 3.4 Evaluation For each of the 3 granularities, we evaluate the pipeline 10 times for each instance, recording whether or not the corresponding issue resolves or if the execution even completes. For each trial, we count the total number of resolutions, failures to resolve, and completions, and calculate the resolve rate as a percentage of the total 50 instances. For each granularity, we average all of these metrics across all 10 trials. 4 Results We consider the results from two perspectives: generalized across all 50 tasks in the dataset, and from the perspective of task difficulty. 4.1 Generalized The results of these experiments are shown in table 1 and figure 3. A Friedman test on the results yieldsí 2 =12.8, í=0.0017, indicating statistical significance. Resolved rate is the highest for the function-level granularity (i.e. for functions, methods and classes). Function-level also boasts the lowest standard deviation of the three granularities, indicating that it is the most stable over repeated runs. Given that this is the level of granularity at which Qwen3-Coder A Study on the Impact of Fault localization Granularity for Repository-Scale Code Repair Tasks7 Fig. 3. Box plot of resolve rate achieved for different granularities of perfect fault localization as reported in table 1 is trained, this is perhaps to be expected, but it would be worth verifying in future work whether or not this holds true for other models. In other words, is there empirical evidence that coding LLMs perform best at the level of granularity on which they were trained? Resolved rate is lowest for file-level granularity. Line-level yields the lowest standard deviation across 10 trials, indicating that its performance is the least stable. Note also that the best resolve rate we achieve is below the 50% mark, over 20% behind the state-of-the-art achieved by Claude Sonnet 4.5 5 . This indicates a very important point: that even perfect fault localization does not necessarily yield good code repair. 4.2 Split by difficulty Furthermore, figure 4 stratifies the resolve rate by instance difficulty, as labelled in the SWE-Bench Verified metadata based on the time taken by a human annotator to resolve each issue. Whilst function-level granularity dominates on average, the relative ordering across granularities shifts with difficulty tier, suggesting that the optimal level of localization granularity is not fixed but instance-dependent. This finding motivates further investigation into whether difficulty-aware or adaptive granularity selection could improve repair outcomes beyond what any single fixed granularity achieves. 5 Limitations This study is not intended to achieve the state-of-the-art code repair performance on SWE-Bench-Mini or similar benchmarks. Nor is our approach intended to represent a full agentic repair system as presented in other work. Instead, 5 https://hal.cs.princeton.edu/swebench_verified_mini, checked on 31st March 2026. 8Joseph Townsend, Chandresh Pravin, Kwun Ho Ngan, and Matthieu Parizy Fig. 4. Mean resolution rate by problem difficulty tier and localization granularity. Difficulty is inferred from human annotator resolution time as provided in the SWE-Bench Verified metadata. Results are averaged over 10 trials per granularity. we focus specifically on understanding how fault localization, and in turn the generated context, affects automatic program repair, and present our findings as a preliminary proof of concept in this research direction. Based on this objective, we deliberately simplified the APR pipeline and excluded factors such as test-time scaling (TTS), prompt engineering, and action planning as implemented in conventional coding agents. Although these components may improve resolution performance, these factors would also introduce additional confounding variability making it hard to isolate the contribution purely from fault localization granularity. This study is also limited by the definition of "perfect" fault localization. We approximate this by using the set of code changes appearing in the associated pull request. This however may ignore code that may actually be relevant to the fault as context but does not require modification for issue resolution. Determining which code is truly relevant to an issue remains an open research question and lies beyond the scope of this paper. 6 Future Directions Perhaps the most logical next step is to observe whether these observations extend to the larger SWE-Bench Verified from which the mini dataset is derived, especially since SWE-Bench mini contains instances from only 2 public repositories out of the total 12 used in SWE-Bench Verified. That said, recently significant weaknesses of SWE-Bench Verified as a means of evaluation have been identified by its curators 6 , arguing that SWE-Bench Pro 7 may now be a more suitable benchmark. Regardless of which is more suitable, the real concern as that the experiments in this paper should be repeated on even larger benchmarks. Similar evaluation with other coder models would also be welcome. In particular this would be useful to evaluate the hypothesis that suitable granularity for repair aligns with the granularity on which the models were trained. Also worth exploring would be combinations of some of the granularities discussed, for example combining function- level and file-level by extracting code blocks at the function level and commenting the code lines identified in the original line-level ground truth. Another variable related to how localization information is presented is the context window, and the impact of this on performance would also be interesting to explore. 6 https://openai.com/index/why-we-no-longer-evaluate-swe-bench-verified/ 7 https://labs.scale.com/leaderboard/swe_bench_pro_public A Study on the Impact of Fault localization Granularity for Repository-Scale Code Repair Tasks9 More generally, a wider exploration of the relationship between a prompt template and resolve rate would also be beneficial, but also very challenging. There are many factors other than localization granularity to consider such as whether or not to include error traces, issue descriptions, etc. The space of possible prompt templates is astronomically large. If we are going to continue injecting knowledge into code repair prompts, a more systematic approach for searching the space of possible templates is needed, and as much as possible the question of what template is appropriate for the APR must be isolated from the question of how reliable the injected knowledge is (for example, by using ground truths when that knowledge is the localized faults). Finally, future work should also incorporate the fault localization module from the original Agentless framework [33] into the experiments, in order to compare Agentlessâ localization quality against our proxy for perfect localization and to analyze any additional contextual information it identifies. 7 Conclusions We have shown that for the SWE-Bench-Mini benchmark, when repaired using Qwen3-Coder in the Agentless framework [33], function-level granularity fault localization yields the highest overall resolve rate when that localization data is input as context to the repair prompt. This level of granularity also offers the best stability, as over 10 trials the variation of resolve rate was the smallest. In comparison, file-level localization yielded the lowest resolve rate and line-level the greatest variation. That being said, these findings are a generalization over the dataset. A deeper dive into how results vary with respect to difficulty suggested that the impact of fault localization is more complex, and that the ideal granularity may in fact depend on the task itself. The next logical step for future work is to observe whether these same conclusions hold true for other, larger repository-level datasets, for other coding models, and for other variations on prompt template. We are the first to conduct a fault granularity analysis under the perfect localization assumption on SWE-Bench-Mini, or on any repository-scale automatic code repair task. This was not an attempt to improve on the state-of-the-art or compare against other architectures. Rather, we hope our experiments encourage others in the field to exercise caution when selecting an appropriate degree of granularity when localizing faults for injection into code repair prompts, and recommend preliminary tests under the perfect localization assumption to this end. Acknowledgements This work would not have been possible without valuable insight from Yuheng Huang and Ao Peng from the University of Tokyo. The formerâs work on fault localization [12] inspired and informed our own venture into the field, and discussions with both since then have influenced the ideas covered in this paper. The authors would also like to thank their colleagues Shanshan Yu and Satoshi Munakata for facilitating these discussions between research teams. References [1]Daman Arora, Atharv Sonwane, Nalin Wadhwa, Abhav Mehrotra, Saiteja Utpala, Ramakrishna Bairi, Aditya Kanade, and Nagarajan Natarajan. 2024. MASAI: Modular Architecture for Software-engineering AI Agents. arXiv:2406.11638 [cs.AI] https://arxiv.org/abs/2406.11638 [2]Jacob Austin, Augustus Odena, Maxwell Nye, Maarten Bosma, Henryk Michalewski, David Dohan, Ellen Jiang, Carrie Cai, Michael Terry, Quoc Le, et al. 2021. Program Synthesis with Large Language Models. arXiv preprint arXiv:2108.07732 (2021). [3]Islem Bouzenia, Premkumar Devanbu, and Michael Pradel. 2024. Repairagent: An autonomous, llm-based agent for program repair. arXiv preprint arXiv:2403.17134 (2024). [4]Viola Campos, Ridwan Shariffdeen, Adrian Ulges, and Yannic Noller. 2025. Empirical evaluation of generalizable automated program repair with large language models. arXiv preprint arXiv:2506.03283 (2025). 10Joseph Townsend, Chandresh Pravin, Kwun Ho Ngan, and Matthieu Parizy [5]Heling Cao, Dong Han, Fangzheng Liu, Tianli Liao, Chenyang Zhao, and Jianshu Shi. 2023. Code Similarity and Location-Awareness Automatic Program Repair. Applied Sciences 13, 14 (2023). doi:10.3390/app13148519 [6]Ruisheng Cao, Mouxiang Chen, Jiawei Chen, Zeyu Cui, Yunlong Feng, Binyuan Hui, Yuheng Jing, Kaixin Li, Mingze Li, Junyang Lin, Zeyao Ma, Kashun Shum, Xuwu Wang, Jinxi Wei, Jiaxi Yang, Jiajun Zhang, Lei Zhang, Zongmeng Zhang, Wenting Zhao, and Fan Zhou. 2026. Qwen3-Coder-Next Technical Report. arXiv:2603.00729 [cs.CL] https://arxiv.org/abs/2603.00729 [7]Dong Chen, Shaoxin Lin, Muhan Zeng, Daoguang Zan, Jian-Gang Wang, Anton Cheshkov, Jun Sun, Hao Yu, Guoliang Dong, Artem Aliev, et al. 2024. Coder: Issue resolving with multi-agent and task graphs. arXiv preprint arXiv:2406.01304 (2024). [8]Mark Chen, Jerry Tworek, Heewoo Jun, Qiming Yuan, Henrique Ponde de Oliveira Pinto, Jared Kaplan, Harri Edwards, Yuri Burda, Nicholas Joseph, Greg Brockman, Alex Ray, Raul Puri, Gretchen Krueger, Michael Petrov, Heidy Khlaaf, Girish Sastry, Pamela Mishkin, Brooke Chan, Scott Gray, Nick Ryder, Mikhail Pavlov, Alethea Power, Lukasz Kaiser, Mohammad Bavarian, Clemens Winter, Philippe Tillet, Felipe Petroski Such, Dave Cummings, Matthias Plappert, Fotios Chantzis, Elizabeth Barnes, Ariel Herbert-Voss, William Hebgen Guss, Alex Nichol, Alex Paino, Nikolas Tezak, Jie Tang, Igor Babuschkin, Suchir Balaji, Shantanu Jain, William Saunders, Christopher Hesse, Andrew N. Carr, Jan Leike, Josh Achiam, Vedant Misra, Evan Morikawa, Alec Radford, Matthew Knight, Miles Brundage, Mira Murati, Katie Mayer, Peter Welinder, Bob McGrew, Dario Amodei, Sam McCandlish, Ilya Sutskever, and Wojciech Zaremba. 2021. Evaluating Large Language Models Trained on Code. arXiv:2107.03374 [cs.LG] [9]DeepSeek-AI, Qihao Zhu, Daya Guo, Zhihong Shao, Dejian Yang, Peiyi Wang, Runxin Xu, Y. Wu, Yukun Li, Huazuo Gao, Shirong Ma, Wangding Zeng, Xiao Bi, Zihui Gu, Hanwei Xu, Damai Dai, Kai Dong, Liyue Zhang, Yishi Piao, Zhibin Gou, Zhenda Xie, Zhewen Hao, Bingxuan Wang, Junxiao Song, Deli Chen, Xin Xie, Kang Guan, Yuxiang You, Aixin Liu, Qiushi Du, Wenjun Gao, Xuan Lu, Qinyu Chen, Yaohui Wang, Chengqi Deng, Jiashi Li, Chenggang Zhao, Chong Ruan, Fuli Luo, and Wenfeng Liang. 2024. DeepSeek-Coder-V2: Breaking the Barrier of Closed-Source Models in Code Intelligence. arXiv:2406.11931 [cs.SE] https://arxiv.org/abs/2406.11931 [10] Daniel Fried, Armen Aghajanyan, Jessy Lin, Sida Wang, Eric Wallace, Freda Shi, Ruiqi Zhong, Wen tau Yih, Luke Zettlemoyer, and Mike Lewis. 2023. InCoder: A Generative Model for Code Infilling and Synthesis. arXiv:2204.05999 [cs.SE] https://arxiv.org/abs/2204.05999 [11]Daya Guo, Qihao Zhu, Dejian Yang, Zhenda Xie, Kai Dong, Wentao Zhang, Guanting Chen, Xiao Bi, Y. Wu, Y. K. Li, Fuli Luo, Yingfei Xiong, and Wen- feng Liang. 2024. DeepSeek-Coder: When the Large Language Model Meets Programming â The Rise of Code Intelligence. arXiv:2401.14196 [cs.SE] https://arxiv.org/abs/2401.14196 [12]Yuheng Huang, Lei Ma, Keizaburo Nishikino, and Takumi Akazaki. 2025. Risk assessment framework for code llms via leveraging internal states. In Proceedings of the 33rd ACM International Conference on the Foundations of Software Engineering. 432â443. [13]Binyuan Hui, Jian Yang, Zeyu Cui, Jiaxi Yang, Dayiheng Liu, Lei Zhang, Tianyu Liu, Jiajun Zhang, Bowen Yu, Keming Lu, Kai Dang, Yang Fan, Yichang Zhang, An Yang, Rui Men, Fei Huang, Bo Zheng, Yibo Miao, Shanghaoran Quan, Yunlong Feng, Xingzhang Ren, Xuancheng Ren, Jingren Zhou, and Junyang Lin. 2024. Qwen2.5-Coder Technical Report. arXiv:2409.12186 [cs.CL] https://arxiv.org/abs/2409.12186 [14]Carlos E. Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, and Karthik Narasimhan. 2024. SWE-bench: Can Language Models Resolve Real-World GitHub Issues? arXiv:2310.06770 [cs.CL] https://arxiv.org/abs/2310.06770 [15] Woosuk Kwon, Zhuohan Li, Siyuan Zhuang, Ying Sheng, Lianmin Zheng, Cody Hao Yu, Joseph E. Gonzalez, Hao Zhang, and Ion Stoica. 2023. Efficient Memory Management for Large Language Model Serving with PagedAttention. In Proceedings of the ACM SIGOPS 29th Symposium on Operating Systems Principles. [16]Junjie Li, Fazle Rabbi, Cheng Cheng, Aseem Sangalay, Yuan Tian, and Jinqiu Yang. 2025. An Exploratory Study on Fine-Tuning Large Language Models for Secure Code Generation. arXiv:2408.09078 [cs.SE] https://arxiv.org/abs/2408.09078 [17] Kui Liu, Anil Koyuncu, TegawendĂŠ F. BissyandĂŠ, Dongsun Kim, Jacques Klein, and Yves Le Traon. 2019. You Cannot Fix What You Cannot Find! An Investigation of Fault Localization Bias in Benchmarking Automated Program Repair Systems. arXiv:1812.07283 [cs.SE] https://arxiv.org/abs/1812. 07283 [18]Yizhou Liu, Pengfei Gao, Xinchen Wang, Jie Liu, Yexuan Shi, Zhao Zhang, and Chao Peng. 2024. Marscode agent: Ai-native automated bug fixing. arXiv preprint arXiv:2409.00899 (2024). [19] Anton Lozhkov, Raymond Li, Loubna Ben Allal, Federico Cassano, Joel Lamy-Poirier, Nouamane Tazi, Ao Tang, Dmytro Pykhtar, Jiawei Liu, Yuxiang Wei, Tianyang Liu, Max Tian, Denis Kocetkov, Arthur Zucker, Younes Belkada, Zijian Wang, Qian Liu, Dmitry Abulkhanov, Indraneil Paul, Zhuang Li, Wen-Ding Li, Megan Risdal, Jia Li, Jian Zhu, Terry Yue Zhuo, Evgenii Zheltonozhskii, Nii Osae Osae Dade, Wenhao Yu, Lucas KrauĂ, Naman Jain, Yixuan Su, Xuanli He, Manan Dey, Edoardo Abati, Yekun Chai, Niklas Muennighoff, Xiangru Tang, Muhtasham Oblokulov, Christopher Akiki, Marc Marone, Chenghao Mou, Mayank Mishra, Alex Gu, Binyuan Hui, Tri Dao, Armel Zebaze, Olivier Dehaene, Nicolas Patry, Canwen Xu, Julian McAuley, Han Hu, Torsten Scholak, Sebastien Paquet, Jennifer Robinson, Carolyn Jane Anderson, Nicolas Chapados, Mostofa Patwary, Nima Tajbakhsh, Yacine Jernite, Carlos MuĂąoz Ferrandis, Lingming Zhang, Sean Hughes, Thomas Wolf, Arjun Guha, Leandro von Werra, and Harm de Vries. 2024. StarCoder 2 and The Stack v2: The Next Generation. arXiv:2402.19173 [cs.SE] https://arxiv.org/abs/2402.19173 [20] Yingwei Ma, Rongyu Cao, Yongchang Cao, Yue Zhang, Jue Chen, Yibo Liu, Yuchen Liu, Binhua Li, Fei Huang, and Yongbin Li. 2025. SWE-GPT: A Process-Centric Language Model for Automated Software Improvement. Proceedings of the ACM on Software Engineering 2, ISSTA (2025), 2362â2383. [21]Martin Monperrus. 2018. Automatic Software Repair: A Bibliography. ACM Comput. Surv. 51, 1, Article 17 (Jan. 2018), 24 pages. doi:10.1145/3105906 [22]Martin Monperrus. 2018. The Living Review on Automated Program Repair. Technical Report hal-01956501. HAL Archives Ouvertes. https: //hal.science/hal-01956501 [23]Joon Park, Kyohei Atarashi, Koh Takeuchi, and Hisashi Kashima. 2025. Emulating Retrieval Augmented Generation via Prompt Engineering for Enhanced Long Context Comprehension in LLMs. arXiv:2502.12462 [cs.CL] https://arxiv.org/abs/2502.12462 A Study on the Impact of Fault localization Granularity for Repository-Scale Code Repair Tasks11 [24]Julian Aron Prenner, Hlib Babii, and Romain Robbes. 2022. Can openaiâs codex fix bugs? an evaluation on quixbugs. In Proceedings of the Third International Workshop on Automated Program Repair. 69â75. [25]Stefano Rando, Luca Romani, Alessio Sampieri, Luca Franco, John Yang, Yuta Kyuragi, Fabio Galasso, and Tatsunori Hashimoto. 2025. LongCodeBench: Evaluating Coding LLMs at 1M Context Windows. arXiv:2505.07897 [cs.CL] https://arxiv.org/abs/2505.07897 [26]Qusay Idrees Sarhan and ĂrpĂĄd BeszĂŠdes. 2022. A Survey of Challenges in Spectrum-Based Software Fault Localization. IEEE Access 10 (2022), 10618â10639. doi:10.1109/ACCESS.2022.3144079 [27]Wei Tao, Yucheng Zhou, Yanlin Wang, Wenqiang Zhang, Hongyu Zhang, and Yu Cheng. 2024. Magis: Llm-based multi-agent framework for github issue resolution. Advances in Neural Information Processing Systems 37 (2024), 51963â51993. [28] Nalin Wadhwa, Atharv Sonwane, Daman Arora, Abhav Mehrotra, Saiteja Utpala, Ramakrishna B Bairi, Aditya Kanade, and Nagarajan Natarajan. 2024. MASAI: Modular Architecture for Software-engineering AI Agents. In NeurIPS 2024 Workshop on Open-World Agents. https://openreview.net/ forum?id=NSINt8lLYB [29]Weishi Wang, Yue Wang, Shafiq Joty, and Steven CH Hoi. 2023. Rap-gen: Retrieval-augmented patch generation with codet5 for automatic program repair. In Proceedings of the 31st ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering. 146â158. [30]Xingyao Wang, Boxuan Li, Yufan Song, Frank F Xu, Xiangru Tang, Mingchen Zhuge, Jiayi Pan, Yueqi Song, Bowen Li, Jaskirat Singh, et al.2024. Openhands: An open platform for ai software developers as generalist agents. arXiv preprint arXiv:2407.16741 (2024). [31]Zora Zhiruo Wang, Akari Asai, Xinyan Velocity Yu, Frank F. Xu, Yiqing Xie, Graham Neubig, and Daniel Fried. 2025. CodeRAG-Bench: Can Retrieval Augment Code Generation? arXiv:2406.14497 [cs.SE] https://arxiv.org/abs/2406.14497 [32]Yuxiang Wei, Olivier Duchenne, Jade Copet, Quentin Carbonneaux, Lingming Zhang, Daniel Fried, Gabriel Synnaeve, Rishabh Singh, and Sida I Wang. 2025. Swe-rl: Advancing llm reasoning via reinforcement learning on open software evolution. arXiv preprint arXiv:2502.18449 (2025). [33]Chunqiu Steven Xia, Yinlin Deng, Soren Dunn, and Lingming Zhang. 2025. Demystifying llm-based software engineering agents. Proceedings of the ACM on Software Engineering 2, FSE (2025), 801â824. [34]Nan Xu and Xuezhe Ma. 2025. Llm the genius paradox: A linguistic and math expertâs struggle with simple word-based counting problems. In Proceedings of the 2025 Conference of the Nations of the Americas Chapter of the Association for Computational Linguistics: Human Language Technologies (Volume 1: Long Papers). 3344â3370. [35] An Yang, Anfeng Li, Baosong Yang, Beichen Zhang, Binyuan Hui, Bo Zheng, Bowen Yu, Chang Gao, Chengen Huang, Chenxu Lv, Chujie Zheng, Dayiheng Liu, Fan Zhou, Fei Huang, Feng Hu, Hao Ge, Haoran Wei, Huan Lin, Jialong Tang, Jian Yang, Jianhong Tu, Jianwei Zhang, Jianxin Yang, Jiaxi Yang, Jing Zhou, Jingren Zhou, Junyang Lin, Kai Dang, Keqin Bao, Kexin Yang, Le Yu, Lianghao Deng, Mei Li, Mingfeng Xue, Mingze Li, Pei Zhang, Peng Wang, Qin Zhu, Rui Men, Ruize Gao, Shixuan Liu, Shuang Luo, Tianhao Li, Tianyi Tang, Wenbiao Yin, Xingzhang Ren, Xinyu Wang, Xinyu Zhang, Xuancheng Ren, Yang Fan, Yang Su, Yichang Zhang, Yinger Zhang, Yu Wan, Yuqiong Liu, Zekun Wang, Zeyu Cui, Zhenru Zhang, Zhipeng Zhou, and Zihan Qiu. 2025. Qwen3 Technical Report. arXiv:2505.09388 [cs.CL] https://arxiv.org/abs/2505.09388 [36] 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:2506.23749 [cs.SE] https://arxiv.org/abs/2506.23749 [37]Haotong Yang, Yi Hu, Shijia Kang, Zhouchen Lin, and Muhan Zhang. 2024. Number cookbook: Number understanding of language models and how to improve it. arXiv preprint arXiv:2411.03766 (2024). [38]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. [39]John Yang, Carlos E. Jimenez, Alex L. Zhang, Kilian Lieret, Joyce Yang, Xindi Wu, Ori Press, Niklas Muennighoff, Gabriel Synnaeve, Karthik R. Narasimhan, Diyi Yang, Sida I. Wang, and Ofir Press. 2024. SWE-bench Multimodal: Do AI Systems Generalize to Visual Software Domains? arXiv:2410.03859 [cs.CL] https://arxiv.org/abs/2410.03859 [40]Yaopeng Yang, Chuanyi Li, Zhifeng Han, Rui Li, Kui Xu, Qingyuan Li, Wenkang Zhong, Zongwen Shen, Zhiwei Fei, Jidong Ge, and Bin Luo. 2025. Patch Generation in APR: A Survey from the Perspectives of Utilizing LLMs and Using APR-Specific Information. ACM Trans. Softw. Eng. Methodol. (Aug. 2025). doi:10.1145/3764584 Just Accepted. [41]Howard Yen, Tianyu Gao, Minmin Hou, Ke Ding, Daniel Fleischer, Peter Izsak, Moshe Wasserblat, and Danqi Chen. 2025. HELMET: How to Evaluate Long-Context Language Models Effectively and Thoroughly. arXiv:2410.02694 [cs.CL] https://arxiv.org/abs/2410.02694 [42]Quanjun Zhang, Chunrong Fang, Yuxiang Ma, Weisong Sun, and Zhenyu Chen. 2023. A Survey of Learning-based Automated Program Repair. ACM Trans. Softw. Eng. Methodol. 33, 2, Article 55 (Dec. 2023), 69 pages. doi:10.1145/3631974 [43]Quanjun Zhang, Chunrong Fang, Yang Xie, YuXiang Ma, Weisong Sun, Yun Yang, and Zhenyu Chen. 2024. A systematic literature review on large language models for automated program repair. arXiv preprint arXiv:2405.01466 (2024). [44]Sheng Zhang, Yifan Ding, Shuquan Lian, Shun Song, and Hui Li. 2025. CodeRAG: Finding Relevant and Necessary Knowledge for Retrieval- Augmented Repository-Level Code Completion. In Proceedings of the 2025 Conference on Empirical Methods in Natural Language Processing, Christos Christodoulopoulos, Tanmoy Chakraborty, Carolyn Rose, and Violet Peng (Eds.). Association for Computational Linguistics, Suzhou, China, 23278â23288. doi:10.18653/v1/2025.emnlp-main.1187 [45]Xiang Zhang, Juntai Cao, and Chenyu You. 2024. Counting ability of large language models and impact of tokenization. arXiv preprint arXiv:2410.19730 (2024). 12Joseph Townsend, Chandresh Pravin, Kwun Ho Ngan, and Matthieu Parizy [46]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. [47]Hasen ĂzaytĂźrk and Feza Buzluca. 2025. AutoStructor: A Generative AI-Based Framework for Automated Program Repair with Deep Learning- Guided Fault Localization. In 2025 10th International Conference on Computer Science and Engineering (UBMK). 1193â1198. doi:10.1109/UBMK67458. 2025.11206755 A Appendix A.1 Prompt Template Source file context constructed from fault localization output; granularity varies from file-level (entire file) to function- level (relevant functions with context window) to line-level (specific line intervals with context window). The prompt used for by the repair agent is as follows: We are currently solving the following issue within our repository. Here is the issue text: --- BEGIN ISSUE --- problem_statement --- END ISSUE --- Below are some code segments , each from a relevant file. One or more of these files may contain bugs. --- BEGIN FILE --- ``` content ``` --- END FILE --- Generate *SEARCH/REPLACE* edits to fix the issue. DO NOT include any explanations or analysis. ONLY output the code block. Every *SEARCH/REPLACE* edit must use this format: 1. The file path 2. The start of search block: <<<<<<< SEARCH 3. A contiguous chunk of lines to search for in the existing source code 4. The dividing line: ======= 5. The lines to replace into the source code 6. The end of the replace block: >>>>>>> REPLACE EXAMPLE OUTPUT (this is the ONLY acceptable format): ```python ### mathweb/flask/app.py <<<<<<< SEARCH from flask import Flask ======= A Study on the Impact of Fault localization Granularity for Repository-Scale Code Repair Tasks13 import math from flask import Flask >>>>>>> REPLACE ``` REQUIREMENTS: - NO text before or after the```python...``` code block - PROPER INDENTATION is required - Start your response directly with```python Note: Terms in braces denote variable placeholders substituted at inference time. PlaceholderDescription problem_statementThe GitHub issue text provided as task input contentSource file contents provided for repair 14Joseph Townsend, Chandresh Pravin, Kwun Ho Ngan, and Matthieu Parizy A.2 Line-level Granularity Content Example Theproblem_statementandcontentplaceholders at line-level granularity for instancedjango__djangoâ11848 are shown below. Line-level localization identifies the modified line ranges, but we expand these into small code snippets, because LLMs require some form of surrounding context to generate valid edits. problem_statement: django.utils.http.parse_http_date two digit year check is incorrect Description (last modified by Ad Timmering) RFC 850 does not mention this , but in RFC 7231 (and there's something similar in RFC 2822) , there's the following quote: Recipients of a timestamp value in rfc850 -date format , which uses a two -digit year , MUST interpret a timestamp that appears to be more than 50 years in the future as representing the most recent year in the past that had the same last two digits. Current logic is hard coded to consider 0-69 to be in 2000 -2069 , and 70-99 to be 1970 -1999 , instead of comparing versus the current year. content: ### django/utils/http.py ... """ # email.utils.parsedate () does the job for RFC1123 dates; unfortunately # RFC7231 makes it mandatory to support RFC850 dates too. So we roll # our own RFC -compliant parsing. for regex in RFC1123_DATE , RFC850_DATE , ASCTIME_DATE: m = regex.match(date) if m is not None: break else: raise ValueError ("%r is not in a valid HTTP date format" % date) try: year = int(m.group('year')) if year < 100: if year < 70: year += 2000 else: year += 1900 A Study on the Impact of Fault localization Granularity for Repository-Scale Code Repair Tasks15 month = MONTHS.index(m.group('mon').lower ()) + 1 day = int(m.group('day')) hour = int(m.group('hour')) min = int(m.group('min')) sec = int(m.group('sec')) result = datetime.datetime(year , month , day , hour , min , sec) return calendar.timegm(result.utctimetuple ()) except Exception as exc: raise ValueError ("%r is not a valid date" % date) from exc def parse_http_date_safe(date): """ Same as parse_http_date , but return None if the input is invalid. """ try: return parse_http_date(date) ... 16Joseph Townsend, Chandresh Pravin, Kwun Ho Ngan, and Matthieu Parizy A.3 Function-level Granularity Content Example Theproblem_statementandcontentplaceholders at function-level granularity for instancedjango__djangoâ11848 are shown below. problem_statement: django.utils.http.parse_http_date two digit year check is incorrect Description (last modified by Ad Timmering) RFC 850 does not mention this , but in RFC 7231 (and there's something similar in RFC 2822) , there's the following quote: Recipients of a timestamp value in rfc850 -date format , which uses a two -digit year , MUST interpret a timestamp that appears to be more than 50 years in the future as representing the most recent year in the past that had the same last two digits. Current logic is hard coded to consider 0-69 to be in 2000 -2069 , and 70-99 to be 1970 -1999 , instead of comparing versus the current year. ... content: ... ### django/utils/http.py ... `epoch_seconds` is a floating point number expressed in seconds since the epoch , in UTC - such as that outputted by time.time(). If set to None , it defaults to the current time. Output a string in the format'Wdy , D Mon Y H:M:S GMT'. """ return formatdate(epoch_seconds , usegmt=True) def parse_http_date(date): """ Parse a date format as specified by HTTP RFC7231 section 7.1.1.1. The three formats allowed by the RFC are accepted , even if only the first one is still in widespread use. A Study on the Impact of Fault localization Granularity for Repository-Scale Code Repair Tasks17 Return an integer expressed in seconds since the epoch , in UTC. """ # email.utils.parsedate () does the job for RFC1123 dates; unfortunately # RFC7231 makes it mandatory to support RFC850 dates too. So we roll # our own RFC -compliant parsing. for regex in RFC1123_DATE , RFC850_DATE , ASCTIME_DATE: m = regex.match(date) if m is not None: break else: raise ValueError ("%r is not in a valid HTTP date format" % date) try: year = int(m.group('year')) if year < 100: if year < 70: year += 2000 else: year += 1900 month = MONTHS.index(m.group('mon').lower ()) + 1 day = int(m.group('day')) hour = int(m.group('hour')) min = int(m.group('min')) sec = int(m.group('sec')) result = datetime.datetime(year , month , day , hour , min , sec) return calendar.timegm(result.utctimetuple ()) except Exception as exc: raise ValueError ("%r is not a valid date" % date) from exc def parse_http_date_safe(date): """ Same as parse_http_date , but return None if the input is invalid. """ try: return parse_http_date(date) except Exception: pass ... 18Joseph Townsend, Chandresh Pravin, Kwun Ho Ngan, and Matthieu Parizy A.4 File-level Granularity Content Example Theproblem_statementandcontentplaceholders at file-level granularity for instancedjango__djangoâ11848 are shown below. problem_statement: django.utils.http.parse_http_date two digit year check is incorrect Description (last modified by Ad Timmering) RFC 850 does not mention this , but in RFC 7231 (and there's something similar in RFC 2822) , there's the following quote: Recipients of a timestamp value in rfc850 -date format , which uses a two -digit year , MUST interpret a timestamp that appears to be more than 50 years in the future as representing the most recent year in the past that had the same last two digits. Current logic is hard coded to consider 0-69 to be in 2000 -2069 , and 70-99 to be 1970 -1999 , instead of comparing versus the current year. content: ### django/utils/http.py ... import base64 import calendar import datetime import re import unicodedata import warnings from binascii import Error as BinasciiError from email.utils import formatdate from urllib.parse import ( ParseResult , SplitResult , _coerce_args , _splitnetloc , _splitparams , quote , quote_plus , scheme_chars , unquote , unquote_plus , urlencode as original_urlencode , uses_params , ) from django.core.exceptions import TooManyFieldsSent from django.utils.datastructures import MultiValueDict from django.utils.deprecation import RemovedInDjango40Warning from django.utils.functional import keep_lazy_text A Study on the Impact of Fault localization Granularity for Repository-Scale Code Repair Tasks19 # based on RFC 7232, Appendix C ETAG_MATCH = re.compile(rⲠ( # start of string and capture group (?:W/)? # optional weak indicator " # opening quote [^"]* # any sequence of non -quote characters " # end quote ) # end of string and capture group â˛, re.X) MONTHS ='jan feb mar apr may jun jul aug sep oct nov dec'. split () __D = r'(?P<day > 2)' __D2 = r'(?P<day >[ ] )' __M = r'(?P<mon > 3)' __Y = r'(?P<year > 4)' __Y2 = r'(?P<year > 2)' __T = r'(?P<hour > 2) :(?P<min > 2) :(?P<sec > 2)' RFC1123_DATE = re.compile(r' 3, %s %s %s %s GMT$' % (__D , __M , __Y , __T)) RFC850_DATE = re.compile(r' 6,9, %s-%s-%s %s GMT$' % (__D , __M , __Y2 , __T)) ASCTIME_DATE = re.compile(r' 3 %s %s %s %s$' % (__M , __D2 , __T , __Y)) RFC3986_GENDELIMS = ":/?#[]@" RFC3986_SUBDELIMS = "!$&'()*+ ,;=" FIELDS_MATCH = re.compile ('[&;]') @keep_lazy_text def urlquote(url , safe='/'): """ A legacy compatibility wrapper to Python's urllib.parse.quote () function. (was used for unicode handling on Python 2) """ warnings.warn( 'django.utils.http.urlquote () is deprecated in favor of' 'urllib.parse.quote ().', RemovedInDjango40Warning , stacklevel =2, ) return quote(url , safe) 20Joseph Townsend, Chandresh Pravin, Kwun Ho Ngan, and Matthieu Parizy @keep_lazy_text def urlquote_plus(url , safe=â˛): """ A legacy compatibility wrapper to Python's urllib.parse.quote_plus () function. (was used for unicode handling on Python 2) """ warnings.warn( 'django.utils.http.urlquote_plus () is deprecated in favor of' 'urllib.parse.quote_plus () ,', RemovedInDjango40Warning , stacklevel =2, ) return quote_plus(url , safe) @keep_lazy_text def urlunquote(quoted_url): """ A legacy compatibility wrapper to Python's urllib.parse.unquote () function. (was used for unicode handling on Python 2) """ warnings.warn( 'django.utils.http.urlunquote () is deprecated in favor of' 'urllib.parse.unquote ().', RemovedInDjango40Warning , stacklevel =2, ) return unquote(quoted_url) @keep_lazy_text def urlunquote_plus(quoted_url): """ A legacy compatibility wrapper to Python's urllib.parse.unquote_plus () function. (was used for unicode handling on Python 2) """ warnings.warn( 'django.utils.http.urlunquote_plus () is deprecated in favor of' 'urllib.parse.unquote_plus ().', RemovedInDjango40Warning , stacklevel =2, ) return unquote_plus(quoted_url) A Study on the Impact of Fault localization Granularity for Repository-Scale Code Repair Tasks21 def urlencode(query , doseq=False): """ A version of Python's urllib.parse.urlencode () function that can operate on MultiValueDict and non -string values. """ if isinstance(query , MultiValueDict): query = query.lists () elif hasattr(query ,'items'): query = query.items () query_params = [] for key , value in query: if value is None: raise TypeError( "Cannot encode None for key'%s' in a query string. Did you " "mean to pass an empty string or omit the value ?" % key ) elif not doseq or isinstance(value , (str , bytes)): query_val = value else: try: itr = iter(value) except TypeError: query_val = value else: # Consume generators and iterators , when doseq=True , to # work around https :// bugs.python.org/issue31706. query_val = [] for item in itr: if item is None: raise TypeError( "Cannot encode None for key'%s' in a query " "string. Did you mean to pass an empty string or " "omit the value ?" % key ) elif not isinstance(item , bytes): item = str(item) query_val.append(item) query_params.append ((key , query_val)) return original_urlencode(query_params , doseq) 22Joseph Townsend, Chandresh Pravin, Kwun Ho Ngan, and Matthieu Parizy def http_date(epoch_seconds=None): """ Format the time to match the RFC1123 date format as specified by HTTP RFC7231 section 7.1.1.1. `epoch_seconds` is a floating point number expressed in seconds since the epoch , in UTC - such as that outputted by time.time(). If set to None , it defaults to the current time. Output a string in the format'Wdy , D Mon Y H:M:S GMT'. """ return formatdate(epoch_seconds , usegmt=True) def parse_http_date(date): """ Parse a date format as specified by HTTP RFC7231 section 7.1.1.1. The three formats allowed by the RFC are accepted , even if only the first one is still in widespread use. Return an integer expressed in seconds since the epoch , in UTC. """ # email.utils.parsedate () does the job for RFC1123 dates; unfortunately # RFC7231 makes it mandatory to support RFC850 dates too. So we roll # our own RFC -compliant parsing. for regex in RFC1123_DATE , RFC850_DATE , ASCTIME_DATE: m = regex.match(date) if m is not None: break else: raise ValueError ("%r is not in a valid HTTP date format" % date) try: year = int(m.group('year')) if year < 100: if year < 70: year += 2000 else: year += 1900 A Study on the Impact of Fault localization Granularity for Repository-Scale Code Repair Tasks23 month = MONTHS.index(m.group('mon').lower ()) + 1 day = int(m.group('day')) hour = int(m.group('hour')) min = int(m.group('min')) sec = int(m.group('sec')) result = datetime.datetime(year , month , day , hour , min , sec) return calendar.timegm(result.utctimetuple ()) except Exception as exc: raise ValueError ("%r is not a valid date" % date) from exc def parse_http_date_safe(date): """ Same as parse_http_date , but return None if the input is invalid. """ try: return parse_http_date(date) except Exception: pass # Base 36 functions: useful for generating compact URLs def base36_to_int(s): """ Convert a base 36 string to an int. Raise ValueError if the input won't fit into an int. """ # To prevent overconsumption of server resources , reject any # base36 string that is longer than 13 base36 digits (13 digits # is sufficient to base36 -encode any 64-bit integer) if len(s) > 13: raise ValueError (" Base36 input too large ") return int(s, 36) def int_to_base36(i): """ Convert an integer to a base36 string .""" char_set ='0123456789 abcdefghijklmnopqrstuvwxyz' if i < 0: raise ValueError (" Negative base36 conversion input .") 24Joseph Townsend, Chandresh Pravin, Kwun Ho Ngan, and Matthieu Parizy if i < 36: return char_set[i] b36 =Ⲡwhile i != 0: i, n = divmod(i, 36) b36 = char_set[n] + b36 return b36 def urlsafe_base64_encode(s): """ Encode a bytestring to a base64 string for use in URLs. Strip any trailing equal signs. """ return base64.urlsafe_b64encode(s).rstrip(b' =').decode('ascii') def urlsafe_base64_decode(s): """ Decode a base64 encoded string. Add back any trailing equal signs that might have been stripped. """ s = s.encode () try: return base64.urlsafe_b64decode(s.ljust(len(s) + len(s) % 4, b'=')) except (LookupError , BinasciiError) as e: raise ValueError(e) def parse_etags(etag_str): """ Parse a string of ETags given in an If -None -Match or If -Match header as defined by RFC 7232. Return a list of quoted ETags , or ['*'] if all ETags should be matched. """ if etag_str.strip () =='*': return ['*'] else: # Parse each ETag individually , and return any that are valid. etag_matches = (ETAG_MATCH.match(etag.strip ()) for etag in etag_str.split(',')) return [match.group (1) for match in etag_matches if match] A Study on the Impact of Fault localization Granularity for Repository-Scale Code Repair Tasks25 def quote_etag(etag_str): """ If the provided string is already a quoted ETag , return it. Otherwise , wrap the string in quotes , making it a strong ETag. """ if ETAG_MATCH.match(etag_str): return etag_str else: return'"%s"' % etag_str def is_same_domain(host , pattern): """ Return``True`` if the host is either an exact match or a match to the wildcard pattern. Any pattern beginning with a period matches a domain and all of its subdomains. (e.g.``.example.com`` matches``example.com`` and ``foo.example.com``). Anything else is an exact string match. """ if not pattern: return False pattern = pattern.lower () return ( pattern [0] =='.' and (host.endswith(pattern) or host == pattern [1:]) or pattern == host ) def url_has_allowed_host_and_scheme(url , allowed_hosts , require_https=False): """ Return``True`` if the url uses an allowed host and a safe scheme. Always return``False`` on an empty url. If``require_https`` is``True``, only'https' will be considered a valid scheme , as opposed to'http' and'https' with the default ,``False``. 26Joseph Townsend, Chandresh Pravin, Kwun Ho Ngan, and Matthieu Parizy Note: "True" doesn't entail that a URL is "safe". It may still be e.g. quoted incorrectly. Ensure to also use django.utils.encoding.iri_to_uri () on the path component of untrusted URLs. """ if url is not None: url = url.strip () if not url: return False if allowed_hosts is None: allowed_hosts = set() elif isinstance(allowed_hosts , str): allowed_hosts = allowed_hosts # Chrome treats \ completely as / in paths but it could be part of some # basic auth credentials so we need to check both URLs. return ( _url_has_allowed_host_and_scheme(url , allowed_hosts , require_https=require_https) and _url_has_allowed_host_and_scheme(url.replace('\\','/'), allowed_hosts , require_https=require_https) ) def is_safe_url(url , allowed_hosts , require_https=False): warnings.warn( 'django.utils.http.is_safe_url () is deprecated in favor of' 'url_has_allowed_host_and_scheme ().', RemovedInDjango40Warning , stacklevel =2, ) return url_has_allowed_host_and_scheme(url , allowed_hosts , require_https) # Copied from urllib.parse.urlparse () but uses fixed urlsplit () function. def _urlparse(url , scheme=â˛, allow_fragments=True): """ Parse a URL into 6 components: <scheme >://<netloc >/<path >;<params >?<query >#<fragment > Return a 6-tuple: (scheme , netloc , path , params , query , fragment). Note that we don't break the components up in smaller bits (e.g. netloc is a single string) and we don't expand % escapes .""" url , scheme , _coerce_result = _coerce_args(url , scheme) splitresult = _urlsplit(url , scheme , allow_fragments) scheme , netloc , url , query , fragment = splitresult A Study on the Impact of Fault localization Granularity for Repository-Scale Code Repair Tasks27 if scheme in uses_params and';' in url: url , params = _splitparams(url) else: params =Ⲡresult = ParseResult(scheme , netloc , url , params , query , fragment) return _coerce_result(result) # Copied from urllib.parse.urlsplit () with # https :// github.com/python/cpython/pull /661 applied. def _urlsplit(url , scheme=â˛, allow_fragments=True): """ Parse a URL into 5 components: <scheme >://<netloc >/<path >?<query >#<fragment > Return a 5-tuple: (scheme , netloc , path , query , fragment). Note that we don't break the components up in smaller bits (e.g. netloc is a single string) and we don't expand % escapes .""" url , scheme , _coerce_result = _coerce_args(url , scheme) netloc = query = fragment =Ⲡi = url.find(':') if i > 0: for c in url[:i]: if c not in scheme_chars: break else: scheme , url = url[:i]. lower (), url[i + 1:] if url [:2] =='//': netloc , url = _splitnetloc(url , 2) if (('[' in netloc and']' not in netloc) or (']' in netloc and'[' not in netloc)): raise ValueError (" Invalid IPv6 URL") if allow_fragments and'#' in url: url , fragment = url.split('#', 1) if'?' in url: url , query = url.split('?', 1) v = SplitResult(scheme , netloc , url , query , fragment) return _coerce_result(v) def _url_has_allowed_host_and_scheme(url , allowed_hosts , require_https=False): # Chrome considers any URL with more than two slashes to be absolute , but 28Joseph Townsend, Chandresh Pravin, Kwun Ho Ngan, and Matthieu Parizy # urlparse is not so flexible. Treat any url with three slashes as unsafe. if url.startswith ('///'): return False try: url_info = _urlparse(url) except ValueError: # e.g. invalid IPv6 addresses return False # Forbid URLs like http :/// example.com - with a scheme , but without a hostname. # In that URL , example.com is not the hostname but , a path component. However , # Chrome will still consider example.com to be the hostname , so we must not # allow this syntax. if not url_info.netloc and url_info.scheme: return False # Forbid URLs that start with control characters. Some browsers (like # Chrome) ignore quite a few control characters at the start of a # URL and might consider the URL as scheme relative. if unicodedata.category(url [0]) [0] =='C': return False scheme = url_info.scheme # Consider URLs without a scheme (e.g. // example.com/p) to be http. if not url_info.scheme and url_info.netloc: scheme ='http' valid_schemes = ['https'] if require_https else ['http','https'] return ((not url_info.netloc or url_info.netloc in allowed_hosts) and (not scheme or scheme in valid_schemes)) def limited_parse_qsl(qs , keep_blank_values=False , encoding='utf -8', errors='replace', fields_limit=None): """ Return a list of key/value tuples parsed from query string. Copied from urlparse with an additional "fields_limit" argument. Copyright (C) 2013 Python Software Foundation (see LICENSE.python). Arguments: qs: percent -encoded query string to be parsed keep_blank_values: flag indicating whether blank values in percent -encoded queries should be treated as blank strings. A A Study on the Impact of Fault localization Granularity for Repository-Scale Code Repair Tasks29 true value indicates that blanks should be retained as blank strings. The default false value indicates that blank values are to be ignored and treated as if they were not included. encoding and errors: specify how to decode percent -encoded sequences into Unicode characters , as accepted by the bytes.decode () method. fields_limit: maximum number of fields parsed or an exception is raised. None means no limit and is the default. """ if fields_limit: pairs = FIELDS_MATCH.split(qs , fields_limit) if len(pairs) > fields_limit: raise TooManyFieldsSent( 'The number of GET/POST parameters exceeded' 'settings.DATA_UPLOAD_MAX_NUMBER_FIELDS.' ) else: pairs = FIELDS_MATCH.split(qs) r = [] for name_value in pairs: if not name_value: continue nv = name_value.split('=', 1) if len(nv) != 2: # Handle case of a control -name with no equal sign if keep_blank_values: nv.append(â˛) else: continue if nv[1] or keep_blank_values: name = nv[0]. replace('+',â˛) name = unquote(name , encoding=encoding , errors=errors) value = nv[1]. replace('+',â˛) value = unquote(value , encoding=encoding , errors=errors) r.append ((name , value)) return r def escape_leading_slashes(url): """ 30Joseph Townsend, Chandresh Pravin, Kwun Ho Ngan, and Matthieu Parizy If redirecting to an absolute path (two leading slashes), a slash must be escaped to prevent browsers from handling the path as schemaless and redirecting to another host. """ if url.startswith ('//'): url ='/%2F'. format(url [2:]) return url ... A.5 Model Configuration Repair experiments were conducted using a vLLM-served model with the following configuration: ParameterValue âmodel Qwen/Qwen3-Coder-30B-A3B-Instruct âtensor-parallel-size 1 âgpu-memory-utilization 0.95 âmax-num-seqs 32 âmax-model-len 262144 âenable-chunked-prefill True âenable-prefix-caching True âtool-call-parser qwen3_coder âenable-auto-tool-choice True âdtype bfloat16 âport 8000