Rust-Analyzer-Based Design Pipeline

• Rust-analyzer-based design is an approach that leverages incremental analysis to support interactive editing, refactoring, and formal verification in Rust.
• The design organizes development tools into layered components including editor integration, server orchestration, and verification backends for precise syntactic and semantic analysis.
• REM 2.0 exemplifies this pipeline by providing rapid extract-function operations, iterative borrow-checker repairs, and machine-checked equivalence proofs via LLBC and Coq.

A Rust-analyzer-based design refers to development tools or automated refactoring and verification pipelines architected atop rust-analyzer—an incremental, persistent analysis engine for Rust—enabling interactive editing, refactoring, and language-integrated practices, including formal verification. Such designs leverage rust-analyzer’s capability to provide rapid, precise access to Rust’s syntax, type information, and lifetime relationships, forming the substrate for advanced developer tooling. The REM 2.0 toolchain is a flagship example, incorporating rust-analyzer with downstream formal methods to provide both fast refactorings and machine-checked equivalence proofs over Rust programs (Britton et al., 27 Jan 2026).

1. High-Level Architecture and Workflow

A canonical rust-analyzer-based design, as manifest in REM 2.0, organizes the toolchain into three principal layers: editor integration, server/daemon orchestration, and verification backends.

• Editor integration: The VSCode frontend communicates with the REM 2.0 daemon via JSON-RPC. Users can invoke extract-function assists, receive immediate feedback, and request optional verification of refactorings.
• REM server (daemon/CLI): The server handles extraction, repair, and (optionally) verification requests. Extraction leverages rust-analyzer’s built-in transformation assists; repair orchestrates incremental compilation to iteratively resolve borrow checker issues, adjusting lifetimes and type signatures until the refactored program typechecks.
• Verification backend: For proofs of behavioural equivalence, the server invokes a pipeline that uses CHARON to translate Rust’s MIR (Mid-level Intermediate Representation) into Low-Level Borrow Calculus (LLBC), and AENEAS to functionalize LLBC to Coq, emitting equivalence lemmas automatically discharged by Coq’s tactic engine (Britton et al., 27 Jan 2026, Ho et al., 2024).

The architecture enables low-latency extract-function and verification operations, supporting rapid developer feedback.

2. Core Language and Semantics

Rust-analyzer-based verification tools, such as REM 2.0, target a subset of Rust capturing essential features with formal semantics:

• Ownership and borrowing: All explicit moves, borrows, and lifetime relationships are modeled. Only safe Rust is supported (no unsafe code, no interior mutability).
• Control flow: Loops, early returns, and control-flow primitives (break, continue, return), materialized as constructs like std::ops::ControlFlow.
• Generics and trait bounds: The pipeline supports generic parameters and limited higher-ranked lifetimes and trait objects.
• Excluded features: Concurrency, closures, pinned data, divergent return types (!), and interior mutability are outside the current formal verification subset.

LLBC semantics are defined in small-step operational style. For example:

• $$⟨\text{let } x = v \text{ in } S, \sigma⟩ \rightarrow ⟨S[x \mapsto v], \sigma⟩$$
• $$⟨x := v, \sigma⟩ \rightarrow ⟨\text{skip}, \sigma[x \mapsto v]⟩$$
• $$⟨y =$$

Formal typing judgements and denotational semantics ground the equivalence proofs, relying on precise type information extracted by rust-analyzer.

3. End-to-End Pipeline: Extraction, Translation, and Repair

The REM 2.0 pipeline operationalizes a rust-analyzer-based design as follows:

1. Extraction and borrow-checker repair:
   • The user initiates extract-function via rust-analyzer.
   • The REM repairer invokes cargo check iteratively, generalizing or inserting lifetime parameters and applying lifetime elision until both source ($P$) and refactored ($P′$) programs compile.
   • Outputs are “virtual crates”: isolated Rust workspaces for the original and refactored function.
2. Translation to LLBC via CHARON:
   • CHARON receives MIR (generated via rustc --emit=mir) for both crates.
   • Control-flow is reconstructed as structured AST (loops, conditionals).
   • All ownership and borrow events are made explicit in the LLBC IR.
   • LLBC is serialized for downstream consumption.
3. Functionalization and proof generation via AENEAS:
   • AENEAS transforms LLBC to a pure, heap-threaded λ-calculus in Coq, converting loops to Fixpoints and erasing pointers in favor of explicit value passing.
   • REM 2.0 then emits a Coq lemma asserting equivalence:

   $$\forall a \in A. \; \llbracket f \rrbracket(a) = \llbracket f' \rrbracket(a)$$

• Proofs are discharged automatically; well-founded recursion is required for loop translation.

This pipeline enables both fully automated extraction repairs and optional machine-checked equivalence proofs for a major fragment of Rust programs.

