---
title: 'RepoScope: Repository-Level Code Generation'
url: https://www.emergentmind.com/topics/reposcope
type: topic
---

# RepoScope: Repository-Level Code Generation

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 [2507.14791].

## 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 [2507.14791].

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 [2507.14791].

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 [2507.14791].

## 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 [2507.14791].

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 [2507.14791].

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 [2507.14791].

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 [2507.14791].

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 [2507.14791].

## 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 [2507.14791].

| 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 [2507.14791].

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 $\phi(x)=\log_2(x+1)$ [2507.14791].

Traversal uses **depth-first search** over the structural/type relations $\mathcal{R}_{ST}$. The maximum chain length is $l_{\max}=5$. 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 $K_{\text{chain}}=5$ chains, limits diversity to $\tau=4$ maximum chains per starting point, and deduplicates nested or overlapping chains [2507.14791].

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** [2507.14791].

## 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 [2507.14791].

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 [2507.14791].

The framework then performs **iterative prompt construction** under a maximum prompt length of **4096** tokens. Let $\ell$ denote the available input length after subtracting task instructions, and let there be $N$ context types. In stage one, each type receives a pre-allocation of
$$
\bar{\ell}=\left\lfloor\frac{\ell}{N}\right\rfloor.
$$
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 [2507.14791].

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** [2507.14791].

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 [2507.14791].

## 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** [2507.14791].

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** [2507.14791].

| 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** [2507.14791].

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 [2507.14791].

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 [2507.14791].

## 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 [2306.10998]. RepoScope differs in that it is explicitly **training-free** and relies on static analysis rather than a dedicated repository-context training objective [2507.14791].

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 [2412.08068]. **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 [2008.04884]. **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 [2605.13310]. **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 [2512.01630].

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 [2507.14791].

Source: https://www.emergentmind.com/topics/reposcope