RepoScope: Repository-Level Code Generation

• RepoScope is a training-free framework that leverages static analysis to build a multi-view Repository Structural Semantic Graph capturing code structure and dependencies.
• It retrieves a four-view context—including callers, predicted callees, similar functions, and code fragments—to preserve structural alignment and guide accurate code generation.
• Empirical evaluations on CoderEval and DevEval show up to a 36.35% improvement in pass@1, demonstrating enhanced repository-aware code generation performance.

RepoScope is a training-free, static-analysis-driven framework for repository-level code generation that targets a central failure mode of conventional repository-aware retrieval-augmented generation: retrieving context that is textually similar yet structurally misaligned with the target completion. It constructs a Repository Structural Semantic Graph (RSSG), retrieves a four-view context comprising callers, predicted callees via call chain prediction, similar functions, and similar code fragments, and serializes that context in a structure-preserving manner for a single LLM query. The method is evaluated on CoderEval and DevEval, where it outperforms state-of-the-art baselines with up to a 36.35% relative improvement in pass@1, while relying solely on static analysis and avoiding additional training or multiple LLM queries (Liu et al., 20 Jul 2025).

1. Problem setting and design rationale

RepoScope is motivated by the mismatch between the information repository-level code generation requires and the information most RAG pipelines actually deliver. The target setting is generation “within the context of a specified repository,” where the model must recover repository-specific APIs, internal conventions, and latent structural dependencies under a constrained context window (Liu et al., 20 Jul 2025).

The framework is explicitly positioned against several limitations of prior repository-level methods. Similarity-only retrieval, exemplified by RepoCoder in the paper’s discussion, can return code that looks relevant but follows the wrong call chain, causing the model to hallucinate incorrect methods. Structural methods such as RepoFuse and DRACO are described as using relatively shallow structural cues and as often retrieving too much irrelevant code. Other systems are criticized for using too few contextual perspectives, or for depending on training or multi-step agentic orchestration, as in RepoHYPER, CodeAgent, and LingmaAgent. RepoScope’s design goal is therefore not merely to retrieve more context, but to retrieve context that reflects repository structure and to preserve that structure in the prompt (Liu et al., 20 Jul 2025).

This design also encodes a narrower claim than many repository-aware code-generation systems. RepoScope does not introduce a new training regime. It instead assumes that repository-level gains can be obtained through static analysis, graph construction, heuristically scored retrieval, and prompt assembly. A plausible implication is that the framework is intended to be deployable across repositories without repository-specific finetuning, which the paper associates with efficiency and generalizability (Liu et al., 20 Jul 2025).

2. Repository Structural Semantic Graph

The RSSG is the framework’s core index. It is defined as a multi-view heterogeneous directed graph,

$$G=\{(h,r,t)\mid h,t\in\mathcal{E},\ r\in\mathcal{R}_{ST}\cup\mathcal{R}_C\cup\mathcal{R}_I\},$$

where $\mathcal{E}$ is the set of entities, $\mathcal{R}_{ST}$ contains structural and type dependency relations, $\mathcal{R}_C$ contains call relations, and $\mathcal{R}_I$ contains import relations (Liu et al., 20 Jul 2025).

RSSG contains three entity types: Class, Function, and Attribute. Its relation space is organized into three semantic views. The structural and type dependency view includes Contains, Returns, As Parameter, and Inherits. The calls view contains Calls edges. The imports view contains Imports edges, which encode whether an entity can be directly called within the current code context because it was imported or shares the same module scope (Liu et al., 20 Jul 2025).

The practical role of these relations is to expose paths that ordinary similarity search misses. Contains preserves class-member structure. Returns and As Parameter encode type-level prerequisites and outputs. Inherits propagates superclass accessibility. Calls records invocation structure, with each call edge assigned a weight $w_r$ equal to the number of times the head entity calls the tail entity. Imports establishes the set of entities directly accessible from the target function and therefore admissible as call-chain entry points (Liu et al., 20 Jul 2025).

RSSG is constructed using Pytype and Tree-sitter. Entity embeddings are computed from a combination of name, signature, docstring, and path. This makes the graph simultaneously structural and semantic: topology is derived from static code analysis, while ranking later exploits embedding similarity (Liu et al., 20 Jul 2025).

