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/willcrichton/flowistry 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.

GO — Healthy across all four use cases

• Last commit 5d ago
• 4 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Small team — 4 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 94% of recent commits

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

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

What it runs against: a local clone of willcrichton/flowistry — 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 willcrichton/flowistry | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | 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 ≤ 35 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of willcrichton/flowistry. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/willcrichton/flowistry.git
#   cd flowistry
#
# 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 willcrichton/flowistry and re-run."
  exit 2
fi

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT 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 "crates/flowistry/src/lib.rs" \\
  && ok "crates/flowistry/src/lib.rs" \\
  || miss "missing critical file: crates/flowistry/src/lib.rs"
test -f "crates/flowistry/src/infoflow/analysis.rs" \\
  && ok "crates/flowistry/src/infoflow/analysis.rs" \\
  || miss "missing critical file: crates/flowistry/src/infoflow/analysis.rs"
test -f "crates/flowistry/src/mir/engine.rs" \\
  && ok "crates/flowistry/src/mir/engine.rs" \\
  || miss "missing critical file: crates/flowistry/src/mir/engine.rs"
test -f "crates/flowistry/src/infoflow/dependencies.rs" \\
  && ok "crates/flowistry/src/infoflow/dependencies.rs" \\
  || miss "missing critical file: crates/flowistry/src/infoflow/dependencies.rs"
test -f "crates/flowistry/src/mir/aliases.rs" \\
  && ok "crates/flowistry/src/mir/aliases.rs" \\
  || miss "missing critical file: crates/flowistry/src/mir/aliases.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 35 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~5d)"
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/willcrichton/flowistry"
  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).

Flowistry is a Rust IDE plugin that performs information flow analysis to identify which code statements can influence or be influenced by a specific piece of code you click on. It visualizes data and control dependencies by fading out irrelevant code, helping developers focus on the subset of a function that matters for a given task. The core engine (in crates/flowistry/src/infoflow/ and crates/flowistry/src/mir/) analyzes Rust's MIR (Mid-level Intermediate Representation) to compute these dependencies. Monorepo with crates/flowistry/ as the core analysis library and crates/bench_utils/ for benchmarking infrastructure. The main logic is split into three modules: mir/ (MIR traversal and place aliasing analysis), infoflow/ (dependency graph construction and backward/forward slicing), and extensions/ (utility methods). The IDE plugin integration happens elsewhere (not in this repo structure).

Rust developers reading complex functions who want to understand code dependencies without manually tracing data flow. Particularly useful for compiler engineers, systems programmers, and anyone working in large Rust codebases where functions have intertwined logic.

Actively maintained and production-ready: the codebase has comprehensive test coverage (tests/ directory with specific backward_slice tests), published on crates.io, has CI workflows for tests/benchmarks/releases (.github/workflows/), and the algorithm was published at PLDI 2022. This is a mature research-backed tool, not experimental.

Low risk: single maintainer (willcrichton) but well-documented and stable. Main risk is tight coupling to rustc internals via rustc_plugin and rustc_utils (pinned to nightly 2026-05-01), meaning each Rust nightly update may require maintenance. Dependency count is minimal and deliberate.

The project appears stable with benchmarking infrastructure in place (benches/tests/min and benches/tests/max directories test performance across scenarios like nested_struct, lifetimes, and infoflow). No indication of active breaking changes in the file structure, suggesting maintenance mode focused on stability and performance tuning.

git clone https://github.com/willcrichton/flowistry.git
cd flowistry
cargo build --release
cargo test

Note: requires Rust nightly (rustup required, as specified in Makefile.toml and Cargo.toml workspace dependencies).

Daily commands:

cargo build
cargo test
cargo run --example example

Benchmarks run via cargo bench (configured in Cargo.toml with [profile.bench] debug = true). The example at crates/flowistry/examples/example.rs demonstrates the API.

