GO — Healthy across the board

• Last commit today
• 10 active contributors
• Distributed ownership (top contributor 30% of recent commits)
• Apache-2.0 licensed
• CI configured
• Tests present

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests}

Miri is an interpreter for Rust's Mid-level Intermediate Representation (MIR) that detects undefined behavior (UB) at runtime. It can execute binaries and test suites to catch memory safety violations like out-of-bounds accesses, use-after-free, alignment issues, invalid enum discriminants, data races, and violations of aliasing rules (Stacked Borrows / Tree Borrows). It also serves as a cross-architecture emulation tool for testing byte-level data manipulation on different endianness targets. Single-crate design (src/ under miri/) with a bin driver (miri binary via Cargo.toml [[bin]]) wrapping a library (test = true). Separate bench-cargo-miri/ contains standalone benchmark projects (backtraces, big-allocs, serde1/2, range-iteration, slice-chunked, string-replace). Testing uses ui_test framework for compare-output style tests, with CI orchestrated via GitHub Actions workflows.

Rust library and systems programmers who need to validate unsafe code correctness, and contributors to the Rust project itself who want to catch UB regressions during compiler development. It's also used by crate maintainers and security researchers testing untrusted code.

Miri is actively developed and maintained as part of the Rust project (rust-lang/miri), with comprehensive CI/CD in .github/workflows/ci.yml and sysroots.yml. The codebase is large (4.2M lines of Rust) with feature flags, benchmarks in bench-cargo-miri/, and UI tests (ui_test dependency). However, it explicitly documents in README that it does not catch every UB violation—it's an approximation tool, not a specification, making it 'production-ready for catching many UB categories' but not a complete guarantee.

The main risk is tight coupling to the Rust compiler internals via rustc_private feature (noted in Cargo.toml metadata), meaning breaking changes could cascade with new Rust versions. The dependency count is moderate but includes OS-specific deps (libc, nix for Linux, capstone for x86 disassembly), increasing maintenance surface. The genmc-sys and native-lib optional features add complexity for memory-model checking and FFI. No obvious abandonment risk given rust-lang organization, but contributors should expect frequent compiler-driven changes.

Based on file structure, active areas include: (1) CI/workflow refinement (.github/workflows/), (2) Benchmarking suite maintenance (multiple bench-cargo-miri projects with dated Cargo.lock files), (3) Feature development indicated by [features] section with genmc (memory-model checking), stack-cache, native-lib, and experimental aliasing modes. The edition = "2024" and chrono-tz / mio dependencies suggest recent updates for time handling and async I/O support.

git clone https://github.com/rust-lang/miri.git
cd miri
cargo build --release  # or cargo build for debug
cargo test             # runs lib tests
./miri --help         # see interpreter flags
# To test a Rust project with miri:
cargo miri test --manifest-path /path/to/project/Cargo.toml

Daily commands:

cargo run -- /path/to/binary arg1 arg2    # Run a binary under miri
MIRIFLAGS="-Zmiri-disable-isolation" cargo run -- binary  # Access real system APIs
cargo miri test --test my_test             # Run test suite
# Benchmark:
cd bench-cargo-miri/serde1 && cargo miri run --release

• src/lib.rs — Core library entry point containing the MIR interpreter's main logic and public API that all contributors must understand
• cargo-miri/src/main.rs — Entry point for the cargo-miri command-line tool that users invoke to run Miri on their Rust projects
• src/shims/mod.rs — Central shim module providing implementations of standard library functions that Miri intercepts during interpretation
• src/eval.rs — Core evaluation loop that interprets MIR statements and expressions, the heart of the interpreter
• src/machine.rs — Machine state abstraction representing the virtual Rust execution environment with memory, threads, and stacks
• Cargo.toml — Project manifest defining dependencies, workspace structure, and edition requirements for the entire project
• README.md — High-level overview of Miri's purpose, capabilities for detecting undefined behavior, and getting started guide

Add support for a new standard library intrinsic

1. Identify the intrinsic's MIR representation in rustc and locate it in shim dispatcher (src/shims/mod.rs)
2. Add a new branch in the match statement for the function name (src/shims/mod.rs)
3. Implement the logic by reading from the interpreter's memory, performing the operation, and writing results back (src/shims/mod.rs)
4. Add test case in tests/pass/ or tests/fail/ directory to verify behavior and UB detection (tests/pass/)

