HIDE: Hierarchical Isolation via Documentation and Evidence for Rustc Bugs

HIDE: Hierarchical Isolation via Documentation and Evidence for Rustc Bugs TIANRONG ZHANG, Peking University Shenzhen Graduate School, China YAKUN ZHANG, Harbin Institute of Technology, Shenzhen, China DAN HAO, Peking University Shenzhen Graduate School, China Rustc bugs can prevent valid programs from compiling or cause incorrect compilation results, making the identification of responsible source files essential for repair. Using large language models (LLMs) for rustc bug isolation raises three challenges. First, distributed compiler functionality requires understanding both what individual files do and how they work together. Second, a large source file

arXiv:2610.37343v1 [cs.SE] 27 Oct 2026

search space makes exhaustive analysis of all files costly. Third, including documentation and source code for many candidate files in LLM prompts leads to context overload, which can reduce bug isolation accuracy. To address these challenges, we propose HIDE, a hierarchical LLM-based approach that combines compiler documentation with bug evidence to rank suspicious rustc source files. Given a rustc revision and a bug context, HIDE consists of two stages that generate compiler documentation and narrow the search space. To understand distributed compiler functionality, the Layered Documentation Aggregation stage summarizes what individual files do and how files with similar functions work together. To reduce the large source file search space, the Hierarchical Bug Isolation stage uses hierarchical candidate selection to reduce the number of files requiring detailed analysis. To mitigate context overload, this stage uses Scoped Candidate Competition and Evidence-Guided Code Slicing to limit the number of candidates and the amount of source code included in each prompt, respectively. We evaluate HIDE on 160 reproducible rustc bugs and compare it with Agentless, SoapFL, and GraphLocator. With GPT-5.4, HIDE achieves 42.08% Accuracy@1 and 80.42% Accuracy@10, exceeding the strongest baseline results by 5.83% and 6.04%, respectively. These results demonstrate that generating compiler documentation, narrowing candidates hierarchically, and limiting analysis context enable effective rustc bug isolation. CCS Concepts: • Software and its engineering → Compilers; Software defect analysis. Additional Key Words and Phrases: Compiler bug isolation, Rust compiler, Large language models, Hierarchical search, Query traces

1

Introduction

Rustc is the primary compiler for Rust, a programming language that combines high execution efficiency with strong memory-safety and concurrency-safety guarantees [13]. Rustc translates source programs while performing checks and analyses to enforce these guarantees. Rustc is therefore expected to compile programs correctly and enforce these guarantees so that Rust software can be built and trusted. However, rustc bugs may terminate compilation, reject valid programs, or accept invalid programs [12]. These failures can block Rust software builds or undermine trust in the compiled software by producing incorrect compilation results. To repair these bugs, developers first need to identify the responsible compiler source files. This task, known as compiler bug isolation (CBI), is challenging in a large, evolving repository with strong dependencies among source files. Effective compiler bug isolation can reduce the costs of understanding the compiler architecture, tracing compilation behavior, and isolating bugs. Existing bug-isolation methods fall into two broad categories: general methods and compiler-specific methods. General methods use semantic relevance, execution behavior, or code dependencies to locate faults and increasingly employ large language models (LLMs) to interpret such evidence [1, 4, 5, 8, 9, 17, 27, 28, 31]. Although broadly applicable, Authors’ Contact Information: Tianrong Zhang, tianrongzhang25@stu.pku.edu.cn, Peking University Shenzhen Graduate School, China; Yakun Zhang, zhangyk@hit.edu.cn, Harbin Institute of Technology, Shenzhen, China; Dan Hao, haodan@pku.edu.cn, Peking University Shenzhen Graduate School, China. 2026. Manuscript submitted to ACM

Manuscript submitted to ACM

1

2

Zhang et al.

they do not explicitly exploit rustc’s source organization and compiler execution behavior. Compiler-specific methods obtain contrasting executions by mutating failing programs, varying compiler configurations, or skipping compilation steps [10, 24, 30]. Although LLM4CBI [24] uses LLMs for tasks such as guiding program mutation, its localization evidence still comes primarily from execution differences, without reasoning about how dependent source files jointly implement compiler functionality. LLM reasoning is therefore not unique to compiler bug isolation. The open problem is how to combine it with rustc-specific structure and execution evidence. This motivates using LLMs to understand compiler source code while exploiting rustc-specific information to guide bug isolation. Using LLMs for rustc bug isolation raises three implementation challenges. First, distributed compiler functionality requires understanding both what individual files do and how they work together. Second, a large source file search space makes exhaustive analysis of all files costly. Third, including documentation and source code for many candidate files in LLM prompts leads to context overload, which can reduce bug isolation accuracy. To address these challenges, we propose HIDE, a hierarchical LLM-based approach that combines compiler documentation with bug evidence to rank suspicious rustc source files. HIDE consists of two stages: Layered Documentation Aggregation and Hierarchical Bug Isolation. Given a rustc revision and a bug context, HIDE generates compiler documentation to guide progressive candidate selection from crates to modules to files. To understand distributed compiler functionality, the Layered Documentation Aggregation stage summarizes what individual files do and how files with similar functions work together. To reduce the large source file search space, the Hierarchical Bug Isolation stage uses hierarchical candidate selection to reduce the number of files requiring detailed analysis. To mitigate context overload, the Hierarchical Bug Isolation stage uses two mechanisms, Scoped Candidate Competition and Evidence-Guided Code Slicing, to limit the number of candidates and the amount of source code included in each prompt, respectively. We evaluate HIDE on 160 reproducible rustc bugs and compare it with Agentless [27], SoapFL [17], and GraphLocator [9], representing semantics-based, execution-based, and dependency-based approaches, respectively. The evaluation yields four main findings. (1) For effectiveness, HIDE achieves 42.08% Accuracy@1 and 80.42% Accuracy@10, exceeding the strongest baseline results by 5.83% and 6.04%, respectively. (2) For efficiency, HIDE averages 154 seconds and 145,413 tokens per bug, achieving the lowest average execution time and consuming substantially fewer tokens than Agentless and SoapFL. (3) For generalizability, HIDE obtains mean Accuracy@10 values between 76.04% and 80.42% with GPT-5.4, Gemini-3.1-Pro-Preview, and DeepSeek-V4-Pro, supporting its robustness across different LLMs. (4) In the ablation study, all ablated variants achieve lower Accuracy@𝑘 than HIDE, supporting the contributions of the proposed stages, components, and mechanisms. Our main contributions are as follows: • We propose HIDE, a hierarchical LLM-based approach that combines compiler documentation with bug evidence to rank suspicious rustc source files. • We propose the Layered Documentation Aggregation stage, which provides hierarchical documentation summarizing what individual files do and how files with similar functions work together. • We propose the Hierarchical Bug Isolation stage, which uses hierarchical candidate selection to reduce the number of files requiring detailed analysis. Its two mechanisms, Scoped Candidate Competition and Evidence-Guided Code Slicing, mitigate context overload by limiting the number of candidates and the amount of source code included in each prompt, respectively. • We conduct a comprehensive evaluation on 160 reproducible rustc bugs with three LLMs and three representative baselines. HIDE achieves the best results at every reported accuracy metric and the lowest average execution Manuscript submitted to ACM

HIDE: Hierarchical Isolation via Documentation and Evidence for Rustc Bugs

3

time. Results across different LLMs support its robustness, while the ablation study supports the contributions of its stages, components, and mechanisms. The code is available at https://github.com/zhangtr02/HIDE. 2

Background

2.1

Rustc Architecture and Query System

We identify two complementary sources of information in rustc that can support bug isolation: its static source organization and dynamic query execution. The static source organization describes the directory structure of the compiler repository and provides candidate search scopes, while dynamic query execution is recorded in query traces that capture the computations involved during compilation. We introduce both because combining code structure with execution evidence can help isolate rustc bugs. Static source organization. Rustc organizes its source files hierarchically [23]. At the highest level, a crate is a directory containing code for a set of compiler functions. For example, the rustc_const_eval crate implements constant evaluation and MIR interpretation. At the next level, a module represented by a subdirectory groups files that implement specific compiler functionality. For example, the transform module within this crate contains code for constant checking, constant promotion, and MIR validation. At the finest level, a file implements concrete checks, analyses, or transformations. For example, the validate.rs file checks MIR structure, types, and storage usage. Dynamic query execution. Rustc organizes compiler computations as queries, each of which takes an input key and returns a result [22]. For example, the type_of query takes the identifier of a program item and returns its type. A query is requested when its result is needed. Rustc reuses a cached result when available and otherwise invokes the function implementing the query. This function may request other queries, creating dependencies between computations. A query trace records query events observed during compilation, providing execution evidence for bug isolation. Taken together, static source organization and dynamic query execution support bug isolation in complementary ways. The former divides compiler files into candidate search scopes, while the latter provides evidence of the computations performed during compilation. They allow us to use execution evidence to guide the search for suspicious files within these scopes. Figure 1(a) illustrates this combination. The nested boxes show the containment of crates, modules, and files. The query nodes and orange arrows illustrate selected query requests when compiling a constant body. The dashed arrow points from the mir_promoted query to the promote_consts.rs file, whose constant promotion code is used during this query. 2.2

Motivating Example

We use Bug 118990 [20] to illustrate the challenges of rustc bug isolation. Following Section 2.1, we examine static source organization and dynamic query execution alongside the bug report, compiler log, and failure program, which is the program that triggers the compiler failure. Figure 1(b) shows this program, explains the incorrect report, summarizes the query trace and the files involved in validation. In the failure program, break exits a block before a temporary CompileError value is created. This type uses Drop to define cleanup when a value is destroyed. With -Zvalidate-mir enabled, rustc checks its mid-level intermediate representation (MIR), an internal form of the program, and terminates with an internal compiler error (ICE). The check reports a cleanup operation on a temporary value whose storage is not active. Since cleanup at this stage is conditional on initialization, the early exit means that this cleanup would not occur. The check overlooks this condition and therefore incorrectly reports an error [21].

Manuscript submitted to ACM

4

Zhang et al. (a) Information for rustc bug isolation Static source organization

Dynamic query execution Orange arrow 𝐴 → 𝐵 means 𝐴 requests 𝐵

rustc_const_eval crate Constant evaluation and MIR interpretation transform module validate.rs file MIR validation promote_consts.rs file Constant promotion Other files in this module