• crates/flowistry/src/lib.rs — Main library entry point that exports the public API and orchestrates the core analysis modules for information flow computation.
• crates/flowistry/src/infoflow/analysis.rs — Core information flow analysis implementation that determines dependencies between code locations—every feature relies on this analysis logic.
• crates/flowistry/src/mir/engine.rs — MIR analysis engine that processes Rust's intermediate representation; foundational for all backward slice and dependency tracking.
• crates/flowistry/src/infoflow/dependencies.rs — Defines dependency tracking data structures and algorithms that answer 'does X affect Y?' queries used throughout the codebase.
• crates/flowistry/src/mir/aliases.rs — Alias analysis for tracking which memory locations may refer to the same data—critical for precision in information flow queries.
• crates/flowistry/src/extensions.rs — Trait extensions that add helper methods to rustc types; used pervasively across MIR and analysis modules.
• Cargo.toml — Workspace configuration with critical nightly Rust compiler plugin dependencies (rustc_plugin, rustc_utils) that enable MIR analysis.

Add a new information flow analysis query

1. Define a new query type or extend QueryResult in dependencies.rs to represent your new query (e.g., does value X flow to output Y?) (crates/flowistry/src/infoflow/dependencies.rs)
2. Implement the query logic in analysis.rs by adding a new method to the InfoflowAnalysis struct that traverses the dependency graph (crates/flowistry/src/infoflow/analysis.rs)
3. Export the new query through the public API in lib.rs (crates/flowistry/src/lib.rs)
4. Add test cases as backward_slice/.txt and backward_slice/.txt.expected pairs to verify correctness (crates/flowistry/tests/backward_slice)

Improve alias analysis precision for a new type pattern

1. Add pattern matching logic in aliases.rs to recognize the new type or memory pattern (crates/flowistry/src/mir/aliases.rs)
2. Update placeinfo.rs if you need to track new metadata about places resulting from the pattern (crates/flowistry/src/mir/placeinfo.rs)
3. Add extension methods in extensions.rs if the pattern requires new rustc type introspection (crates/flowistry/src/extensions.rs)
4. Create test cases to verify the improved alias precision in the backward_slice test suite (crates/flowistry/tests/backward_slice)

Add support for a new Rust language construct (e.g., new control flow)

1. Update the MIR engine in engine.rs to handle the new construct's MIR representation (crates/flowistry/src/mir/engine.rs)
2. Extend dependencies.rs and analysis.rs to model how information flows through the new construct (crates/flowistry/src/infoflow/analysis.rs)
3. Add extension helper methods in extensions.rs for querying properties of the new construct (crates/flowistry/src/extensions.rs)
4. Write backward_slice test cases covering the new construct with various data flow scenarios (crates/flowistry/tests/backward_slice)

• Rust nightly compiler (rustc_plugin, rustc_utils) — Flowistry performs analysis on Rust's MIR (intermediate representation), which requires access to unstable rustc internals only available via nightly compiler plugins.
• MIR-based analysis rather than AST — MIR is closer to actual runtime semantics, enabling precise tracking of mutations, aliases, and control flow—critical for answering 'does X affect Y?' accurately.
• Indexical (version 0.9.3 with rustc feature) — Provides efficient sparse index-based data structures for representing MIR location sets and dependency graphs without allocating dense vectors.

• MIR-based analysis instead of high-level type/AST analysis

  • Why: MIR is more precise for tracking data flow and mutations, but requires tighter coupling to rustc compiler internals.
  • Consequence: High maintenance burden: any rustc version change may break analysis; limited to nightly-only usage. Gain: highly accurate backward/forward slices even for complex aliasing.

• Conservative alias analysis (sound but not complete)

  • Why: Alias analysis must be sound (no false negatives) to avoid missing dependencies, but can be conservative (false positives acceptable).
  • Consequence: User may see more highlighted code than strictly necessary; eliminates risk of silently missing relevant code.

• Per-function analysis granularity

  • Why: Analyzing entire crates or call graphs at once would be prohibitively expensive for IDE responsiveness.
  • Consequence: Function boundaries are analysis units; cross-function dependencies inferred through call site analysis. Trade-off: speed vs. whole-program precision.