Add detection for a new undefined behavior pattern

1. Determine where in the execution flow the UB should be caught (memory access, alignment, etc.) (src/memory.rs)
2. Add validation logic at the appropriate check point in memory operations or machine state transitions (src/memory.rs)
3. Create an error variant in the diagnostics module (src/diagnostics.rs)
4. Emit error with context information (backtrace, memory state) when UB is detected (src/diagnostics.rs)
5. Add regression test with code that exhibits the UB pattern (tests/fail/)

Add a new command-line option to cargo-miri

1. Define argument in the arg parser with help text (cargo-miri/src/arg.rs)
2. Pass parsed argument through the execution phases (cargo-miri/src/phases.rs)
3. Read the flag in the machine initialization or configuration code (src/machine.rs)
4. Implement feature logic in appropriate interpreter component based on flag (src/lib.rs)

Add support for a new target platform (Unix-like OS)

1. Add OS-specific system call implementations following POSIX conventions (src/shims/unix.rs)
2. Implement or update target-specific constants and types (page size, signal numbers, etc.) (src/machine.rs)
3. Update environment setup logic if needed for platform-specific variables (cargo-miri/src/setup.rs)
4. Add CI job for the new platform (.github/workflows/ci.yml)

• Rust with rustc compiler integration — Miri must hook deeply into rustc's compilation pipeline to access MIR and implement a Rust-compatible interpreter with precise semantics
• Stacked Borrows / Tree Borrows — Provides formal models for detecting aliasing violations and enforce Rust's borrow checker rules at runtime for unsafe code
• LLVM-style bit-level memory model — Enables detection of low-level UB like uninitialized bytes, misalignment, and out-of-bounds access at the granularity Rust cares about
• Thread-local and atomic operation emulation — Allows detection of data races and weak memory effects in concurrent code without requiring actual OS threads
• Sysroot compilation via rustc — Ensures the standard library runs under Miri's interpreter, catching UB in std library code paths

• Interpret MIR rather than compile to native code

  • Why: Interpretation allows fine-grained UB detection and control over memory operations; compilation would lose visibility
  • Consequence: Execution is 10–100× slower than native code; acceptable for testing but not for production use

• Single-threaded deterministic interleaving by default

  • Why: Simplifies reproducibility and makes data race detection tractable without expensive state explosion
  • Consequence: Some subtle race conditions on weak memory models (ARM, PowerPC) may not be detected; users must opt into weak memory emulation

• Experimental Tree Borrows as optional alternative to Stacked Borrows

  • Why: Stacked Borrows is overly restrictive for some safe Rust patterns; Tree Borrows offers more precision but is less mature
  • Consequence: Different borrow models may accept/reject same code; Tree Borrows is not yet stable for production

• No ahead-of-time compilation; each invocation interprets fresh

  • Why: Keeps implementation simple and avoids caching issues; MIR is always correct to current rustc
  • Consequence: No persistent compilation cache; slower on large projects with repeated runs

• Not a replacement for static analysis or the borrow checker — only detects runtime UB on executed paths
• Does not guarantee detection of all undefined behavior — only catches UB in code paths actually executed by tests/main
• Not suitable for real-time or production execution — designed for testing and validation only
• Does not support all Rust features (e.g., inline assembly, some FFI patterns require explicit configuration)
• Does

Rustc Nightly Dependency: Miri must be kept in sync with rustc nightly because it uses rustc_private features (noted in Cargo.toml metadata). Releases lag compiler changes. Isolation Mode Default: By default, MIRI_ISOLATION=1 (set via deterministic 'fake' system calls); if a test mysteriously hangs or fails with time/random, it's likely hitting the fake RNG or blocked I/O—set MIRIFLAGS="-Zmiri-disable-isolation" as documented in README. Edition Mismatch: edition = "2024" is unusual and may not parse on stable—requires nightly Rust. Benchmarks Need Maintenance: bench-cargo-miri/ subdirectories have independent Cargo.lock files; running benchmarks may need explicit feature flags. Platform-Specific Shims: libc/nix deps for Unix-only features (ptrace, mman, signal) mean some UB checks are OS-dependent; Linux-specific: genmc-sys and ipc-channel for advanced memory model checking.