Implementation code used by the query

mir_promoted

mir_const_qualif

mir_const

Example query requests when compiling a constant

mir_built

Nested boxes show directory containment Execution evidence guides candidate selection within directory scopes (b) Motivating Bug 118990 Failure Program struct CompileError; impl Drop for CompileError {...} ’code: { break ’code; CompileError.throw(); }

Validation Error

Query Trace

Reported error Cleanup of a temporary value whose storage is not active.

mir_built — MIR construction

Why the report is incorrect Cleanup would not occur after the early exit.

Early exit skips temporary creation.

mir_borrowck — borrow checking ... These tasks also occur during normal compilation. Their presence does not identify the responsible files.

Validation across files in different crates storage_liveness.rs Provides storage information

validate.rs Checks MIR using storage information

pass_manager.rs Controls when validation runs

Fig. 1. Static and dynamic evidence for rustc bug isolation and motivating Bug 118990.

First, Bug 118990 illustrates the challenge of understanding distributed compiler functionality. Explaining the incorrect report requires understanding both the validation rule and the storage information it relies on. The validate.rs file in the rustc_const_eval crate checks MIR using information about when storage is active, provided by the storage_liveness.rs file in the rustc_mir_dataflow crate. The pass_manager.rs file in the rustc_mir_transform crate controls when validation runs [21]. An LLM must understand how these files work together to judge whether the check accounts for the condition under which cleanup occurs. General bug-isolation methods identify candidate files based on semantic relevance between problem descriptions and code. In this example, isolating the bug further requires understanding how storage information and the timing of validation affect the check.

Manuscript submitted to ACM

HIDE: Hierarchical Isolation via Documentation and Evidence for Rustc Bugs

5

Second, Bug 118990 illustrates the challenge of a large source file search space. The query trace in Figure 1(b) includes mir_built and mir_borrowck, corresponding to MIR construction and borrow checking. These tasks also occur during normal compilation, so their presence alone does not tell us which files caused the failure. Following the code that implements these tasks and its dependencies can lead to many files in different crates and modules. Static source organization groups these files into search scopes, but we still need to decide which scopes and files to inspect. General bug-isolation methods use execution information and code dependencies to reduce the search space. In this example, an LLM must still determine which of the files involved in compilation could be responsible for the bug. Examining every candidate file in detail is costly, making it necessary to narrow the candidates before detailed analysis. Finally, Bug 118990 illustrates the challenge of context overload. An LLM analyzing this bug needs to understand the validation rule, the storage information it relies on, and when validation runs. Including many candidate files in one prompt requires the LLM to assess how each file relates to the failure. Providing complete source code for each candidate also requires it to read code unrelated to the failure. These two demands can make it harder to determine whether cleanup would actually occur. General bug-isolation methods face this difficulty when they include documentation and source code for many candidate files in the same prompt. This example motivates comparing smaller groups of candidate files and focusing on bug-related code within each file. Overall, Bug 118990 illustrates three challenges of rustc bug isolation, namely distributed compiler functionality, a large source file search space, and context overload. Addressing these challenges requires understanding what individual files do and how they work together, narrowing candidates before detailed analysis, and comparing smaller groups of files using bug-related code. These requirements motivate Rustc-CBI, a hierarchical LLM-based approach to rustc bug isolation, which we present in the next section. 3

Approach

Figure 2 presents an overview of HIDE. HIDE is a hierarchical LLM-based approach that combines compiler documentation with bug evidence to rank suspicious rustc source files. Given a rustc revision and a bug context, it progressively narrows candidates from crates to modules to files. HIDE consists of two stages. The Layered Documentation Aggregation stage contains the File-Level Documentation Generation, Module-Level Documentation Generation, and Crate-Level Documentation Generation components. The Hierarchical Bug Isolation stage contains the Crate-Level Bug Isolation, Module-Level Bug Isolation, and File-Level Bug Isolation components. The Layered Documentation Aggregation stage uses LLMs to describe compiler functionality at the file, module, and crate levels. Its three components operate from files to modules and then to crates. The file-level component generates a file doc from each file’s path and source code, the module-level component aggregates file docs within each module, and the crate-level component aggregates module docs within each crate. Together, these docs summarize file functionality and relationships across modules to guide hierarchical search. The Hierarchical Bug Isolation stage uses the docs and bug context to progressively narrow candidates from crates to modules and then to files. At each level, the corresponding component assesses the current candidates, selects a smaller set, and passes its assessments to the next component. Within this stage, the Scoped Candidate Competition mechanism compares files separately within each selected module before global ranking, limiting the number of files considered together. The Evidence-Guided Code Slicing mechanism supplies code slices selected using the bug context instead of complete files, limiting the amount of source code examined.

Manuscript submitted to ACM

6

Zhang et al.

Hierarchical Bug Isolation

Layered Documentation Aggregation

Issue Description

Compiler Log

Query Trace

Crate-Level Bug Isolation

Crate-Level Documentation Generation

Module-Doc Aggregation

Failure Program

Crate Responsibility Synthesis

Bug Relevance Analysis

Crate Candidate Ranking

Module-Level Bug Isolation

Module-Level Documentation Generation

Scoped Candidate Competition File-Doc Module Responsibility Aggregation Synthesis

Bug Relevance Module Candidate Analysis Ranking

File-Level Bug Isolation

File-Level Documentation Generation

Evidence-Guided Code Slicing File Responsibility Synthesis

Same-Name Differentiation Evidence-Term Code Window Extraction Scoring

Top Window Selection

Bug Relevance Final File Suspicious Analysis Ranking Files

Rustc Repository

Fig. 2. Overview of HIDE.

3.1

Layered Documentation Aggregation

The Layered Documentation Aggregation stage summarizes what individual files do and how files with similar functions work together. Given a rustc revision, its three components construct compiler documentation from files to modules and then to crates. File-Level Documentation Generation component summarizes each file’s responsibilities from its repository path and source code, producing file docs D 𝑓 . Module-Level Documentation Generation component aggregates file docs to describe each module’s functionality and how its files work together, producing module docs D𝑚 . Crate-Level Documentation Generation component aggregates module docs to describe each crate’s functionality and how its modules work together, producing crate docs D𝑐 . These file, module, and crate docs serve as inputs to the Hierarchical Bug Isolation stage, which uses them to select candidates at the corresponding levels, as described in Section 3.2. Below, we first describe the three components and then present the prompt design that implements them through a shared template with level-specific inputs and output requirements. The first component, File-Level Documentation Generation, produces a file doc 𝑑 𝑓 (𝑓 ) that summarizes the compiler functionality implemented by each Rust source file 𝑓 . It first performs File Responsibility Synthesis, using the file’s repository path and source code to summarize the checks, analyses, or transformations it implements without focusing on a particular bug. It then performs Same-Name Differentiation, using the file’s repository path and source code to clarify functional differences between files with identical names in different modules or crates. The refined description

Manuscript submitted to ACM

HIDE: Hierarchical Isolation via Documentation and Evidence for Rustc Bugs

7

becomes the file doc. For example, the file doc for the validate.rs file in the rustc_const_eval crate describes its checks of MIR structure, types, and storage usage. The second component, Module-Level Documentation Generation, produces a module doc 𝑑𝑚 (𝑚) that summarizes the compiler functionality implemented by each module 𝑚 and how its files work together. It first performs File-Doc Aggregation, collecting the file docs within the module according to the repository’s directory structure. It then performs Module Responsibility Synthesis, using these file docs to summarize the module’s compiler functionality and how its files work together. The resulting module doc provides a combined summary without repeating every file doc. For example, the module doc for the transform module in the rustc_const_eval crate describes constant checking, constant promotion, and MIR validation. The third component, Crate-Level Documentation Generation, produces a crate doc 𝑑𝑐 (𝑐) that summarizes the compiler functionality implemented by each crate 𝑐 and how its modules work together. It first performs Module-Doc Aggregation, collecting the module docs within the crate according to the repository’s directory structure. It then performs Crate Responsibility Synthesis, using these module docs to summarize the crate’s compiler functionality and how its modules work together. The resulting crate doc provides a combined summary without repeating every module doc. For example, the crate doc for the rustc_const_eval crate describes constant evaluation, MIR interpretation, and MIR validation. We express the generation of module docs and crate docs as follows.
𝑑𝑚 (𝑚) = A {𝑑 𝑓 (𝑓 ) | 𝑓 ∈ 𝑚} ,
𝑑𝑐 (𝑐) = A {𝑑𝑚 (𝑚) | 𝑚 ∈ 𝑐} .

(1) (2)

Here, A denotes LLM-based document aggregation, which summarizes compiler functionality from the input docs. A module doc is generated from the file docs within that module, and a crate doc from the module docs within that crate. Prompt Design. The three components use the shared prompt template in Figure 3, with their inputs, processing, and outputs summarized in Table 1. The template identifies the target file, module, or crate and specifies its level and input content. At the file level, the input contains the repository path and source code, and the prompt asks for the checks, analyses, or transformations implemented by the file and any necessary distinctions between files with identical names. At the module and crate levels, the inputs contain file docs and module docs, respectively, and the prompt asks for the compiler functionality they collectively describe and how the files or modules work together. For each component, the LLM follows the two steps listed in Table 1 to generate the corresponding doc. In summary, the Layered Documentation Aggregation stage provides docs that describe compiler functionality at the file, module, and crate levels, including how files and modules work together. The Hierarchical Bug Isolation stage uses these docs with the bug context to select candidates at each level. 3.2

Hierarchical Bug Isolation

The Hierarchical Bug Isolation stage uses hierarchical candidate selection to reduce the number of files requiring detailed analysis. It combines the docs from the Layered Documentation Aggregation stage with a shared bug context to progressively narrow candidates from crates to modules and then to files, producing a ranked list of suspicious files. To mitigate context overload, it uses two mechanisms. At the module level, the Scoped Candidate Competition mechanism compares files within individual modules before global ranking, limiting the number of candidates considered together. At the file level, the Evidence-Guided Code Slicing mechanism provides bug-related code slices instead of complete files, limiting the amount of source code examined. This stage consists of three components, Crate-Level Bug Isolation, Manuscript submitted to ACM

8

Zhang et al.