• Test-driven verification with .txt/.txt.expected files

  • Why: Dataflow analysis correctness is hard to verify; snapshots of input code and expected sliced output provide ground truth.
  • Consequence: Regression tests are verbose but catch subtle analysis bugs that automated unit tests might miss.

• Real-time IDE integration or LSP server implementation (flowistry is a library; IDE plugins are external)
• Whole-program or cross-crate analysis in a single pass (designed for per-function queries)
• Support for stable Rust compiler (requires nightly rustc_plugin unstable API)
• Handling of unsafe code semantics (treats unsafe blocks conservatively without custom semantics)
• Deterministic performance guarantees (analysis complexity varies by function structure)

Nightly Rust pinned to 2026-05-01: workspace dependencies pin to a specific rustc nightly date; updating Rust requires explicit Cargo.toml changes and may break MIR analysis due to compiler internals shifting. Interior mutability limitations: the README explicitly notes Flowistry does not completely handle interior mutability (Cell, RefCell, Mutex), meaning false positives in dependency detection for such code. MIR-level analysis: the tool works on MIR, not source code, meaning some source-level constructs may be unrecognizable in test outputs. Nested functions unsupported: closures and async blocks cannot be analyzed with their containing function (documented limitation).

• Mid-level Intermediate Representation (MIR) — Flowistry operates on Rust's MIR, not source code; understanding MIR statements, places, and rvalues is essential to debugging analysis results and contributing to mir/engine.rs or mir/placeinfo.rs
• Information Flow Analysis — The core algorithm: determines whether one piece of code can influence another through data or control dependencies; the PLDI 2022 paper formalizes this for Rust ownership
• Backward and Forward Program Slicing — The user-visible feature: given a selection, backward slicing finds all code that influences it, forward slicing finds all code it influences; implemented in infoflow/analysis.rs
• Place Aliasing / Pointer Analysis — Critical for tracking when two different variable names (e.g., x and *px) reference the same memory; mir/aliases.rs handles this to avoid false negatives in dependency detection
• Control Dependence — Complements data flow analysis by tracking how branches (if/while/match) control whether code executes; necessary for accurate slicing of conditional statements
• Ownership Type System — Rust's ownership rules constrain information flow in ways that Flowistry leverages to avoid false positives; the algorithm is 'modular' precisely because ownership limits aliasing
• Interior Mutability — Known limitation: Flowistry struggles with Cell, RefCell, Mutex because these break the ownership-based reasoning; understanding this gap explains why certain patterns fail (documented in README Limitations)

• rust-lang/rust-analyzer — LSP server for Rust with dependency and hover analysis; Flowistry is a complementary tool that goes deeper into information flow rather than type information
• rust-lang/miri — Interprets Rust MIR for runtime behavior checking; shares the MIR analysis foundation with Flowistry but operates at runtime rather than static analysis
• willcrichton/flux — A related refinement type checker for Rust by the same author; shares similar goals of bringing advanced program analysis to Rust developers
• rust-lang/polonius — Borrow checker research project using similar graph-based dependency reasoning; Flowistry's ownership-based flow analysis builds on concepts from polonius
• tokio-rs/tokio — Common dependency in real Rust projects that Flowistry users analyze; not directly related but typical customer code analyzed by this tool

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 test coverage for crates/flowistry/src/mir/aliases.rs

The aliases.rs module is critical for MIR alias analysis but has no dedicated test file in crates/flowistry/tests/. The backward_slice tests exist but don't specifically target alias resolution logic. Adding focused unit and integration tests would improve confidence in alias tracking correctness and help catch regressions in future refactors.

• [ ] Create crates/flowistry/tests/mir_aliases/ directory with test cases
• [ ] Add tests for basic alias tracking scenarios (simple assignments, references, dereferences)
• [ ] Add tests for complex alias chains and mutual aliasing
• [ ] Add tests for edge cases with Box, Rc, or other wrapper types based on existing backward_slice patterns
• [ ] Run tests via cargo test and verify they pass

Add CI workflow for benchmark regression detection