A common misconception is that repository structure in code generation reduces to import graphs or file adjacency. RepoScope’s graph is materially richer. It combines containment, inheritance, type dependencies, direct calls, and imports into a single heterogeneous index, and the later retrieval stages use these views differently rather than flattening them into one generic edge set (Liu et al., 20 Jul 2025).

3. Four-view retrieval and call chain prediction

RepoScope follows an indexing–retrieval–generation pipeline, but its distinguishing feature is the four-view context assembled during retrieval (Liu et al., 20 Jul 2025).

View	Function in retrieval
Callers	Reveal intended use of the target function
Predicted callees	Provide likely call chains inside the target body
Similar functions	Supply reusable patterns and conventions
Similar code fragments	Capture useful code outside function boundaries

The rationale for these views is explicitly multi-perspectival. Callers expose how the target function is consumed. Predicted callees guide body construction more directly than isolated lexical neighbors. Similar functions encode higher-level implementation patterns. Similar code fragments compensate for the fact that relevant code may not align with function boundaries. RepoScope therefore combines structural and similarity-based evidence rather than treating them as substitutes (Liu et al., 20 Jul 2025).

The most distinctive component is call chain prediction. Starting from the imported entities of the target function,

$$\mathcal{E}_{\mathrm{imp}(f)}=\{e\mid (f,r,e)\in G,\ r\in\mathcal{R}_I\},$$

RepoScope searches the graph for likely call chains. All entities are first clustered with K-means. Entity scoring then combines cosine similarity between the target function and an entity embedding with a cluster-level call-propagation term derived from call relations among entities in related clusters. In implementation, the paper sets $\alpha_1=1.0$, $\alpha_2=2.0$, $\alpha_3=2.0$, and $\mathcal{E}$0 (Liu et al., 20 Jul 2025).

Traversal uses depth-first search over the structural/type relations $\mathcal{E}$1. The maximum chain length is $\mathcal{E}$2. Each chain is then extended for interpretability by adding constructors for classes, parameter and return-type classes for functions, and owning classes for functions or attributes. Chains are scored by the average score of their constituent entities. RepoScope selects the top $\mathcal{E}$3 chains, limits diversity to $\mathcal{E}$4 maximum chains per starting point, and deduplicates nested or overlapping chains (Liu et al., 20 Jul 2025).

The paper treats call chains, rather than single callees, as the more faithful unit of repository reasoning. Its motivating example uses the difference between a superficially similar function and the correct callee sequence to argue that generation errors often arise not from missing lexical analogues but from missing structural execution paths. In the reported callee-prediction comparison, RepoScope attains F1 = 0.603 versus 0.4352 for a similarity-only baseline, a 38.56% improvement (Liu et al., 20 Jul 2025).

4. Structure-preserving serialization and prompt construction

Retrieval alone does not define RepoScope. The retrieved entities must be converted into a prompt without destroying the very structure that justified their retrieval. RepoScope addresses this with a structure-preserving serialization algorithm and a two-stage prompt budgeting procedure (Liu et al., 20 Jul 2025).

The serialization step first builds a structural tree from the retrieved call chains. Child relations are determined by Contains edges. The tree is then serialized by preorder traversal, with indentation used to reconstruct hierarchy. The purpose is to preserve class–method and class–attribute nesting, remove duplication across overlapping chains, and avoid the flattening effect of naive concatenation (Liu et al., 20 Jul 2025).

The framework then performs iterative prompt construction under a maximum prompt length of 4096 tokens. Let $\mathcal{E}$5 denote the available input length after subtracting task instructions, and let there be $\mathcal{E}$6 context types. In stage one, each type receives a pre-allocation of

$\mathcal{E}$7

Each context family fills its share according to its ranking. In stage two, remaining budget is reallocated according to a fixed priority order, allowing context types that still have high-value units to claim unused space from others (Liu et al., 20 Jul 2025).

Several implementation details follow directly from this design. RepoScope is single-query at generation time. It is training-free. It uses bge-small-en-v1.5 as the embedding model for most methods; the paper notes RLCoder as the exception, using a fine-tuned UnixCoder retriever. The evaluated backbone LLMs are GPT-4o mini, Claude-3.5-Haiku, Qwen3-235B-A22B, and DeepSeek-V3, all run with temperature set to 0 (Liu et al., 20 Jul 2025).