Prompt Template You are analyzing the architecture of the rustc compiler. Target level: <level> Target entity: <entity_id> Input content: <input_content> Instructions: Summarize the compiler functionality implemented by the target file, module, or crate. For a file, use its repository path and source code to describe its checks, analyses, or transformations and clarify functional differences between files with identical names. For a module or crate, use the input docs to summarize its compiler functionality and how its files or modules work together. Output: Return a concise structured description. Fig. 3. Prompt template for Layered Documentation Aggregation. Table 1. Prompt design across the three documentation components. Component

Input content

Processing

Output

File-Level Documentation Generation

Repository path and source code

File Responsibility Synthesis Same-Name Differentiation

File doc

File-Doc Aggregation Module Responsibility Synthesis

Module doc

Module-Level Documentation Generation File docs within the target module Crate-Level Documentation Generation

Module docs within the target crate Module-Doc Aggregation Crate Responsibility Synthesis

Crate doc

Module-Level Bug Isolation, and File-Level Bug Isolation, which we describe below after defining the shared bug context. We then present the prompt design shared by the three components and the Scoped Candidate Competition mechanism. All three components use the same bug context, shown on the right side of Figure 2. We represent this context as B = ⟨𝐼, 𝑃, 𝐿, 𝑄⟩,

(3)

where 𝐼 , 𝑃, 𝐿, and 𝑄 denote the issue description, failure program, compiler log, and query trace, respectively. The issue description and failure program describe the failure and its triggering conditions, while the compiler log and query trace provide evidence of compilation behavior and query execution. At each level, the corresponding component uses this bug context with the docs at that level to select candidates. The crate-level and module-level components pass the candidates and the reasons for their selection to the next component to guide further analysis. 3.2.1 Crate-Level Bug Isolation. The first component, Crate-Level Bug Isolation, selects crate candidates for the ModuleLevel Bug Isolation component. It collects all compiler crates in the target rustc revision to form the initial candidate set C. It first performs Crate-Level Bug Relevance Analysis, using the crate docs and bug context to assess whether each crate may be responsible for the bug. It then performs Crate Candidate Ranking, comparing these assessments to rank the crates and select a small set of candidates. Manuscript submitted to ACM

HIDE: Hierarchical Isolation via Documentation and Evidence for Rustc Bugs

9

During Crate-Level Bug Relevance Analysis, the LLM analyzes each crate 𝑐 ∈ C using its crate doc 𝑑𝑐 (𝑐) and the bug context B. Based on the bug context, it assesses whether the compiler functionality described in the crate doc may be responsible for the bug. For each crate, the LLM produces an assessment for use in Crate Candidate Ranking. During Crate Candidate Ranking, the LLM compares the crate-level assessments to rank all crates in C. Crates considered more likely to be responsible for the bug are ranked higher. It selects the top-𝐾𝑐 crates as the candidate set S𝑐 = TopK𝐾𝑐 (C),

(4)

where 𝐾𝑐 is the number of crate candidates, and TopK𝐾𝑐 selects the 𝐾𝑐 highest-ranked crates based on these assessments. The Module-Level Bug Isolation component then searches only the modules within these crate candidates. 3.2.2 Module-Level Bug Isolation. The second component, Module-Level Bug Isolation, selects module candidates within the crate candidates. It collects all modules in the crate candidates S𝑐 to form the initial candidate set M. It first performs Module-Level Bug Relevance Analysis, using the module docs, bug context, and crate-level assessments to assess whether each module may be responsible for the bug. It then performs Module Candidate Ranking, comparing these assessments to rank the modules and select a small set of candidates. The Scoped Candidate Competition mechanism subsequently selects files separately within each module candidate. During Module-Level Bug Relevance Analysis, the LLM analyzes each module 𝑚 ∈ M using its module doc 𝑑𝑚 (𝑚), the bug context B, and the assessment of its owning crate. Based on the bug context and crate-level assessment, it assesses whether the compiler functionality described in the module doc may be responsible for the bug. For each module, the LLM produces an assessment for use in Module Candidate Ranking. During Module Candidate Ranking, the LLM compares the module-level assessments to rank all modules in M. Modules considered more likely to be responsible for the bug are ranked higher. It selects the top-𝐾𝑚 modules as the candidate set S𝑚 = TopK𝐾𝑚 (M),

(5)

where 𝐾𝑚 is the number of module candidates, and TopK𝐾𝑚 selects the 𝐾𝑚 highest-ranked modules based on these assessments. This comparison ranks modules across all crate candidates without requiring each crate to contribute the same number of modules. The Scoped Candidate Competition mechanism then selects files separately within each module candidate, using the module-level assessments to guide the analysis. The Scoped Candidate Competition mechanism limits the number of file candidates considered together by comparing files separately within each module candidate. Comparing all files across module candidates in one prompt would increase the context size and could allow larger modules to dominate the candidate set. For each module candidate 𝑚 ∈ S𝑚 , the LLM analyzes its file set F𝑚 using the file docs, module doc, bug context, and module-level assessment. It compares the compiler functionality described in the file docs to assess whether each file may be responsible for the bug and ranks the files within that module. It selects up to 𝐾𝑠 highest-ranked files as the candidate set W𝑚 = TopK𝐾𝑠 (F𝑚 ),

(6)

where 𝐾𝑠 is the maximum number of file candidates per module, and W𝑚 contains the file candidates selected from module 𝑚. The mechanism combines the file candidates from all module candidates into Ø W= W𝑚 .

(7)

𝑚∈ S𝑚

Manuscript submitted to ACM

10

Zhang et al.

Naive Global Competition Module A 18 files Module B 7 files

Scoped Candidate Competition Module A F𝐴 : 18 files select up to 𝐾𝑠

Global file pool 28 files

Module B F𝐵 : 7 files select up to 𝐾𝑠

Compare all files together

Module C F𝐶 : 3 files select up to 𝐾𝑠

Module C 3 files

File candidates W𝐴 , W𝐵 , W𝐶 Ð W = 𝑚 W𝑚 ↓ File-Level Bug Isolation

Fig. 4. The Scoped Candidate Competition mechanism compared with naive global competition.

The set W contains file candidates from different modules without a global file ranking and is passed to the File-Level Bug Isolation component for further analysis. As shown in Figure 4, selecting files separately within each module limits the candidates considered together while preserving candidates from multiple modules. 3.2.3 File-Level Bug Isolation. The third component, File-Level Bug Isolation, produces the final ranked list of suspicious files. It takes the file candidates W from the Module-Level Bug Isolation component as its initial candidate set. It first uses the Evidence-Guided Code Slicing mechanism to extract code slices from each candidate file based on the bug context, limiting the amount of source code examined. It then performs File-Level Bug Relevance Analysis, using the code slices, file docs, bug context, crate-level assessments, and module-level assessments to assess whether each file may be responsible for the bug. Finally, it performs Final File Ranking, comparing these assessments to rank the files and return the most suspicious files. The Evidence-Guided Code Slicing mechanism consists of three steps, Evidence-Term Extraction, Code Window Scoring, and Top Window Selection, which we describe below. During Evidence-Term Extraction, the mechanism extracts terms from the bug context B, such as identifiers, diagnostic messages, and query names, to construct a weighted term set T . Terms from the compiler log and query trace receive weight 2, whereas terms from the issue description and failure program receive weight 1, giving greater weight to execution evidence. For terms appearing in multiple sources, it uses the highest weight. It also removes overly general terms that cannot distinguish source locations. The resulting set T is used in Code Window Scoring. During Code Window Scoring, the mechanism scores source lines in each candidate file using the weighted terms in T . For a source line 𝑙, the score is 𝑠 (𝑙) =

∑︁

I(𝑡 ∈ 𝑙) 𝑤 (𝑡) + 𝑏 (𝑙),

(8)

𝑡∈T

where I(𝑡 ∈ 𝑙) indicates whether term 𝑡 occurs in line 𝑙, and 𝑤 (𝑡) is the term’s weight. The bonus 𝑏 (𝑙) increases the score of lines containing failure markers such as panic! or assert!. Each line matching an evidence term is grouped with its neighboring lines to form a code window 𝑊 . The window score is the sum of its line scores: ∑︁ 𝑠 (𝑊 ) = 𝑠 (𝑙).

(9)

𝑙 ∈𝑊

Windows receive higher scores when they match more terms, match terms with greater weights, or contain more failure markers. These scores guide Top Window Selection. Manuscript submitted to ACM

HIDE: Hierarchical Isolation via Documentation and Evidence for Rustc Bugs

11

1. Bug Context

2. Evidence-Term Extraction

Bug 118990 Query Trace mir_drops_elaborated_and_const_checked Compiler Log delay_span_bug .../validate.rs

Term set T mir_drops. . . const_checked delay_span_bug validate_mir storage

Failure Setting -Zvalidate-mir

Execution evidence receives the higher weight

3. Code Window Scoring

4. Top Window Selection

validate.rs fn visit_local(...) if storage.is_none() { bug!("no storage here"); }

File Code Slice .../validate.rs lines 𝐿𝑖 –𝐿 𝑗

Evidence-term matches + failure-marker bonus

Windows with the highest scores selected within the code budget per file

Weight [2] [2] [2] [1] [1]

visit_local(...) storage.is_none() "no storage here"

Fig. 5. Evidence-Guided Code Slicing illustrated with Bug 118990.

During Top Window Selection, the mechanism ranks each file’s code windows by 𝑠 (𝑊 ). It selects the windows with the highest scores within a predefined budget for the amount of code extracted from each file. The selected code is presented in source order with the file path and line-number ranges, forming the code slices used in File-Level Bug Relevance Analysis. Files without matching evidence terms are analyzed and ranked using their file docs and other available evidence, without code slices. Figure 5 illustrates this procedure for Bug 118990. During File-Level Bug Relevance Analysis, the LLM analyzes each file 𝑓 ∈ W using its file doc, available code slices, the bug context B, crate-level assessments, and module-level assessments. Based on the bug context and these assessments, it examines the compiler functionality described in the file doc and the implementation details in the available code slices to assess whether the file may be responsible for the bug. For each file, the LLM produces an assessment for use in Final File Ranking. During Final File Ranking, the LLM compares the file-level assessments to rank all files in W across modules. Files considered more likely to be responsible for the bug are ranked higher. It selects the top-𝐾 𝑓 files to form the final ranked list S𝑓 = TopK𝐾 𝑓 (W),

(10)