4. Internals: CHARON and AENEAS

CHARON and AENEAS delineate roles within the verification architecture:

Tool	Input	Output	Functionality
CHARON	MIR	LLBC (JSON)	Control-flow structuring, explicit borrows/moves, fully resolved types and trait instances
AENEAS	LLBC	Coq definitions	Functionalization, elimination of pointers, Coq module/lemma synthesis, proof skeletons

CHARON’s MIR interception is achieved through a rustc “driver” that hooks into the compiler pipeline to extract control-flow graphs after borrow checking (Ho et al., 2024). Two forms of IR are constructed:

• ULLBC: An unstructured, precisely-typed representation mirroring MIR’s control-flow graph (CFG)
• LLBC: A structured AST (via loop/if reconstruction), where all Rust semantic primitives—copy, move, borrow—are explicit, and control-flow is well-structured.

Clients like AENEAS operate on the LLBC artifact, extracting function and memory specifications, translating to pure formalisms, and emitting verification conditions suitable for backend solvers (e.g., SMT, Coq). Specs (contracts) may be attached to Rust functions via attributes parsed by CHARON.

5. Proof Obligations and Equivalence Checking

Central to the formal assurance provided by REM 2.0 and its rust-analyzer-based pipeline is the generation and discharge of behavioral equivalence proofs:

• The essential obligation, formulated for functions $f$ and $f′$, is:

$$f \approx f′ \iff \forall a \in A. \; \llbracket f \rrbracket(a) = \llbracket f′ \rrbracket(a)$$

• REM 2.0 emits Coq theorems of the form:

Theorem equivalence_f : forall (x : A), f_orig x = f_extracted x. Proof. reflexivity. Qed.

• CHARON’s MIR→LLBC translation and AENEAS’s functionalλ abstraction are both required to be semantics-preserving for the proof to be meaningful. Errors due to unsupported features or proof failures are reported distinctly, avoiding false positives.

The equivalence lemma directly encodes program equality under operational semantics, providing strong guarantees about the correctness of refactorings (Britton et al., 27 Jan 2026).

6. Empirical Evaluation and Performance

On representative benchmarks, REM 2.0’s rust-analyzer-based design demonstrates both high compatibility and low latency:

Benchmark Type	Size (LOC)	LLBC (fresh/cache)	Coq Conversion	Proof Check	Total Time	Success
EX (trivial)	3–8	270–350ms / 170–240ms	295–335ms	1.2–1.6s	1.7–2.2s	10/10
RW (real-world)	4–44	9–11s / 1.6–1.9s	~1.1s	1.2–1.4s	3.8–4.4s	9/10

• End-to-end verification: 19/20 benchmarks successfully verified (median total time, cached LLBC: EX ≈1.9s; RW ≈4.0s).
• Responsiveness: Daemonized operation allows extract-function refactoring with single-digit millisecond latency.
• Verification bottleneck: Proof checking in Coq (coqc) dominates latency (~1.2s per proof); once LLBC is cached, interactive workflows are feasible.
• Feature handling: Most extractions involving async/await, const fn, non-local control flow, generics, and higher-ranked trait bounds are supported. However, there are explicit limitations: unsupported are nested loops, closures, interior mutability, concurrency, divergent types, and pinning.

This empirical evidence verifies the practicality of rust-analyzer-based designs for interactive, formally assured Rust refactoring (Britton et al., 27 Jan 2026).

7. Impact, Limitations, and Further Directions

Rust-analyzer-based designs, as synthesized by the REM 2.0 + CHARON/AENEAS stack, effect a significant shift by enabling developers to move from interactive code extraction, type-correct repair, and opt-in end-to-end semantic verification, all within mainstream editing environments and for non-trivial Rust codebases (Britton et al., 27 Jan 2026, Ho et al., 2024).

Limitations:

• The verification subset excludes concurrency, closures, interior mutability, and some advanced Rust features.
• LLBC’s verbosity is unwieldy for human inspection though advantageous for mechanized translation.
• A failed verification is robustly distinguished from unsupported-feature errors, reducing the risk of unsound assurances.

Significance:

• By composing a fast syntactic/semantic frontend (rust-analyzer) with backend IRs and proof-producing compilers, these designs bridge practical developer workflows and high-assurance formal methods for a substantial portion of safe Rust.
• The CHARON/AENEAS stack enables the Rust verification community to decouple from compiler-internal instability, and to rapidly build new analysis and transformation tooling atop a stable, well-typed IR.

A plausible implication is that as the LLBC/Coq pipeline matures to support a broader Rust fragment, such rust-analyzer-based designs could become the de facto foundation for both industrial-grade refactoring and end-to-end program verification tools in the Rust ecosystem.