• Undefined Behavior (UB) Detection — Miri's core mission is catching UB at runtime; understanding what counts as UB in Rust (alignment, enum discriminants, pointer provenance) is essential to interpreting Miri's diagnostics and writing safe unsafe code.
• Stacked Borrows & Tree Borrows — These are Miri's aliasing rule implementations (default and opt-in); violations are caught and reported. Understanding the stack model vs. tree model is key to fixing 'invalidated reference' errors.
• Mid-level Intermediate Representation (MIR) — Miri executes MIR bytecode directly (not LLVM), so understanding MIR's instruction set, control flow, and type system is critical to understanding what Miri is actually interpreting.
• Deterministic Execution & Isolation — Miri virtualizes system calls (time, RNG, environment) for determinism by default; setting MIRIFLAGS=-Zmiri-disable-isolation is a common debugging step when tests behave unexpectedly.
• Memory Layout & Alignment Checking — Miri enforces Rust's memory alignment and size requirements; errors like 'alignment check failed' indicate UB from unaligned access or incorrect transmute usage.
• Shim (System Call Emulation) — Miri's src/shims/ directory contains implementations of libc, POSIX, and intrinsic functions; understanding shims is essential for adding support for new stdlib APIs or native functions.
• Cross-Endian Emulation — Miri can run the same binary as if it's on big-endian or little-endian targets; this is useful for testing byte-order-dependent code (bitfields, serialization) without a cross-compiler.

• rust-lang/rust — Parent project and source of rustc_private APIs; Miri tracks compiler changes and UB definitions here
• rust-lang/rfcs — Aliasing rule RFCs (Stacked Borrows, Tree Borrows) and UB definitions that Miri implements; governance of what counts as UB in Rust
• model-checking/kani — Complementary tool for bounded model checking of Rust code; while Miri is dynamic execution, Kani does symbolic verification—often used together
• iarna/cargo-script — Unrelated in purpose but shows adjacent tool patterns for wrapping cargo for custom Rust execution modes
• rust-lang/polonius — Alternative borrow checker framework that Miri may use or reference for advanced aliasing checks beyond Stacked Borrows

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive UI tests for native-lib feature interactions

The repo has a [[test]] name = "ui" harness = false test framework in place and a native-lib feature (enabled by default with platform-specific dependencies like libffi, libloading, nix), but there's no visible test coverage for the error messages and behavior of native-lib interactions. New contributors can add UI tests to ensure error messages are clear when native library calls fail, similar to how the existing ui_test framework validates compiler error outputs.

• [ ] Review existing ui test structure in tests/ui/ directory
• [ ] Create new test cases for native-lib feature errors (libffi, libloading failures)
• [ ] Add .stderr and .rs test pairs for cases like: invalid FFI function signatures, unsupported library operations on different platforms
• [ ] Document native-lib testing patterns in CONTRIBUTING.md with specific examples

Implement feature-gated benchmarks for stack-cache and expensive-* features

The Cargo.toml shows expensive-* features (incomplete in the snippet) and a stack-cache feature, with a bench-cargo-miri/ directory containing multiple benchmark projects. However, there's no CI workflow or benchmark harness that validates performance impact of these features. A contributor could create a benchmark runner that conditionally compiles and executes benchmarks based on enabled features.

• [ ] Create a new benchmark harness script in bench-cargo-miri/ root that runs benches conditionally by feature
• [ ] Add feature-specific benchmark cases (e.g., bench-cargo-miri/stack-cache/ for stack-cache benchmarks)
• [ ] Document in bench-cargo-miri/README.md how to run feature-specific benchmarks
• [ ] Optionally add a GitHub Actions workflow (.github/workflows/bench.yml) to track performance regressions

Add unit tests for cargo-miri argument parsing (cargo-miri/src/arg.rs)

The cargo-miri/src/arg.rs file exists for CLI argument handling but there's no visible dev test coverage for argument parsing edge cases. This is a critical component that converts cargo commands into miri flags. Contributors can add robust unit tests for parsing complex flag combinations, especially for new features like genmc mode and platform-specific options.

• [ ] Add #[cfg(test)] module at the end of cargo-miri/src/arg.rs with test cases
• [ ] Cover edge cases: conflicting flags, missing required arguments, platform-specific argument validation
• [ ] Test integration between cargo flags and miri-specific arguments (e.g., --miri-extra-flags with spaces)
• [ ] Update CONTRIBUTING.md with guidance on testing argument parsing changes