where 𝐾 𝑓 is the number of suspicious files returned, and TopK𝐾 𝑓 selects the 𝐾 𝑓 highest-ranked files based on these assessments. HIDE returns the ranked list S𝑓 with a brief reason for selecting each file. This list corresponds to the suspicious files in Figure 2.

Manuscript submitted to ACM

12

Zhang et al.

Prompt Template You are isolating the source files responsible for a rustc compiler bug. Isolation level: <level> Bug context: <bug_context> Upstream results: <upstream_results> Candidate documentation: <candidate_docs> Code evidence: <code_slices> Output size: <K> Instructions: Analyze how each candidate’s responsibility relates to the observed failure. Distinguish candidates that directly expose the symptom, intermediate compiler phases that propagate it, and upstream components that may introduce the root cause. Output: Return exactly <K> valid candidate IDs, or up to <K> for Scoped Candidate Competition. Order them from most to least relevant to the bug’s root cause. For each candidate, provide a concise reason grounded in the bug context and the supplied documentation or code evidence. Fig. 6. Prompt template for Hierarchical Bug Isolation. Table 2. Prompt design across the three isolation components and the scoped candidate competition mechanism. Component or mechanism

Input content

Processing

Output

Crate-Level Bug Isolation

Bug context and crate docs

Crate-Level Bug Relevance Analysis Crate Candidate Ranking

𝐾𝑐 crates

Module-Level Bug Isolation

Bug context, crate-level assessments, and module docs

Module-Level Bug Relevance Analysis 𝐾𝑚 modules Module Candidate Ranking

Scoped Candidate Competition

Bug context, module assessment, module doc, and file docs

Scoped Candidate Competition

Up to 𝐾𝑠 files

File-Level Bug Isolation

Bug context, assessments, file docs, and code slices

File-Level Bug Relevance Analysis Final File Ranking

𝐾 𝑓 suspicious files

Prompt Design. The three components and the Scoped Candidate Competition mechanism use the shared prompt template in Figure 6, with their inputs, processing, and outputs summarized in Table 2. The template specifies the isolation level, bug context, candidate docs, available assessments and code slices, and output size. At the crate level, the input contains the bug context and crate docs, and the prompt asks whether the compiler functionality described in each doc may be responsible for the bug. At the module level, the input contains module docs and crate-level assessments alongside the bug context, and the prompt asks the same question for modules within the selected crates. For the Scoped Candidate Competition mechanism, the input contains the bug context, one module candidate’s assessment and doc, and its file docs, and the prompt asks for file comparison within that module. At the file level, the input contains the bug context, crate-level assessments, module-level assessments, file docs, and available code slices from the Evidence-Guided Code Slicing mechanism, and the prompt asks for analysis of the combined file candidates using both compiler functionality and implementation details. For each component or mechanism, the LLM follows the processing Manuscript submitted to ACM

HIDE: Hierarchical Isolation via Documentation and Evidence for Rustc Bugs

13

listed in Table 2 to rank candidates and return the specified number, or up to 𝐾𝑠 for Scoped Candidate Competition, with a brief reason for selecting each candidate. In summary, the Hierarchical Bug Isolation stage uses the generated docs and bug context to narrow candidates across crates, modules, and files, producing a ranked list of suspicious files. The Scoped Candidate Competition and Evidence-Guided Code Slicing mechanisms limit the number of candidates and the amount of source code included in each prompt, respectively. 4

Experimental Setup

To evaluate the performance of HIDE in compiler bug isolation, we investigate the following research questions: • RQ1 (Effectiveness): How effective is HIDE in isolating rustc bugs compared with baselines? • RQ2 (Efficiency): How efficient is HIDE compared with baselines? • RQ3 (Generalizability): How does HIDE perform across different LLMs? • RQ4 (Ablation): How do the components and mechanisms of HIDE contribute to its performance? 4.1

Datasets

Our evaluation uses the rustc bug dataset assembled by Liu et al. [12]. Since the dataset was constructed for an empirical study of rustc bugs, it requires further processing for file-level bug isolation. We process the dataset in four steps: defining the target bug categories, screening bugs for artifact availability and reproducibility, generating the artifacts required by the evaluated methods, and deriving the file-level ground truth. We describe each step below. First, we focus our evaluation on ICE, completeness, and soundness bugs. An ICE bug causes rustc to terminate with an internal compiler error. A completeness bug causes rustc to reject a valid program, while a soundness bug causes it to accept an invalid program. These three categories admit a uniform compiler-level reproduction oracle based solely on compiler termination and program acceptance. In contrast, runtime-behavior bugs require executing the compiled program under a controlled runtime environment, while diagnostic bugs require specialized oracles for diagnostic messages, source spans, or suggested fixes. We therefore exclude runtime-behavior and diagnostic bugs from our evaluation to avoid confounding bug-isolation effectiveness with differences in reproduction artifacts and oracle design. This exclusion serves only to delimit the scope of our evaluation and does not imply an inherent limitation on the applicability of HIDE. Second, we screen all 195 bugs in these three categories from Liu et al. [12] for artifact availability and reproducibility. Each bug must meet three inclusion criteria. (1) The issue description provides enough information to construct a failure program. (2) The rustc revision and compilation command, including the required parameters, can be identified. (3) Compiling the failure program on that revision consistently reproduces the reported behavior. This screening excludes 35 bugs with missing information or inconsistent behavior, leaving 160 bugs in the evaluation dataset. Third, we prepare the artifacts required for bug isolation. For each bug in the evaluation dataset, we collect the issue description, failure program, compilation parameters, and rustc revision on which the bug is reproduced. We compile the failure program on this revision with the specified parameters to collect the compiler log. During the same compilation, rustc’s self-profile mechanism records the executed queries, which we use to construct the query trace. The issue description, failure program, compiler log, and query trace form the bug context. We use the fixing pull request (PR) only to derive the ground truth and do not use its information to generate the bug context.

Manuscript submitted to ACM

14

Zhang et al. Table 3. Characteristics of the rustc bugs used in our evaluation. Category

Bugs

rustc .rs files

rustc versions

ICE Completeness Soundness

94 46 20

1,258–1,863 1,377–1,858 1,406–1,787

1.53.0–1.85.0 1.60.0–1.84.0 1.61.0–1.80.0

Total

160

1,258–1,863

1.53.0–1.85.0

Finally, we derive the file-level ground truth for each bug from its fixing PR. We include the Rust source files in the rustc compiler source tree modified by the PR and exclude test files, documentation, and other non-compiler source files. A bug may have multiple ground-truth files if its fixing PR modifies several compiler source files. We consider a bug successfully isolated when at least one ground-truth file appears in the returned top-𝐾 suspicious files. Table 3 reports the number of bugs and the ranges of rustc source-file counts and compiler versions in each category. The file counts correspond to the rustc revision associated with each bug. 4.2

Baselines

We compare HIDE with three state-of-the-art baselines for general software bug isolation, namely Agentless [27], SoapFL [17], and GraphLocator [9]. These methods represent semantics-based, execution-based, and dependency-based approaches, respectively. We evaluate their ability to rank suspicious rustc source files. • Agentless is the semantics-based baseline. Its hierarchical localization process progressively narrows an issue from suspicious files to relevant classes or functions, followed by specific edit locations. At the file level, it combines an LLM’s analysis of the repository tree with embedding retrieval over chunks of source code. Subsequent levels use code skeletons and selected source code for more detailed localization. We evaluate its localization results without performing the repair and validation stages. • SoapFL is the execution-based baseline. It organizes fault localization into fault comprehension, codebase navigation, and fault confirmation. During fault comprehension, it analyzes the behavior of failing tests to infer possible causes. During codebase navigation, it combines coverage with existing documentation and documentation generated by an LLM to narrow covered classes and methods. During fault confirmation, it reviews candidate methods through multiple LLM rounds to produce a suspiciousness ranking. • GraphLocator is the dependency-based baseline. It represents repository entities and their hierarchical and dependency relations using a repository dependency fractal structure. It first locates graph vertices associated with reported symptoms, then traverses neighboring vertices and uses abductive reasoning to construct a causal issue graph that grounds sub-issues in code entities and records their causal dependencies. This graph supports tracing reported symptoms toward potential bug causes. To ensure a consistent comparison, we preserve each baseline’s core localization workflow, prompt design, and reported parameter settings. We evaluate all methods using a shared dataset and protocol, comparing their ranked lists of suspicious files. 4.3

Evaluation Metrics

We evaluate file-level bug isolation effectiveness using Accuracy@𝑘 and computational efficiency using average time and average tokens. Manuscript submitted to ACM

HIDE: Hierarchical Isolation via Documentation and Evidence for Rustc Bugs

15

Table 4. Candidate values and selected parameter settings. Parameter 𝐾𝑐 𝐾𝑚 𝐾𝑠 𝐾𝑓

Meaning Number of selected crate candidates Number of selected module candidates Maximum number of files selected per module Number of returned suspicious files

Candidate values

Selected value

2, 4, 6 8, 12, 16 2, 4, 6 Fixed

4 12 4 10

Following prior bug-isolation studies [8, 17, 24], we define Accuracy@𝑘 as the proportion of bugs for which at least one ground-truth file appears among the top-𝑘 suspicious files returned by a method. For bug 𝑖, let 𝑃𝑖𝑘 be the set of these top-𝑘 files and 𝐺𝑖 be the ground-truth file set. Accuracy@𝑘 is calculated as Accuracy@ 𝑘 =

𝑁  1 ∑︁  𝑘 I 𝑃𝑖 ∩ 𝐺 𝑖 ≠ ∅ , 𝑁 𝑖=1

(11)

where 𝑁 is the number of evaluated bugs and I(·) equals one if the condition holds and zero otherwise. We report results for 𝑘 ∈ {1, 3, 5, 10}, with higher values of Accuracy@𝑘 indicating better bug isolation effectiveness. Average time is the mean wall-clock time per bug, measured from the start of bug isolation until the final ranked list is produced. Average tokens is the mean total number of input and output tokens across all LLM requests per bug. Lower values indicate less time and fewer tokens required for bug isolation, respectively. 4.4

Experimental Design

For RQ1 and RQ2, HIDE and all baselines use GPT-5.4. For RQ4, the full approach and all ablated variants also use GPT-5.4. These settings keep the underlying LLM consistent when comparing methods and ablated variants. For RQ3, we evaluate HIDE with GPT-5.4, Gemini-3.1-Pro-Preview, and DeepSeek-V4-Pro to examine its performance across LLMs. We perform three independent runs for each method in RQ1 and each model configuration in RQ3, and report the mean Accuracy@𝑘 values. 4.5

