The compiler source looks like a mess in your editor
You clone the Rust compiler repository to fix a false positive in Clippy or tweak a diagnostic message. You open the project in your editor. The experience falls apart immediately. Imports are unresolved. Completions are missing. The standard library types show errors. You are staring at librustc_lint and the editor treats it like plain text.
This happens because the Rust compiler is not a normal crate. It lives in a massive monorepo with a custom build system, stage bootstrapping, and hundreds of internal crates that do not follow standard Cargo conventions. Standard tooling expects Cargo.toml files and a flat dependency graph. The compiler gives it a forest of build scripts and feature flags.
RustRover can handle this complexity, but it needs explicit instructions. The IDE relies on rust-analyzer for indexing and completion. Without a bridge between the compiler's build system and the analyzer, the IDE cannot find the definitions. You have to generate that bridge.
RustRover needs a map for the monorepo
RustRover is JetBrains' dedicated IDE for Rust. It brings the IntelliJ platform to the language, offering deep refactoring, integrated debugging, and a unified UI. For typical application code, RustRover works out of the box. It reads Cargo.toml, downloads dependencies, and indexes everything automatically.
Compiler development requires a different workflow. The cargo dev tool generates the configuration files that tell RustRover how to navigate the monorepo. It creates a map of the internal crates, links the local toolchain, and configures the analyzer to understand the compiler's structure.
The setup process is a one-time command per repository clone. It produces .idea files and project metadata that RustRover consumes. Once generated, the IDE can resolve paths, provide completions for compiler internals, and allow you to jump between definitions across the entire codebase.
Running the setup
The setup requires the Rust compiler repository and the cargo dev tool. The cargo dev tool is part of the cargo-dev crate, which is maintained alongside the compiler. Contributors usually install it once and reuse it across projects.
# Clone the monorepo. This contains rustc, clippy, rustfmt, and the standard library.
# The repository is large. Ensure you have sufficient disk space.
git clone https://github.com/rust-lang/rust.git
# Navigate into the repository root.
cd rust
# Generate IntelliJ project files and link the toolchain.
# This command creates the .idea directory and configures rust-analyzer
# to understand the compiler's internal crate structure.
cargo dev setup intellij
If your compiler repository lives in a different location than your current project, you can point the setup command to the correct path. This is common when working on a tool like Clippy that references the compiler source separately.
# Link to a rustc repository located elsewhere on the filesystem.
# The --repo-path flag tells cargo dev where to find the compiler source.
cargo dev setup intellij --repo-path /path/to/rust
Convention aside: The community standard for compiler contributors is to run cargo dev setup intellij immediately after cloning or pulling significant changes. The setup script detects the repository structure automatically. You rarely need manual configuration unless you are maintaining a highly customized fork.
What the setup actually does
The cargo dev setup intellij command does not just create a generic project file. It performs specific steps tailored to the Rust compiler's architecture.
First, it scans the repository to identify all internal crates. The compiler contains hundreds of crates, many of which are not published to crates.io and do not have standard Cargo.toml manifests in the expected format. The setup script catalogs these crates and builds a dependency graph that rust-analyzer can consume.
Second, it links the local toolchain. Compiler code often depends on the exact version of the standard library and compiler internals being built. The setup ensures that the IDE uses the local toolchain rather than a system-wide installation. This prevents version mismatches where the IDE expects a newer or older standard library than the code actually targets.
Third, it configures build scripts and feature flags. Many compiler crates rely on custom build scripts that generate code or set environment variables. The setup script extracts this information and passes it to the analyzer, ensuring that generated code is indexed and feature-gated items are visible.
The result is a rust-project.json or updated .idea configuration that acts as a single source of truth for the IDE. When you open the project in RustRover, the IDE reads this configuration and starts indexing with full awareness of the compiler's structure.
Trust the setup script. It knows the repo structure better than you do.
Debugging and performance
Working on the compiler in RustRover introduces performance considerations. The monorepo is large, and indexing hundreds of crates consumes significant memory and CPU. The first load can take several minutes. Subsequent loads are faster as the IDE caches the index.
Memory usage is the primary bottleneck. IntelliJ-based IDEs run on the JVM and have a default heap size that may be insufficient for the Rust compiler repository. If the IDE becomes unresponsive or shows memory warnings, you need to increase the heap allocation.
Edit the rustrover64.exe.vmoptions file (or the equivalent for your platform) and adjust the -Xmx parameter. A value of 4096m or higher is recommended for compiler work.
# Example vmoptions adjustment.
# Locate the vmoptions file in your RustRover installation directory.
# Increase the maximum heap size to handle the large monorepo.
-Xmx4096m
Debugging compiler code works seamlessly once the setup is complete. You can attach the RustRover debugger to x.py test runs or cargo dev commands. Set breakpoints in the compiler source, run the test, and inspect variables as the compiler executes. The debugger understands the compiler's internal types and provides full stack traces.
Bump your heap size before the IDE starts swapping. Your machine will thank you.
Pitfalls and error codes
Even with the correct setup, you may encounter issues. Most problems stem from toolchain mismatches, stale configuration, or memory constraints.
If you see E0432 (unresolved import) errors on standard library items or compiler internals, the toolchain link is likely broken. The IDE is pointing to a different Rust installation than the one used by the build system. Re-run cargo dev setup intellij to refresh the link.
error[E0432]: unresolved import `rustc_span::Symbol`
--> src/tools/clippy/clippy_lints/src/lib.rs:12:5
|
12 | use rustc_span::Symbol;
| ^^^^^^^^^^ use of undeclared crate or module `rustc_span`
If completions are missing for specific crates, the index may be stale. The compiler repository changes frequently. After pulling new commits, run the setup command again to update the project configuration.
# Refresh the IDE configuration after pulling changes.
# This ensures rust-analyzer sees the latest crate structure.
cargo dev setup intellij
Memory errors in the IDE manifest as slow performance, frozen UI, or crash dialogs. Check the vmoptions file and increase the heap size. You can also exclude non-essential directories from indexing to reduce the load. Mark directories like tests/ or benchmarks/ as excluded in the project settings if you do not need to edit them frequently.
Keep the heap size high. The indexer will eat it anyway.
Choosing your tool
The Rust ecosystem offers multiple development environments. The right choice depends on your workflow, hardware, and contribution goals.
Use RustRover when you prefer a full-featured IDE with integrated debugging, advanced refactoring, and a unified UI for large codebases. RustRover provides the best experience for compiler contributors who need deep navigation and reliable tooling across the monorepo.
Use VS Code with the rust-analyzer extension when you want a lightweight editor that still offers excellent Rust support. VS Code is highly customizable and consumes less memory than RustRover, making it suitable for machines with limited resources or developers who prefer a modular extension ecosystem.
Use cargo dev setup intellij when you are working on compiler internals and need the IDE to resolve paths inside the monorepo. This command is the standard way to bridge the gap between the compiler's build system and IntelliJ-based IDEs.
Reach for x.py when you need to build the compiler, run stage-specific tests, or perform cross-compilation. The x.py script handles the complex bootstrapping process and manages toolchains that cargo cannot replicate. Use it for building and testing, not for day-to-day editing.
Pick manual configuration only if you are maintaining a custom fork with a non-standard layout that cargo dev cannot detect. Manual setup is error-prone and rarely necessary. The automated tools cover the vast majority of use cases.
Counter-intuitive but true: the more you rely on manual IDE configuration, the more likely you are to drift out of sync with the compiler's actual build behavior.