The repo has bench.yml and Makefile.toml with benchmark infrastructure, but no automated workflow to detect performance regressions. This is crucial for a performance-sensitive project like Flowistry. A CI job should run benchmarks on PRs, compare against baseline, and fail if regressions exceed a threshold.

• [ ] Create .github/workflows/bench_check.yml that runs on pull_request
• [ ] Use cargo bench to run crates/flowistry/benches/main.rs on both PR and main branch
• [ ] Parse benchmark output and compare results (e.g., using a tool like critcmp or custom parsing)
• [ ] Add workflow that fails if any benchmark regresses by >5% (configurable threshold)
• [ ] Document the new workflow in crates/flowistry/benches/README.md

Expand test coverage for crates/flowistry/src/infoflow/recursive.rs

The recursive.rs module handles recursive information flow analysis but has minimal test coverage visible in the test directory structure. Recursive patterns (self-referential structs, recursive function calls) are complex and error-prone. Add specific integration tests to crates/flowistry/tests/infoflow_recursive/ covering recursive data structures and function chains.

• [ ] Create crates/flowistry/tests/infoflow_recursive/ directory
• [ ] Add test cases for recursive struct definitions (e.g., linked lists, trees)
• [ ] Add test cases for mutually recursive functions
• [ ] Add test cases for recursive closures and captured recursive types
• [ ] Ensure expected output files follow the .txt/.txt.expected pattern used in backward_slice tests
• [ ] Verify tests run successfully and document in crates/flowistry/benches/README.md if applicable

• Add test cases for interior mutability patterns (Cell, RefCell) in crates/flowistry/tests/backward_slice/ to document current limitations and establish a baseline for future improvements.
• Expand crates/flowistry/benches/tests/max/ and /min/ with additional stress tests for deeply nested structs (current nested_struct.rs is minimal) to identify performance cliffs.
• Document the MIR-to-source mapping in crates/flowistry/src/test_utils.rs with inline comments explaining how test .txt files (e.g., array_read.txt) correlate to MIR statements; currently undocumented for new contributors.

The codebase demonstrates reasonable security practices overall, with no obvious hardcoded credentials, injection vulnerabilities, or infrastructure misconfigurations detected in the provided artifacts. However, there are concerns regarding dependency management: the reliance on pinned nightly compiler versions from an unusual future date (2026-05-01) is a red flag that warrants investigation, and the use of exact version constraints prevents automatic security updates. The project appears to be a legitimate Rust analysis tool without obvious malicious intent, but dependency hygiene should be improved. No SQL queries, XSS vectors, or exposed secrets were identified in the file structure.

• High · Nightly Compiler Dependency on Pinned Date — Cargo.toml (workspace.dependencies). The project depends on a nightly version of rustc_plugin and rustc_utils pinned to a specific date (2026-05-01). Using nightly compiler versions introduces stability risks and potential security issues, as nightly builds may contain unvetted code changes. The future date is also suspicious and may indicate a configuration error. Fix: Either migrate to stable Rust versions when possible, or document the nightly requirement clearly. If nightly is necessary, use a version from a recent stable cut or MSRV-compatible nightly, and regularly audit for security updates.
• Medium · Missing Dependency Version Constraints — Cargo.toml (workspace.dependencies). The workspace dependencies use exact version pinning (=0.15.0-nightly-2026-05-01 and =0.15.0-nightly-2026-05-01) which prevents automatic security updates. If a critical security patch is released for rustc_plugin or rustc_utils, the project will not automatically receive it unless manually updated. Fix: Consider using semantic versioning constraints (e.g., ^0.15.0-nightly-2026-05-01) to allow patch and minor version updates, or establish a regular dependency update schedule.
• Medium · Indexical Dependency with Default Features Disabled — Cargo.toml (workspace.dependencies - indexical). The indexical dependency explicitly disables default features while enabling only the 'rustc' feature. This selective feature enablement could mask or expose unexpected behavior. Without understanding the feature landscape, there's a risk of missing important security-related features. Fix: Document why default features are disabled. Review the indexical crate's features documentation to ensure no security-relevant features are inadvertently disabled.

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

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

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