Implementation Details

Table 4 lists the parameters that control candidate selection in the Hierarchical Bug Isolation stage. We select their values using GPT-5.4 on a subset comprising 20% of the full dataset. We evaluate every combination of the candidate values for 𝐾𝑐 , 𝐾𝑚 , and 𝐾𝑠 in Table 4. We select the configuration with the highest Accuracy@10, using lower average tokens and then lower average time to break ties. We fix 𝐾 𝑓 at 10 to support all reported Accuracy@𝑘 metrics. The selected configuration is 𝐾𝑐 = 4, 𝐾𝑚 = 12, 𝐾𝑠 = 4, and 𝐾 𝑓 = 10. We use these values across LLMs, the main experiments, and the ablation study. All experiments run on the same Ubuntu 22.04.5 LTS server, equipped with Intel Xeon Platinum 8468V processors and 96 physical CPU cores. 5

Experimental Results and Analysis

5.1

RQ1: Effectiveness

Experimental Results. Table 5 compares HIDE with the baselines using mean Accuracy@𝑘 values from three independent runs with GPT-5.4. Boldface marks the best result, and underlining marks the second-best in each column. Manuscript submitted to ACM

16

Zhang et al. Table 5. File-level bug isolation effectiveness with GPT-5.4. Approach HIDE Agentless SoapFL GraphLocator

Accuracy@1

Accuracy@3

Accuracy@5

Accuracy@10

42.08% 30.00% 33.75% 36.25%

60.21% 55.21% 47.50% 48.75%

70.83% 64.38% 56.46% 50.00%

80.42% 74.38% 67.50% 50.00%

For overall accuracy, HIDE achieves the highest accuracy at all four values of 𝑘. Its Accuracy@1 is 42.08%, exceeding the strongest baseline, GraphLocator, by 5.83%. Agentless is the strongest baseline at 𝑘 = 3, 5, and 10. HIDE achieves 60.21%, 70.83%, and 80.42% at these values of 𝑘, exceeding Agentless by 5.00%, 6.45%, and 6.04%, respectively. For accuracy gains, HIDE’s accuracy rises from 42.08% at 𝑘 = 1 to 80.42% at 𝑘 = 10, a gain of 38.34%. Increasing 𝑘 from 5 to 10 adds 9.59%, while GraphLocator remains at 50.00%. These results indicate that inspecting more candidates in HIDE’s ranked list improves the likelihood of identifying a ground-truth file. Experimental Analysis. Comparison with Agentless. Agentless has the lowest Accuracy@1 at 30.00% but ranks second at Accuracy@3, Accuracy@5, and Accuracy@10. Its file localization combines analysis of the repository tree with embedding retrieval over code chunks [27]. This retrieval emphasizes semantic relevance to the issue description rather than compiler execution behavior. Agentless’s accuracy rises from 30.00% at Accuracy@1 to 55.21% at Accuracy@3, suggesting that relevant files often appear in its ranked list but are not prioritized first. HIDE instead compares documented file responsibilities with code slices selected using bug evidence during File-Level Bug Isolation. It achieves 42.08% Accuracy@1, compared with 30.00% for Agentless, an improvement of 12.08%. This integration helps HIDE prioritize the top candidate more effectively while retaining higher accuracy at larger values of 𝑘. Comparison with SoapFL. SoapFL ranks third among the four approaches at Accuracy@1, Accuracy@5, and Accuracy@10, whereas it ranks fourth at Accuracy@3. Its Test Behavior Analysis task summarizes test execution for the Test Failure Analysis task to infer bug causes. The Search Suspicious Class task narrows covered classes, while the Method Doc Enhancement task supports the Find Related Methods task. Repeated executions of the Method Review task precede the Suspicious Method Ranking task [17]. This workflow uses test behavior and documentation to narrow candidates from classes to methods, but it lacks HIDE’s aggregated descriptions of compiler functionality at the crate and module levels. HIDE combines these descriptions with query traces to narrow compiler regions before file comparison. It achieves 80.42% Accuracy@10 compared with SoapFL’s 67.50%, an improvement of 12.92%. This result suggests that compiler level context helps preserve relevant files in the final ranking. Comparison with GraphLocator. GraphLocator ranks second at Accuracy@1 (36.25%), but falls to third at Accuracy@3 and fourth at Accuracy@5 and Accuracy@10. Its Dynamic CIG Discovering phase traces from symptom locations toward potential causes through neighboring code entities [9]. This causal reasoning provides a basis for prioritizing bug causes rather than relying on semantic similarity alone. However, its Accuracy@5 and Accuracy@10 both remain at 50.00%, so extending the ranked list beyond the top five candidates does not improve its localization accuracy. This pattern is consistent with search guided by code dependencies concentrating successful predictions near the top without extending coverage of ground truth files at larger 𝑘. HIDE’s Scoped Candidate Competition retains alternatives from separate modules before global ranking, with Accuracy@5 to Accuracy@10 rising from 70.83% to 80.42%.

Manuscript submitted to ACM

HIDE: Hierarchical Isolation via Documentation and Evidence for Rustc Bugs (b) Token consumption — lower is better

(a) Execution time — lower is better 154

HIDE

Agentless

SoapFL

Agentless

GraphLocator

445 200

300

2,111,809

SoapFL

306

100

145,413

HIDE

269

0

17

400

Average time (s)

500

GraphLocator

580,901

99,642 100,000

1,000,000

Average tokens per bug (log scale)

Fig. 7. Efficiency of HIDE and the baselines. (a) Average time per bug (seconds). (b) Average tokens per bug (logarithmic scale).

Answer to RQ1. HIDE outperforms all baselines at every reported Accuracy@𝑘, achieving 42.08% Accuracy@1 and 80.42% Accuracy@10. Although HIDE consistently exceeds the baselines, its Accuracy@1 leaves substantial room for improvement. Accurately ranking a ground-truth file first therefore remains a challenge. 5.2

RQ2: Efficiency

Experimental Results. Figure 7 compares HIDE with the baselines in terms of average time and average tokens per bug. For average time, HIDE is the fastest approach, requiring 154 seconds per bug. Agentless, SoapFL, and GraphLocator require 269, 306, and 445 seconds per bug, respectively. HIDE reduces average time by approximately 42.8%, 49.7%, and 65.4% relative to these baselines, respectively. For average tokens, HIDE uses 145,413 tokens per bug, compared with 2,111,809 for Agentless and 580,901 for SoapFL, corresponding to reductions of approximately 93.1% and 75.0%, respectively. GraphLocator uses the fewest tokens at 99,642 per bug. Compared with GraphLocator, HIDE uses 45,771 more tokens but requires 291 fewer seconds per bug. Experimental Analysis. Comparison with Agentless. Agentless processes 2,111,809 tokens per bug, about 14.52 times HIDE’s 145,413 tokens. Its Localize to Related Elements step places the skeletons of all candidate files in one prompt, while the Localize to Edit Locations step repeatedly supplies selected source code when sampling edit locations [27]. These repeated inputs create cumulative token costs despite skeleton compression. HIDE narrows candidates using layered documentation before detailed file analysis. Its Scoped Candidate Competition limits the files compared together, while Evidence-Guided Code Slicing restricts the source content supplied for analysis. Together, these mechanisms limit the context HIDE processes, explaining its substantially lower token consumption than Agentless. Comparison with SoapFL. SoapFL requires 306 seconds per bug, nearly twice HIDE’s 154 seconds. Its 580,901 tokens are about 3.99 times HIDE’s consumption. SoapFL’s Method Doc Enhancement task reads method code to generate descriptions, while its Method Review task repeatedly resubmits failure context for each candidate method [17]. These tasks add LLM requests involving both source code and test evidence, increasing cumulative processing. HIDE instead compares selected files using bounded code slices, without a separate review dialogue for each method. Comparison with GraphLocator. GraphLocator uses the fewest tokens at 99,642 per bug, but requires 445 seconds, about 2.89 times HIDE’s execution time. GraphLocator’s Symptom Vertices Locating phase iteratively retrieves code entities. Its Dynamic CIG Discovering phase then expands one subissue per iteration using newly observed code entities Manuscript submitted to ACM

18

Zhang et al. Table 6. File-level bug isolation accuracy of HIDE across three LLMs and three independent runs. LLM

Metric

Run 1

Run 2

Run 3

Mean

GPT-5.4

Accuracy@1 Accuracy@3 Accuracy@5 Accuracy@10

42.50% 60.00% 70.00% 81.88%

41.25% 61.25% 71.88% 80.00%

42.50% 59.38% 70.62% 79.38%

42.08% 60.21% 70.83% 80.42%

Gemini-3.1-Pro-Preview

Accuracy@1 Accuracy@3 Accuracy@5 Accuracy@10

50.00% 66.88% 73.12% 78.12%

52.50% 68.12% 75.00% 80.00%

57.50% 72.50% 77.50% 81.88%

53.33% 69.17% 75.21% 80.00%

DeepSeek-V4-Pro

Accuracy@1 Accuracy@3 Accuracy@5 Accuracy@10

37.50% 53.75% 61.88% 73.12%

40.00% 59.38% 65.62% 80.00%

38.75% 55.62% 63.75% 75.00%

38.75% 56.25% 63.75% 76.04%

alongside a compact causal graph [9]. Although this process restricts source context, each expansion depends on the previous reasoning result. These operations explain why low token consumption does not translate into a short execution time. HIDE follows a fixed hierarchy, using 45,771 more tokens but finishing 291 seconds sooner. Answer to RQ2. HIDE achieves the lowest average time at 154 seconds per bug and uses 145,413 tokens per bug. Its average token consumption is substantially lower than that of Agentless and SoapFL but higher than that of GraphLocator. 5.3

RQ3: Generalizability

