Flowistry: information flow analysis for Rust in VS Code

The problem Flowistry solves for readers of Rust code

Reading a long Rust function is mostly a filtering problem. A function takes arguments, mutates locals, iterates, and calls helpers, and only a fraction of those statements matter to the value you are trying to understand. Flowistry attacks that directly: it analyzes the information flow of a Rust program and determines whether it is possible for one piece of code to affect another. The IDE integration turns that analysis into a focus mode. When you click a variable or expression, Flowistry fades out code that does not influence the selection and is not influenced by it. The README uses a set-union function as its example: `orig_len` is not influenced by the for-loop, while `set.len()` is. The audience is anyone who reads Rust more often than they write it, including people working through large codebases such as the Rust compiler itself, which the README uses as a second example.

How Flowistry decides what to fade: ownership and information flow

The algorithm behind Flowistry was published as "Modular Information Flow through Ownership" at PLDI 2022, and the ownership framing explains the shape of the tool. Rather than tracking every byte through the program, the analysis reasons about how Rust's ownership and borrowing rules constrain which values can reach which others. That is what makes the analysis modular enough to run inside an editor.

The data flow visible in the repository is a two-stage pipeline. First, Flowistry type-checks your codebase at startup; the README says this may take a few minutes with many dependencies, and the results are cached in the `target/flowistry` directory. Second, once you are in focus mode, Flowistry computes information flow for the function your cursor is in, and the status bar reports when the analysis finishes. The README warns this can take up to 15 seconds for larger functions. The workspace layout matches that split: `crates/` holds the analysis crates, including the `flowistry` crate published to crates.io, while `ide/` holds the VS Code extension. The workspace pins its compiler-facing dependencies tightly, with `rustc_plugin` and `rustc_utils` both at `=0.15.0-nightly-2026-05-01` and `indexical` at `0.9.3`, which tells you the analysis is built on nightly compiler internals rather than a stable API.

Installing Flowistry in VS Code and running focus mode

The supported path is the extension itself. The README says Flowistry is available on the Visual Studio Marketplace and the Open VSX Registry; in VS Code you open the Extensions pane, search for "Flowistry", click Install, then open a Rust workspace and wait for the tool to finish installing. Two platform caveats are stated up front: NixOS is not yet supported, and ARM targets such as M1 Macs cannot use pre-built binaries, so Flowistry is built from scratch there, which the README says takes a few more minutes.

If you want to build from source, the README gives these steps. The first block installs the Flowistry binaries from the repository, and the second builds the VS Code extension and links it into your extensions directory. Note that the link target is `~/.vscode/extensions/flowistry`.

# Install flowistry binaries
git clone https://github.com/willcrichton/flowistry
cd flowistry
cargo install --path crates/flowistry_ide

# Install vscode extension
cd ide
npm install
npm run build
ln -s $(pwd) ~/.vscode/extensions/flowistry

Once installed, open a Rust workspace in VS Code. A Flowistry icon appears in the bottom toolbar, and startup begins with type-checking, which the README says may take a few minutes for a workspace with many dependencies. When the loading icon disappears, run the "Toggle focus mode" command; the default shortcut is Ctrl+R Ctrl+A, or Cmd+R Cmd+A on Mac, and there is also a Flowistry context menu. In focus mode, put your cursor on a variable and Flowistry infers the focus region from it, highlights the focused code in gray, and fades everything outside it.

Two operational details are worth knowing before you commit. Type-check results live in `target/flowistry`; delete that folder and Flowistry recomputes types, and the README notes that for a large codebase the directory may take a fair amount of disk space. Also, the README states the latest Flowistry has a Maximum Supported Rust Version of 1.73 and is not guaranteed to work with features implemented after 1.73, so a workspace on a newer toolchain is a real risk rather than a theoretical one.

Where Flowistry breaks down: interior mutability and function boundaries

The limitations section is unusually candid, and it is the part to read before adopting. Flowistry does not completely handle interior mutability, so code that mutates through `Cell`, `RefCell` or similar abstractions may not be classified the way you expect. A focus region may include more code than you expect, which means the fade is a conservative approximation rather than a precise slice. Not all code is selectable, so some expressions simply will not respond to a click. The sharpest constraint is that nested functions cannot be analyzed together, including closures and async; if the logic you care about is spread across a closure and its enclosing function, focus mode cannot connect them. The README also points readers to a FAQ entry titled "Why does Flowistry highlight (or not) this code?" for cases where the result surprises them, which is an admission that the analysis needs explaining rather than being self-evident.

Flowistry versus rust-analyzer and the rustc plugin route

The obvious comparison is rust-analyzer, and the README addresses it head-on with a FAQ entry asking why Flowistry is not part of it. The difference in approach is the kind of question each tool answers. rust-analyzer is a language server: it resolves names, types, references and completions, and its "find all references" works on syntactic and semantic identity. Flowistry asks a different question, whether one piece of code can affect another, which is a dataflow property rather than a symbol lookup. That is why Flowistry needs its own type-checking pass and a cache directory, and why it can fade code that a reference search would leave visible.

The second route is the `flowistry` crate itself. The README points to https://crates.io/crates/flowistry for anyone interested in the underlying analysis, with documentation hosted at willcrichton.net because Docs.rs does not support crates using `#![feature(rustc_private)]`. Choosing the crate over the extension means you are building on nightly compiler internals and owning the integration work; choosing the extension means accepting the 1.73 ceiling and the editor's startup cost.

Licence and the cost of keeping Flowistry current

Flowistry is MIT licensed, which is permissive and imposes no copyleft obligation on code that merely uses the extension. The dependency side is the more interesting question, and it is a technical one rather than a legal one: the workspace pins `rustc_plugin` and `rustc_utils` to an exact nightly build dated 2026-05-01, and the README ties the tool to a Maximum Supported Rust Version of 1.73. Exact pins on compiler internals mean upgrades are not drop-in. Each release of Flowistry has to be revalidated against a compiler version, and the release history reflects that: the recent releases list shows v0.5.44 on 2025-09-22, v0.5.42 on 2024-07-29 and v0.5.41 on 2023-11-07, so the cadence is measured in months and sometimes more than a year between tagged versions. The repository's last push was on 2026-05-22, which is the most recent activity signal available. If your team tracks Rust stable closely, budget for the possibility that Flowistry lags behind your toolchain rather than the other way around.

Editorial conclusion

Adopt Flowistry if you spend your day reading unfamiliar Rust functions and you are willing to pin a toolchain to Rust 1.73, since the README states the latest Flowistry has a Maximum Supported Rust Version of 1.73 and is not guaranteed to work with features implemented after it. Do not adopt it if you need analysis that crosses function boundaries, because the limitations section says nested functions, closures and async cannot be analyzed together, or if you work on NixOS, which the README says is not yet supported. Before relying on it, verify two things: that your workspace type-checks under the supported toolchain, and how much disk the `target/flowistry` cache consumes on your largest crate.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. willcrichton/flowistry on GitHub