Technical Summary: When LLMs Invent Rust Crates

Problem Statement

Large Language Models (LLMs) are increasingly used for code generation, yet they remain prone to "hallucinations"—producing plausible but factually incorrect or fabricated outputs. A critical subset of this issue is package hallucination, where an LLM recommends or imports a dependency that does not exist. In languages like Python and JavaScript, this poses a severe supply chain security risk, as adversaries can pre-register malicious packages under hallucinated names.

While prior research has extensively studied package hallucination in popular ecosystems (Python, JavaScript), there is a significant gap regarding Rust. Rust is widely adopted for security-critical system-level programming (e.g., operating systems, blockchain). Although Rust's dependency management (via Cargo.toml) differs from other languages—requiring explicit declaration before a crate is downloaded—hallucinated crate references in source code remain a direct reliability problem. They cause build failures, unresolved imports, and namespace confusion. Furthermore, in many LLM-assisted workflows, source-code snippets are generated without complete project manifests, making source-level crate references the earliest observable signal of dependency-related errors.

Methodology

To address the lack of empirical data on Rust, the authors conducted the first large-scale study on crate hallucination in LLM-generated Rust code.

1. Dataset Construction

The authors constructed a multi-source dataset comprising 2,794 coding tasks derived from three sources:

• Stack Overflow: 1,001 unique, highly-voted Rust questions representing real-world developer inquiries.
• GitHub: 793 tasks extracted from the top 100 Rust repositories (by stars), filtered for quality to exclude compiler internals, vague tasks, and platform-specific constraints.
• LLM-Generated Tasks: 1,000 tasks created by transforming descriptions of popular crates (from lib.rs and crates.io) into implementation requests using a Qwen2.5-32B model.

2. Model Evaluation

The study evaluated 14 models across six families, including:

• Commercial: GPT-5, Gemini 2.5 Pro, Claude 4 Opus.
• Open-Source: Qwen2.5-Coder (various sizes), DeepSeek-Coder-V2, OpenCoder.
  Models were tested under default configurations and various decoding temperatures (0 to 5).

3. Detection Mechanism

A comprehensive inventory of valid Rust crates was built by scraping crates.io, the Rust Standard Library, and rustc compiler crates. The authors also mined repository Cargo.toml files to capture crate aliases.

• Extraction: The system extracted crate names from generated code using three patterns: use declarations, direct path prefixes, and extern crate declarations.
• Metric: The Crate Hallucination Rate (CHR) was calculated as the ratio of extracted names absent from the valid inventory to the total number of extracted names.

4. Mitigation Evaluation

Two prompt-engineering strategies were tested to mitigate hallucinations without retraining models:

• Self-Refinement: A multi-turn process where the model reviews its own output, checks for standard library usage, and verifies crate names before finalizing.
• Retrieval Augmented Generation (RAG): The model was provided with a retrieval index of the top 10,000 crates from crates.io and a list of standard library modules to ground its generation.

Key Results

RQ1: Prevalence and Influencing Factors

• High Prevalence: The overall CHR across all models was 20.23%. Hallucinations were observed in all evaluated models.
• Model Sensitivity: While specific models performed better (e.g., Gemini 2.5 Pro at 16.18% vs. Claude 4 Opus at 26.90%), the difference between commercial and open-source models was not statistically significant on average.
• Parameter Independence: Unlike findings in Python/JavaScript, model size (parameter count) showed no statistically significant correlation with hallucination rates within model families (e.g., Qwen2.5-Coder variants).
• Temperature Independence: Increasing decoding temperature did not lead to a systematic increase in hallucinations. The CHR remained stable across temperature settings (0–5), contrasting with prior work where higher temperatures increased hallucination rates.

RQ2: Hallucination Patterns

The study identified four distinct, Rust-specific patterns:

1. Module-Crate Confusion: Over 45% of hallucinations were actually valid Rust standard library modules (e.g., std::thread, std::io) incorrectly referenced as external crates. The models often failed to qualify these with std:: or core::.
2. Cross-Model Consistency: Module hallucinations showed high overlap across different models (Jaccard similarity ≈ 0.44), suggesting shared training data limitations, whereas non-module hallucinations were more unique to specific models.
3. Near-Miss Variants: Hallucinated names were predominantly minor variations of real crates. 86.48% of hallucinations were within five Levenshtein edits of a valid crate. A prominent pattern was the misuse of hyphens, where models generated camelCase names (e.g., httpresponse) instead of the Rust kebab-case convention (e.g., http-response).
4. Cross-Ecosystem Transfer: Approximately 39% of frequent hallucinations reused names from other ecosystems (e.g., Python or Windows APIs), indicating structured but misaligned knowledge transfer.

RQ3: Mitigation Effectiveness

• Limited Gains: Both mitigation strategies reduced hallucination rates, but the improvements were modest.
• Self-Refinement: Consistently reduced CHR by 2–3 percentage points (approx. 10–15% relative reduction).
• RAG: Provided limited and inconsistent improvements; in some cases, it slightly increased the rate.
• Conclusion: Simple prompt-level interventions are insufficient to substantially eliminate crate hallucinations.

Significance and Contributions

The paper claims the following contributions:

1. First Empirical Study: It provides the first systematic investigation of crate hallucinations in LLM-generated Rust code, filling a gap in the literature dominated by Python and JavaScript studies.
2. Distinct Patterns: It reveals that Rust hallucinations follow a distinct pattern compared to other languages: they are highly structured (often involving module confusion and naming convention errors) and are surprisingly insensitive to model size and decoding temperature.
3. Dataset Release: The authors released a dataset of 2,794 Rust coding tasks to facilitate future research.
4. Security and Reliability Implications: The study highlights that while Rust's dependency model mitigates immediate supply chain attacks (by requiring Cargo.toml updates), hallucinated references still cause significant build failures and reliability issues. It suggests that future mitigation requires Rust-aware guardrails (e.g., namespace validation, registry-aware checking, and Cargo.toml cross-referencing) rather than generic prompt engineering.

The authors conclude that while lightweight strategies offer marginal benefits, robust mitigation likely requires tighter integration with toolchain-level verification and training data improvements specific to the Rust ecosystem.