Experimental Results. Table 6 reports HIDE’s bug isolation accuracy over three independent runs with each of three LLMs: GPT-5.4, Gemini-3.1-Pro-Preview, and DeepSeek-V4-Pro. We examine accuracy across models using the mean results and consistency across runs using the difference between the highest and lowest accuracy values for each model. The settings for candidate selection remain unchanged across models. Bold and underlined values in the Mean column indicate the best and second-best results for each metric, respectively. For accuracy across models, HIDE achieves similar mean Accuracy@10 values, reaching 80.42% with GPT-5.4, 80.00% with Gemini-3.1-Pro-Preview, and 76.04% with DeepSeek-V4-Pro. Differences are larger at Accuracy@1, Accuracy@3, and Accuracy@5, where Gemini-3.1-Pro-Preview achieves the highest means of 53.33%, 69.17%, and 75.21%, respectively. The largest difference between models is 14.58% at Accuracy@1, compared with 4.38% at Accuracy@10. For consistency across runs, HIDE exhibits the smallest variation with GPT-5.4 at every reported metric. Across the three runs, the differences between its highest and lowest accuracy values are 1.25% at Accuracy@1 and 2.50% at Accuracy@10. By comparison, the difference reaches 7.50% at Accuracy@1 with Gemini-3.1-Pro-Preview and 6.88% at Accuracy@10 with DeepSeek-V4-Pro. Experimental Analysis. Regarding accuracy across models, Gemini-3.1-Pro-Preview ranks first at Accuracy@1, Accuracy@3, and Accuracy@5, while GPT-5.4 ranks first at Accuracy@10 (80.42%, narrowly ahead of Gemini at 80.00%). Gemini’s 53.33% Accuracy@1 indicates stronger prioritization of a responsible file at the top, potentially reflecting its software engineering reasoning [3]. By contrast, GPT-5.4 gains 9.59% from Accuracy@5 to Accuracy@10, compared with 4.79% for Gemini, suggesting that it recovers more bugs as the candidate list expands. This pattern may reflect Manuscript submitted to ACM

HIDE: Hierarchical Isolation via Documentation and Evidence for Rustc Bugs

19

GPT-5.4’s coding and document understanding capabilities, which are useful for interpreting evidence across HIDE’s documentation hierarchy [15]. Regarding consistency across runs, GPT-5.4 has the smallest Accuracy@1 span across the three runs, ranging from 41.25% to 42.50%, a span of 1.25%. Gemini-3.1-Pro-Preview has the largest, ranging from 50.00% to 57.50%, a span of 7.50%. Because LLMs can produce different outputs from identical prompts [14], early differences in crate or module selection may alter the downstream candidate pool and final file ranking. GPT-5.4 therefore shows more consistent Accuracy@1 than Gemini in these runs. With only three runs, these spans describe observed variation under the tested settings and do not establish inherent differences in model randomness. Answer to RQ3. HIDE maintains similar accuracy across models at 𝑘 = 10 under unchanged settings for candidate selection, with mean Accuracy@10 ranging from 76.04% to 80.42%, although differences are larger at smaller values of 𝑘. Consistency across runs depends on the model, with GPT-5.4 showing the smallest accuracy variation across the three runs. 5.4

RQ4: Ablation Study

Experimental Results. Table 7 compares HIDE with eight ablated variants, grouped into isolation components, documentation generation components, and context management mechanisms. Bold values indicate the best result for each metric. All eight variants achieve lower Accuracy@𝑘 than the full approach at every reported value of 𝑘. For isolation components, removing the Crate-Level Bug Isolation or Module-Level Bug Isolation component reduces Accuracy@10 by 3.76% or 8.13%, respectively. Removing both produces the largest Accuracy@10 decrease in this group, at 10.00%, and also reduces Accuracy@1 by 5.62%. For documentation generation components, removing the Crate-Level Documentation Generation, Module-Level Documentation Generation, or File-Level Documentation Generation component reduces Accuracy@10 by 4.38%, 5.63%, or 13.13%, respectively. Removing the file-level component produces the largest Accuracy@10 decrease among all eight variants and the largest decreases at every reported metric within this group. For context management mechanisms, removing the Scoped Candidate Competition mechanism reduces Accuracy@5 and Accuracy@10 by 9.38% and 10.00%, respectively. Removing the Evidence-Guided Code Slicing mechanism has its largest effect at Accuracy@10, with a decrease of 9.38%, compared with decreases of 3.75%, 0.62%, and 1.88% at Accuracy@1, Accuracy@3, and Accuracy@5, respectively. Experimental Analysis. Using the decrease in Accuracy@10 as the comparison criterion, File-Level Documentation Generation contributes the most, with a 13.13% loss when removed, whereas Crate-Level Bug Isolation contributes the least, with a 3.76% loss. The 10.00% loss without Scoped Candidate Competition also places candidate preservation among the strongest contributors. Regarding isolation components, removing Module-Level Bug Isolation reduces Accuracy@10 by 8.13%, whereas Accuracy@1 falls by only 0.62%. Module selection organizes file comparisons within relevant compiler functions, supporting retention of responsible files beyond the first position. Removing both isolation components increases the Accuracy@10 loss to 10.00%, supporting their complementary refinement. The smaller Accuracy@10 loss without crate selection is consistent with the remaining module filter, despite a 6.25% decrease at Accuracy@3. Regarding documentation generation components, removing File-Level Documentation Generation also reduces Accuracy@1 by 6.25% and Accuracy@5 by 8.75%. File descriptions identify concrete checks, analyses, or transformations, Manuscript submitted to ACM

20

Zhang et al. Table 7. File-level bug isolation accuracy of HIDE and its ablated variants. Variant

Accuracy@1 Accuracy@3 Accuracy@5 Accuracy@10

HIDE (Full)

42.50%

60.00%

70.00%

81.88%

Isolation components w/o Crate-Level Bug Isolation w/o Module-Level Bug Isolation w/o both isolation components

40.00% 41.88% 36.88%

53.75% 57.50% 56.25%

64.38% 66.25% 64.38%

78.12% 73.75% 71.88%

Documentation generation components w/o Crate-Level Documentation Generation w/o Module-Level Documentation Generation w/o File-Level Documentation Generation

37.50% 41.25% 36.25%

55.62% 55.62% 54.37%

65.62% 65.00% 61.25%

77.50% 76.25% 68.75%

Context management mechanisms w/o Scoped Candidate Competition w/o Evidence-Guided Code Slicing

38.75% 38.75%

54.37% 59.38%

60.62% 68.12%

71.88% 72.50%

distinguishing files with similar names but different responsibilities. They guide both initial file competition and subsequent relevance analysis, so their absence weakens two successive decisions. The losses across all cutoffs show that broad descriptions cannot replace this precise account of file functionality. Removing crate or module documentation causes smaller Accuracy@10 losses of 4.38% or 5.63%, respectively. These summaries support navigation between compiler regions, while file descriptions distinguish concrete implementations within those regions. Regarding context management mechanisms, removing Scoped Candidate Competition reduces Accuracy@5 by 9.38% and Accuracy@10 by 10.00%, compared with 3.75% at Accuracy@1. Comparing files separately within each module limits competition from unrelated compiler functions before global ranking. The larger losses at broader cutoffs are consistent with poorer retention of alternative bug locations when files from different modules compete together. Removing Evidence-Guided Code Slicing reduces Accuracy@10 by 9.38%, but Accuracy@3 by only 0.62% and Accuracy@5 by 1.88%. This disproportionate loss is consistent with unrelated source code obscuring additional responsible files in the final ranking. Slicing instead directs analysis toward computations matching the bug evidence, supporting their inclusion within the first ten positions. Answer to RQ4. All eight ablated variants achieve lower accuracy than the full approach at every reported metric, supporting the contributions of the evaluated components and mechanisms. Removing the File-Level Documentation Generation component produces the largest Accuracy@10 decrease, while the effects of the other ablations vary across metrics. 6

Threats to Validity Internal Validity. Internal validity may be affected by baseline adaptation, variation in LLM outputs, and data leakage.

For baseline adaptation, we preserve each baseline’s core localization procedure, prompt design, and reported settings. RQ1 and RQ2 use the same dataset, rustc revisions, GPT-5.4 model, and evaluation protocol for all methods. Adapting the baselines to rustc may still affect their performance. For variation in LLM outputs, RQ1 and RQ3 report means over three independent runs. This reduces dependence on a single run, although three runs cannot fully characterize variation and the ablation results may remain affected. For data leakage, we exclude fixing PRs from all method inputs

Manuscript submitted to ACM

HIDE: Hierarchical Isolation via Documentation and Evidence for Rustc Bugs

21

Table 8. Method-level bug isolation accuracy on rustc. Approach HIDE Agentless SoapFL GraphLocator

Accuracy@1

Accuracy@3

Accuracy@5

Accuracy@10

32.50% 26.25% 25.62% 18.75%

49.38% 39.38% 39.38% 26.25%

58.13% 43.75% 45.62% 28.12%

60.00% 48.75% 56.25% 28.12%

and analyze the rustc revision on which each failure is reproduced. Public issues and fixes may still have appeared in undisclosed model training data. Construct Validity. Construct validity may be affected by ground-truth construction and effectiveness measurement. For ground-truth construction, following prior bug-isolation work [1, 4, 28], we use faulty compiler files as ground truth. We derive these files from each fixing PR and exclude tests, documentation, and other non-compiler files. Supporting edits or refactoring may still introduce files unrelated to the root cause. For effectiveness measurement, following prior bug-isolation work [1, 4, 28], we evaluate ranked lists at multiple values of 𝑘. Accuracy@𝑘 records whether any ground-truth file appears among the first 𝑘 candidates. Thus, Accuracy@𝑘 neither requires identifying all responsible files nor evaluates ranking quality beyond the first 𝑘 candidates. External Validity. External validity may be affected by bug coverage, rustc evolution, and model coverage. For bug coverage, we screen 160 ICE, completeness, and soundness bugs for artifact availability and reproducibility. The results may not extend to non-reproducible bugs or other failures such as performance regressions and poor diagnostics. For rustc evolution, HIDE analyzes the revision associated with each bug and generates documentation for that revision. Major architectural changes may still require adjustments to the hierarchy or query traces. For model coverage, we evaluate three LLMs with unchanged candidate-selection settings. Other models may differ in accuracy and consistency. 7

Discussion

7.1

Extension to Method-Level Bug Isolation