The serialization stage is not a superficial formatting convenience. In ablation, removing structure-preserving serialization reduces pass@1 and slightly increases prompt length. The reported interpretation is that structural formatting improves both model comprehension and token efficiency (Liu et al., 20 Jul 2025).

5. Empirical evaluation

RepoScope is evaluated on three benchmarks. On CoderEval, the paper uses the Python subset only: from 460 original tasks, path-error filtering yields 207 samples. On DevEval, the original 1,874 samples from 117 repositories are filtered to 1,742 after removing invalid solutions and lineno annotations. On RepoEval, the API subset contains 1,600 samples (Liu et al., 20 Jul 2025).

For CoderEval and DevEval the main metric is pass@1; for RepoEval it is EM and ES. Baselines include Direct, SimpleRAG, RepoCoder, DRACO, CodeAgent, and RLCoder (Liu et al., 20 Jul 2025).

Benchmark	Best RepoScope result	Notable comparison
CoderEval	59.42 pass@1 with DeepSeek-V3	+17.15% over the best baseline
DevEval	41.56 pass@1 with Claude-3.5-Haiku	+36.35% over DRACO
RepoEval	40.25 EM, 67.74 ES with DeepSeek-V3	+7.33% EM over the best baseline

The full pass@1 breakdown further illustrates model dependence. On CoderEval, RepoScope reaches 44.93 with GPT-4o mini, 55.07 with Claude-3.5-Haiku, 49.28 with Qwen3-235B-A22B, and 59.42 with DeepSeek-V3. On DevEval, the corresponding results are 26.18, 41.56, 30.02, and 35.82 (Liu et al., 20 Jul 2025).

Prompt length is also reported. RepoScope uses about 3679 tokens on average across the two function-generation benchmarks, which the paper characterizes as competitive or lower than many baselines. In particular, RepoCoder and CodeAgent often consume substantially more context while still underperforming RepoScope (Liu et al., 20 Jul 2025).

Ablation studies isolate the contribution of each component. Removing any of the four context views lowers performance. On DeepSeek-V3, the largest drop comes from removing similar functions, at -11.38%, though the paper also notes that callers and call chains are especially utility-efficient per token. Removing weighted entity scoring, DFS traversal, or call-chain extension also reduces accuracy. These findings support the claim that RepoScope’s performance is not attributable to prompt volume alone but to the interaction among graph construction, multi-view retrieval, chain scoring, and serialization (Liu et al., 20 Jul 2025).

6. Relation to broader repository-scoped research

RepoScope belongs to a broader family of methods that treat the repository, rather than the file or patch, as the relevant analysis unit. Within code generation, a close point of comparison is RepoFusion, which trains code models to consume multiple repository contexts through a Fusion-in-Decoder architecture and reports that repository-context training can let a 220M CodeT5-based model outperform much larger baselines such as CodeGen-16B-multi on single-line completion (Shrivastava et al., 2023). RepoScope differs in that it is explicitly training-free and relies on static analysis rather than a dedicated repository-context training objective (Liu et al., 20 Jul 2025).

Outside code generation, repository-level reasoning appears in several adjacent research strands. RepoSPD extends security patch detection from patch-level to repository-level by constructing a repository-level code property graph, combining graph and sequence branches, and reporting improvements of 11.90% and 3.10% in accuracy over the best baselines on two datasets (Wen et al., 2024). GraphRepo stores mined Git data in Neo4j with modular drillers, miners, and mappers to support fast post-indexing exploration across commits, files, methods, and developers (Serban et al., 2020). SemRepo builds an RDF graph of 82,078,636 triples over 197,566 GitHub repositories and links repositories to authors, papers, datasets, and experiments, enabling provenance and sustainability analyses at scholarly-ecosystem scale (Rafay et al., 13 May 2026). Package Dashboard generalizes repository-scoped reasoning to supply-chain analysis by combining software artifact signals with upstream repository/community health in a dual-perspective framework spanning heterogeneous ecosystems (Liu et al., 1 Dec 2025).

This broader literature suggests that “repository scope” is not a single methodology but a shared epistemic move: important signals are often distributed across files, functions, metadata, issue history, and external scholarly or supply-chain context. RepoScope’s specific contribution within that landscape is to operationalize repository scope for code generation through static graph construction, call-chain-aware retrieval, and structure-preserving prompt assembly, rather than through repository-context training, execution-based analysis, or knowledge-graph integration (Liu et al., 20 Jul 2025).