• Add missing serde_json serialization for diagnostic output: The Cargo.toml has serde_json as optional, but looking at the file structure there's no obvious JSON export for Miri's UB findings. Add a flag like -Zmiri-export-diagnostics-json and serialize violations to JSON; useful for tooling integration. Start in src/lib.rs or error reporting module.
• Expand chrono-tz timezone support in fake time shim: Miri now depends on chrono-tz (0.10) for deterministic time, but tests may not cover all timezone edge cases. Add test cases in tests/ for DST transitions, leap seconds, and cross-timezone arithmetic; document fake time behavior in CONTRIBUTING.md.
• Benchmark suite documentation & CI dashboard: bench-cargo-miri/ has 7 projects (backtraces, serde1/2, range-iteration, etc.) but no README explaining which benchmark tests which Miri feature. Create bench-cargo-miri/README.md with: (1) what each bench target stresses (e.g., serde1 = aliasing rules, big-allocs = heap fragmentation), (2) expected baseline numbers, (3) how to run locally and interpret output. Link from main README.

The Miri codebase demonstrates generally good security practices as a Rust interpreter project. No critical vulnerabilities were identified based on the static analysis of the provided structure and configuration. However, there are configuration issues (invalid edition field, incomplete feature definition) that should be addressed. The project's optional use of native FFI dependencies introduces some complexity that requires careful management. The presence of comprehensive testing infrastructure and the focus on undefined behavior detection are positive security indicators. Recommended actions: (1) Fix the Cargo.toml edition and feature configuration issues, (2) Add explicit security documentation for optional native dependencies, (3) Continue maintaining the strong testing and code review practices that appear to be in place for this foundational Rust tooling project.

• Medium · Outdated Rust Edition Configuration — Cargo.toml. The Cargo.toml specifies edition = '2024', which is not a valid Rust edition. Valid editions are 2015, 2018, and 2021. This could indicate a misconfiguration or future-planning error that may cause build failures. Fix: Update edition to a valid value such as '2021' (the current stable edition) or verify if this is intentional for future toolchain compatibility.
• Medium · Incomplete Feature Configuration — Cargo.toml - [features] section. The [features] section in Cargo.toml has an incomplete entry 'expensive-' that appears to be cut off. This could indicate incomplete configuration or merge conflicts that affect feature flag behavior. Fix: Complete the 'expensive-' feature definition or remove it if not needed. Verify the Cargo.toml file is not corrupted or incomplete.
• Low · Optional Dependency Without Explicit Feature Bindings — Cargo.toml - target-specific dependencies. Multiple optional dependencies (libffi, libloading, serde, nix, ipc-channel, capstone, genmc-sys) are defined but their feature flags in the [features] section are not fully visible (truncated in provided content). This could lead to confusion about which features enable which dependencies. Fix: Ensure all optional dependencies have corresponding feature flags documented in the [features] section and that users understand the security implications of enabling each feature.
• Low · Native FFI Dependencies Without Explicit Safety Documentation — Cargo.toml - libffi, libloading, capstone, nix dependencies. The codebase includes optional native library dependencies (libffi, libloading, capstone, nix) that interface with system libraries. While optional, enabling these features increases the attack surface through FFI boundaries. Fix: Add explicit documentation about the security considerations of each native library dependency. Consider implementing additional validation when these features are enabled.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/rust-lang/miri shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live rust-lang/miri repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/rust-lang/miri.

What it runs against: a local clone of rust-lang/miri — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in rust-lang/miri | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 30 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of rust-lang/miri. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/rust-lang/miri.git
#   cd miri
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of rust-lang/miri and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "rust-lang/miri(\\.git)?\\b" \\
  && ok "origin remote is rust-lang/miri" \\
  || miss "origin remote is not rust-lang/miri (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "src/lib.rs" \\
  && ok "src/lib.rs" \\
  || miss "missing critical file: src/lib.rs"
test -f "cargo-miri/src/main.rs" \\
  && ok "cargo-miri/src/main.rs" \\
  || miss "missing critical file: cargo-miri/src/main.rs"
test -f "src/shims/mod.rs" \\
  && ok "src/shims/mod.rs" \\
  || miss "missing critical file: src/shims/mod.rs"
test -f "src/eval.rs" \\
  && ok "src/eval.rs" \\
  || miss "missing critical file: src/eval.rs"
test -f "src/machine.rs" \\
  && ok "src/machine.rs" \\
  || miss "missing critical file: src/machine.rs"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 30 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~0d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/rust-lang/miri"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.