This subsection examines whether HIDE can be extended from file-level to method-level bug isolation. The extension extracts candidate methods from the suspicious files returned by the File-Level Bug Isolation component (Section 3.2.3). The Scoped Candidate Competition mechanism selects methods independently within each file before merging the selected candidates. The Evidence-Guided Code Slicing mechanism extracts bug-related code slices for each method and retains the complete body of short methods. The selected methods are then ranked globally. We compare the extension with the same three baselines using method-level Accuracy@𝑘. Methods modified by the fixing PR serve as ground truth under the same matching rule as the file-level evaluation. Table 8 reports the method-level results on rustc. HIDE achieves the highest accuracy at every reported metric, reaching 32.50% Accuracy@1 and 60.00% Accuracy@10. These values exceed the strongest baseline results by 6.25% and 3.75%, respectively. Its largest advantage is 12.51% at Accuracy@5, although accuracy increases by only 1.87% from Accuracy@5 to Accuracy@10. The results support extending HIDE to methods but also show that returning more method candidates provides limited additional benefit.

Manuscript submitted to ACM

22

Zhang et al. Table 9. Module distribution of GCC candidate bugs and sampled bugs. Primary module

Candidate bugs

Sampled bugs

Count

Percentage

Count

Percentage

gcc/root gcc/cp gcc/fortran gcc/config gcc/c gcc/c-family

390 361 124 56 37 32

39.0% 36.1% 12.4% 5.6% 3.7% 3.2%

78 72 25 11 8 6

39.0% 36.0% 12.5% 5.5% 4.0% 3.0%

Total

1,000

100%

200

100%

Table 10. File-level bug isolation accuracy on GCC. Approach HIDE Agentless SoapFL GraphLocator

7.2

Accuracy@1

Accuracy@3

Accuracy@5

Accuracy@10

50.00% 46.50% 49.50% 34.00%

71.00% 67.50% 70.00% 40.50%

79.50% 71.50% 76.00% 41.00%

85.50% 77.00% 80.50% 41.00%

Transferability to GCC

This subsection examines whether HIDE can be transferred from rustc to GCC. We use the dataset released with CompSCAN [10]. It contains 1,026 GCC bug instances with the artifacts required for bug isolation. We select 200 bugs through stratified random sampling with a fixed seed. The sample covers the six modules in Table 9 and preserves their approximate proportions. These modules contain 1,000 of the 1,026 instances. The GCC adaptation retains both stages and the two context management mechanisms. It replaces the rustc query trace with a GCC pass trace that records information about compilation passes. We evaluate HIDE and the three baselines on the sampled bugs using GPT-5.4 and file-level Accuracy@𝑘. Table 10 reports the results on the 200 sampled GCC bugs. HIDE achieves the highest accuracy at every reported metric, reaching 50.00% Accuracy@1 and 85.50% Accuracy@10. SoapFL is the strongest baseline, with corresponding values of 49.50% and 80.50%. HIDE’s advantage over SoapFL increases from 0.50% at Accuracy@1 to 5.00% at Accuracy@10. These results support the transferability of HIDE to GCC under the evaluated setting, although the sample covers only six GCC modules. 8

Related Work

8.1

Bug Isolation

Bug-isolation research can be broadly divided into general bug isolation and compiler-specific bug isolation. We review both categories below. General Bug Isolation. General bug-isolation approaches [1, 4, 5, 8, 9, 16–18, 26–28, 31, 33] are designed to locate suspicious code across diverse software repositories. Based on their primary evidence, we organize them into semanticsbased, execution-based, and dependency-based approaches and discuss what each category can reveal about a rustc failure and what remains difficult to determine. Manuscript submitted to ACM

HIDE: Hierarchical Isolation via Documentation and Evidence for Rustc Bugs

23

Semantics-based approaches [8, 27, 31, 33] use descriptions of failing behavior to search for files and functions that implement the affected functionality. Agentless progressively narrows the search from files to more specific code locations [27]. LLM-BL uses an LLM as a zero-shot ranker to assess whether candidate code implements the functionality described in a bug report [8]. OrcaLoca guides agent exploration by prioritizing search actions, dividing complex actions into smaller steps, assessing candidate code against the behavior described in an issue, and pruning context using code distance [31]. These methods can use symptoms described in bug reports to identify code worth inspecting, but they are not specifically designed to explain how rustc source files work together to implement compiler functionality. For example, a file that emits an error message mentioned in a bug report may be ranked highly even when the bug occurs in another file that performs a compiler check, analysis, or transformation. Execution-based approaches [5, 17, 18, 26, 28] use test execution behavior and coverage information to guide the identification and assessment of suspicious code. AutoFL allows an LLM to invoke tools for exploring repositories and testing, and to explain the resulting suspicious locations [5]. FlexFL generates candidates using existing bug-isolation techniques and then applies an LLM released as open source to inspect and rerank them [28]. SoapFL integrates test behavior, coverage, static program information, documentation enhancement, and staged LLM review into a structured workflow [17]. Execution information can reduce the search space, but compilation involves many source files with different functions. Knowing which files execute does not necessarily explain which file performs an incorrect check, analysis, or transformation. Moreover, reranking selected candidates cannot recover a responsible file that was excluded during candidate selection. Dependency-based approaches [1, 4, 9, 16] trace potential bug causes through code dependencies, often represented as graphs that support searches across connected functions and files. LocAgent builds a heterogeneous repository graph to support reasoning by an LLM agent [1], while CoSIL dynamically constructs, expands, and prunes code graphs during iterative search [4]. GraphLocator additionally combines a repository graph with a causal issue graph to connect reported symptoms to possible causes [9]. These graphs help follow dependencies from one function or file to others, but code connections alone may not explain how files across crates jointly implement compiler functionality or which queries are requested during a failing compilation. A file closely connected to the code that reports a failure is therefore not necessarily responsible for the bug. HIDE differs from these general bug-isolation approaches in three respects. First, the Layered Documentation Aggregation stage summarizes what individual files do and how files with similar functions work together, providing documentation at the crate, module, and file levels. Second, the Hierarchical Bug Isolation stage uses this documentation and the bug context to progressively narrow candidates across crates, modules, and files, reducing the number of files requiring detailed analysis. Third, its Scoped Candidate Competition and Evidence-Guided Code Slicing mechanisms limit the number of candidates and the amount of source code included in each prompt, respectively. These designs address distributed compiler functionality, the large source file search space, and context overload in rustc bug isolation. Compiler-Specific Bug Isolation. Compiler-specific bug-isolation approaches [7, 10, 11, 24, 30] compare compiler executions to identify the code responsible for a failure. Based on what they modify to obtain these executions, we organize them into program-based, configuration-based, and step-based approaches. Program-based approaches [11, 24] mutate a program that triggers a compiler failure to generate variants that no longer trigger it, then compare compiler coverage across the original program and these variants. LLM4CBI uses LLMs to guide program mutation and ranks compiler files using the resulting coverage information [24]. This approach requires valid variants that avoid the failure while still exercising enough of the original compilation behavior to make Manuscript submitted to ACM

24

Zhang et al.

the coverage comparison useful. Generating such variants can be difficult when small changes to the program cause the compiler to perform different checks or optimizations. Configuration-based approaches [7, 30] keep the test program unchanged and vary compiler options to obtain executions that do and do not trigger the failure. ODFL changes individual optimization settings and ranks compiler files using coverage differences across these executions [30]. This approach avoids generating new test programs, but it requires options whose settings affect whether the failure occurs. Its use is therefore limited for bugs that cannot be suppressed by changing the available options. Step-based approaches [10] selectively skip compilation steps and observe whether the failure disappears. CompSCAN uses these observations to identify suspicious steps and rank the compiler code that implements them [10]. Applying this strategy requires compilation steps that can be skipped while allowing the remaining compilation to proceed. In rustc, a query is requested when its result is needed, and its implementation may request other queries. These computations do not generally form a fixed sequence of steps that can be independently skipped, making the strategy difficult to apply directly. HIDE does not require changing the test program, varying compiler options, or skipping compilation steps to obtain an execution without the failure. Instead, the Hierarchical Bug Isolation stage uses the original bug context, including the issue description, failure program, compiler log, and query trace, to narrow candidates across crates, modules, and files. The Layered Documentation Aggregation stage supports this search by summarizing what individual files do and how files with similar functions work together. HIDE can therefore search for responsible files even when it is difficult to make the failure disappear through changes to the program or compilation. 8.2

Rust Software Engineering

We review research on Rust software engineering [2, 6, 12, 19, 25, 29, 32] in three areas: Rust program safety, Rust software maintenance, and Rust compiler testing. The following paragraphs describe each area and distinguish its goals from locating responsible source files within rustc. Rust program safety studies [2, 6] develop methods to detect or prevent invalid memory accesses in Rust programs. RustSan adapts AddressSanitizer to Rust and uses program analysis to avoid inserting unnecessary checks [2]. MetaSafe protects the information that smart pointers use to check whether memory accesses are allowed [6]. These methods aim to protect Rust programs from memory errors, including those caused by unsafe code. Their target is the safety of the programs being compiled, whereas HIDE searches for bugs in the compiler implementation. Rust software maintenance studies [19, 32] examine bugs in Rust applications and libraries and the code changes used to repair them. Robati Shirzad and Lam [19] mined Rust repositories to identify recurring changes in bug fixes, including changes involving struct fields and calls to clone(). Zhang et al. [32] studied bugs and fixes in Rust projects and the standard library, classifying their causes and symptoms beyond memory safety issues. These studies help explain how Rust programs fail and how developers fix them, but they do not identify which rustc source files are responsible when the compiler fails. Rust compiler testing studies [12, 25, 29] develop methods that generate tests to expose compiler failures or analyze reported bugs to help identify what to test. Rust-twins mutates Rust programs and generates pairs of macros intended to produce the same results, then compares their expansions to expose compiler errors [29]. Liu et al. [12] categorized rustc bugs by their causes, symptoms, affected compilation stages, and test case characteristics. These efforts help discover compiler bugs and explain which language features or compilation stages need further testing. They do not, however, produce a ranked list of rustc source files for a given failure. Manuscript submitted to ACM

HIDE: Hierarchical Isolation via Documentation and Evidence for Rustc Bugs

25

HIDE complements these studies with a hierarchical LLM-based approach that combines compiler documentation with bug evidence to rank suspicious rustc source files after a failure has been observed. The Layered Documentation Aggregation stage summarizes what individual files do and how files with similar functions work together. The Hierarchical Bug Isolation stage uses these descriptions with the issue description, failure program, compiler log, and query trace to produce a ranked list of suspicious files. The goal is to help developers decide which compiler files to inspect when repairing a reported bug. 9

Conclusion

In this paper, we present HIDE, a hierarchical LLM-based approach that combines compiler documentation with bug evidence to rank suspicious rustc source files. The Layered Documentation Aggregation stage summarizes individual files and how files with similar functions work together. The Hierarchical Bug Isolation stage uses this documentation and the bug context to narrow candidates across crates, modules, and files. Its Scoped Candidate Competition and Evidence-Guided Code Slicing mechanisms limit the number of candidates and source code included in each prompt. Experiments on 160 reproducible rustc bugs show that HIDE outperforms Agentless, SoapFL, and GraphLocator at every reported Accuracy@𝑘, achieving 42.08% Accuracy@1 and 80.42% Accuracy@10 with GPT-5.4 and the lowest average execution time. Experiments with three LLMs support its robustness, while all eight ablated variants achieve lower accuracy than full HIDE. Together, these findings support combining compiler documentation, hierarchical candidate selection, and context management for effective rustc bug isolation. Future work will consider a broader range of compiler bug types, extend HIDE to additional compilers, and improve its method-level localization. References [1] Zhaoling Chen, Robert Tang, Gangda Deng, Fang Wu, Jialong Wu, Zhiwei Jiang, Viktor Prasanna, Arman Cohan, and Xingyao Wang. 2025. LocAgent: Graph-Guided LLM Agents for Code Localization. In Proceedings of the 63rd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers). 8697–8727. [2] Kyuwon Cho, Jongyoon Kim, Kha Dinh Duy, Hajeong Lim, and Hojoon Lee. 2024. RustSan: Retrofitting AddressSanitizer for Efficient Sanitization of Rust. In 33rd USENIX Security Symposium (USENIX Security 24). USENIX Association, Philadelphia, PA, 3729–3746. https://www.usenix.org/ conference/usenixsecurity24/presentation/cho-kyuwon [3] Google. 2026. Gemini 3.1 Pro Preview. https://ai.google.dev/gemini-api/docs/models/gemini-3.1-pro-preview. Accessed October 2, 2026. [4] Zhonghao Jiang, Xiaoxue Ren, Meng Yan, Wei Jiang, Yong Li, and Zhongxin Liu. 2025. Issue Localization via LLM-Driven Iterative Code Graph Searching. In 2025 40th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 3034–3045. [5] Sungmin Kang, Gabin An, and Shin Yoo. 2024. A Quantitative and Qualitative Evaluation of LLM-Based Explainable Fault Localization. Proceedings of the ACM on Software Engineering 1, FSE (2024), 1424–1446. [6] Martin Kayondo, Inyoung Bang, Yeongjun Kwak, HyunGon Moon, and Yunheung Paek. 2024. MetaSafe: Compiling for Protecting Smart Pointer Metadata to Ensure Safe Rust Integrity. In 33rd USENIX Security Symposium (USENIX Security 24). USENIX Association, Philadelphia, PA, 3711–3728. https://www.usenix.org/conference/usenixsecurity24/presentation/kayondo [7] Qingyang Li, Yibiao Yang, Maolin Sun, Jiangchang Wu, Qingkai Shi, and Yuming Zhou. 2026. Isolating Compiler Faults via Multiple Pairs of Adversarial Compilation Configurations. ACM Transactions on Software Engineering and Methodology (2026). doi:10.1145/3786786 [8] Zhengliang Li, Zhiwei Jiang, Qiguo Huang, and Qing Gu. 2025. LLM-BL: Large Language Models Are Zero-Shot Rankers for Bug Localization. In 2025 IEEE/ACM 33rd International Conference on Program Comprehension (ICPC). IEEE, 548–559. [9] Wei Liu, Chao Peng, Pengfei Gao, Aofan Liu, Wei Zhang, Haiyan Zhao, and Zhi Jin. 2026. GraphLocator: Graph-Guided Causal Reasoning for Issue Localization. Proceedings of the ACM on Software Engineering 3, FSE (2026), 1128–1149. [10] Yujie Liu, Mingxuan Zhu, Shengyu Cheng, and Dan Hao. To appear. Isolating Compiler Bugs through Compilation Steps Analysis. ACM Transactions on Software Engineering and Methodology (To appear). [11] Yujie Liu, Mingxuan Zhu, Jinhao Dong, Junzhe Yu, and Dan Hao. 2024. Compiler Bug Isolation via Enhanced Test Program Mutation. In Proceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering. ACM, 819–830. doi:10.1145/3691620.3695074 [12] Zixi Liu, Yang Feng, Yunbo Ni, Shaohua Li, Xizhe Yin, Qingkai Shi, Baowen Xu, and Zhendong Su. 2025. An Empirical Study of Bugs in the rustc Compiler. Proceedings of the ACM on Programming Languages 9, OOPSLA2 (2025), 3869–3896. Manuscript submitted to ACM

26

Zhang et al.

[13] Nicholas D. Matsakis and Felix S. Klock II. 2014. The Rust Language. In Proceedings of the 2014 ACM SIGAda Annual Conference on High Integrity Language Technology. ACM, 103–104. [14] OpenAI. 2026. Evaluation Best Practices. https://developers.openai.com/api/docs/guides/evaluation-best-practices. Accessed October 2, 2026. [15] OpenAI. 2026. Using GPT-5.4. https://developers.openai.com/api/docs/guides/latest-model?model=gpt-5.4. GPT-5.4 section. Accessed October 2, 2026. [16] Siru Ouyang, Wenhao Yu, Kaixin Ma, Zilin Xiao, Zhihan Zhang, Mengzhao Jia, Jiawei Han, Hongming Zhang, and Dong Yu. 2025. RepoGraph: Enhancing AI Software Engineering with Repository-Level Code Graph. In The Thirteenth International Conference on Learning Representations. https://openreview.net/forum?id=dw9VUsSHGB [17] Yihao Qin, Shangwen Wang, Yiling Lou, Jinhao Dong, Kaixin Wang, Xiaoling Li, and Xiaoguang Mao. 2025. SoapFL: A Standard Operating Procedure for LLM-Based Method-Level Fault Localization. IEEE Transactions on Software Engineering 51, 4 (2025), 1173–1187. [18] Md Nakhla Rafi, Dong Jae Kim, Tse-Hsun Chen, and Shaowei Wang. 2025. A Multi-Agent Approach to Fault Localization via Graph-Based Retrieval and Reflexion. arXiv preprint arXiv:2409.13642 (2025). Version 2. doi:10.48550/arXiv.2409.13642 [19] Mohammad Robati Shirzad and Patrick Lam. 2024. A study of common bug fix patterns in Rust. Empirical Software Engineering 29, 2 (2024), 44. [20] The Rust Project. 2023. MIR Validation ICE: Use of Local Which Has No Storage. https://github.com/rust-lang/rust/issues/118990. [21] The Rust Project. 2023. Separate MIR Lints from Validation. https://github.com/rust-lang/rust/pull/119077. [22] The Rust Project. 2026. Queries: Demand-Driven Compilation. https://rustc-dev-guide.rust-lang.org/query.html. [23] The Rust Project. 2026. Rust Compiler Development Guide. https://rustc-dev-guide.rust-lang.org/. [24] Haoxin Tu, Zhide Zhou, He Jiang, Imam Nur Bani Yusuf, Yuxian Li, and Lingxiao Jiang. 2024. Isolating Compiler Bugs by Generating Effective Witness Programs with Large Language Models. IEEE Transactions on Software Engineering 50, 7 (2024), 1768–1788. [25] Qian Wang and Ralf Jung. 2024. Rustlantis: Randomized Differential Testing of the Rust Compiler. Proceedings of the ACM on Programming Languages 8, OOPSLA2, Article 340 (2024), 27 pages. doi:10.1145/3689780 [26] Ratnadira Widyasari, Jia Wei Ang, Truong Giang Nguyen, Neil Sharma, and David Lo. 2024. Demystifying Faulty Code: Step-by-Step Reasoning for Explainable Fault Localization. In 2024 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER). IEEE, 568–579. doi:10.1109/SANER60148.2024.00064 [27] 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. [28] Chuyang Xu, Zhongxin Liu, Xiaoxue Ren, Gehao Zhang, Ming Liang, and David Lo. 2025. FlexFL: Flexible and Effective Fault Localization with Open-Source Large Language Models. IEEE Transactions on Software Engineering 51, 5 (2025), 1455–1471. [29] Wenzhang Yang, Cuifeng Gao, Xiaoyuan Liu, Yuekang Li, and Yinxing Xue. 2024. Rust-twins: Automatic rust compiler testing through program mutation and dual macros generation. In Proceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering. 631–642. [30] Yibiao Yang, Qingyang Li, Maolin Sun, Jing Yang, Jiangchang Wu, and Yuming Zhou. 2025. Isolating Compiler Faults Through Differentiated Compilation Configurations. IEEE Transactions on Software Engineering 51, 6 (2025), 1838–1853. [31] Zhongming Yu, Hejia Zhang, Yujie Zhao, Hanxian Huang, Matrix Yao, Ke Ding, and Jishen Zhao. 2025. OrcaLoca: An LLM Agent Framework for Software Issue Localization. In Proceedings of the 42nd International Conference on Machine Learning (Proceedings of Machine Learning Research, Vol. 267). PMLR, 73416–73436. https://proceedings.mlr.press/v267/yu25x.html [32] Chengquan Zhang, Yang Feng, Yaokun Zhang, Yuxuan Dai, and Baowen Xu. 2024. Beyond Memory Safety: An Empirical Study on Bugs and Fixes of Rust Programs. In 2024 IEEE 24th International Conference on Software Quality, Reliability and Security (QRS). IEEE, 272–283. doi:10.1109/QRS62785. 2024.00035 [33] 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. ACM, 1592–1604. doi:10.1145/3650212.3680384

Manuscript submitted to ACM

Related documents

• HIDE: Hierarchical Isolation via Documentation and Evidence for Rustc Bugs#1468947
• If It's Not Buggy, Don't Fix It: On the Dynamics of Iterative Bug-fixing with LLMs#997036
• Diff-Based Code Corruption using LLMs for Large-Scale Bugfix Benchmarking#321913
• Leaf: An Instrumentation-based Dynamic Analysis Framework for Rust#373453
• JevVibe: Efficient Classification-Guided Secure Code Generation#1129569