REM2.0: Rust Refactoring & Verification Toolchain

• REM2.0 is an advanced toolchain for Rust that automates extract-function refactoring with integrated formal verification.
• It leverages a persistent rust-analyzer daemon alongside automated borrow-checker repairs and a pipeline with CHARON, AENEAS, and Coq.
• REM2.0 achieves 200× faster refactorings and robust handling of features like async/await, const fn, and generics.

REM2.0 is an advanced toolchain for automated extract-function refactoring and equivalence verification in the Rust programming language. Designed as a ground-up reengineering of the original Rusty Extraction Maestro (REM), REM2.0 introduces a rust-analyzer–based persistent daemon, a novel automated borrow-checker repair mechanism, and an opt-in formal verification pipeline targeting equivalence proofs in Coq via integration with CHARON and AENEAS. This architecture addresses the bottlenecks and coverage limitations of prior compiler-based tools, enabling both high-throughput and verification-rich refactoring of complex Rust codebases (Britton et al., 27 Jan 2026).

1. Toolchain Architecture and Component Overview

REM2.0 comprises several modular components to support seamless, low-latency extract-function refactoring and integrated equivalence checking:

• rem-server: A long-lived JSON-RPC daemon built atop rust-analyzer (RA), exposing methods for Extract-Function, Repair, and Verify.
• VSCode extension: A stateless thin client relaying user commands (e.g., region selection and new function names) to rem-server and applying resulting patches.
• Extraction Engine: Internally constructs a temporary "single-file" RA workspace, leveraging RA’s built-in Extract Function assist and then serializing the transformation as a precise patch.
• REM Repairer: Invoked on the refactored source, performing iterative borrow-checker–guided repairs on lifetime and signature annotations, converging when the code type-checks.
• Verification Pipeline: For supported code fragments, generates “virtual” pre- and post-extraction crates, translates MIR to LLBC via CHARON, LLBC to pure λ-calculus (Coq) via AENEAS, formulates equivalence theorems, and automates proof checking in Coq.

Interaction Sequence:

1. VSCode → rem-server: extractFunction(filePath, selectionRange, newName) (JSON-RPC).
2. rem-server ↔ rust-analyzer: workspace handling, extraction request, and result (function definition and call-site edit).
3. Optional repair: rem-server invokes cargo check via rustc, processes borrow-checker errors, and applies fixes.
4. Optional verification: rem-server generates virtual crates and invokes CHARON, AENEAS, and Coq.
5. Results (patch or verification status) propagate back to VSCode for user inspection.

The persistent daemonization and tight coupling with rust-analyzer yield significant reductions in round-trip latency compared to prior approaches dependent on heavy compiler restarts (Britton et al., 27 Jan 2026).

2. Automated Repair Algorithms and Formal Invariants

REM2.0 consistently produces code that type-checks under Rust’s ownership and lifetime semantics by employing an automated source repair loop guided by borrow-checker error feedback.

High-Level Repair Algorithm:

$$\forall\,x, \tau.\; \mathit{Lifetime}_{\mathrm{param}(x)} \sqsubseteq \mathit{Lifetime}_{\mathrm{arg}(x)}$$4

Key Stages and Formal Properties:

• Ownership Analysis: For each moved value, the repairer decides parameter passing (by value, &T, or &mut T).
• Lifetime Insertion/Refinement: In response to lifetime errors, introduces or strengthens explicit lifetime parameters until the borrow checker is satisfied.
• Lifetime Elision: Applies Rust’s three-rule elision strategy to remove annotation redundancy.

Formal Invariants:

• Ownership:

$$\forall x: T,\; x \text{ used after call} \implies \text{modality} \in \{$$

• Lifetime soundness:

$$\forall\,x, \tau.\; \mathit{Lifetime}_{\mathrm{param}(x)} \sqsubseteq \mathit{Lifetime}_{\mathrm{arg}(x)}$$

• Elision equivalence:

$$\mathit{Elide}\left( \forall 'a.\;\mathrm{fn}\;f( \right) = \mathrm{fn}\;f(T)\to U$$

(when 'a is uniquely determined by elision rules).

These mechanisms ensure no extracted function introduces lifetime or ownership unsoundness, a key requirement for safe refactoring in Rust (Britton et al., 27 Jan 2026).

3. Quantitative Evaluation and Performance Characteristics

REM2.0 delivers order-of-magnitude improvements in latency and greatly expands language coverage relative to compiler-based predecessors.

Metrics:

• Original REM (compiler-based):
  • End-to-end extraction: $T_{\text{orig}} \approx 1000$ ms ($1$ s)
  • Compiler invocation per extraction: $1000$–$3000$ ms
• REM2.0 (daemon-based):
  • Extraction time inside rem-server: $T_{\text{daemon}} \approx 2$–$9$ ms
  • VSCode round-trip (extract + repair): $T_{\text{user}} \approx 120$–$$\forall\,x, \tau.\; \mathit{Lifetime}_{\mathrm{param}(x)} \sqsubseteq \mathit{Lifetime}_{\mathrm{arg}(x)}$$0 ms

Relative Speed-up:

$$\forall\,x, \tau.\; \mathit{Lifetime}_{\mathrm{param}(x)} \sqsubseteq \mathit{Lifetime}_{\mathrm{arg}(x)}$$1

These performance characteristics enable near-instantaneous refactorings in typical interactive editing workflows.

Language Feature Coverage:

REM2.0 handles the majority of feature-focused extractions involving constructs such as async/await, const fn, non-local control flow, generics, and higher-ranked trait bounds. Legacy limitations regarding coverage of macros and certain control-flow primitives have been mitigated through rust-analyzer integration (Britton et al., 27 Jan 2026).

4. Verification Pipeline: CHARON, AENEAS, and Coq Integration

REM2.0’s verification subsystem ensures that extract-function refactorings preserve observable program behavior under formal semantics.

Pipeline Steps:

1. Virtual Crate Generation: Constructs minimal “before” and “after” Cargo projects reflecting the original and refactored code.
2. CHARON: Translates Rust MIR to LLBC (Low-Level Borrow Calculus), making lifetimes, ownership, and trait resolution explicit.
3. AENEAS: Converts LLBC to a pure λ-calculus representation in Coq, eliminating explicit heap and stack dependencies.
4. Equivalence Proof Obligation: Generates a Coq module asserting

$$\forall\,x, \tau.\; \mathit{Lifetime}_{\mathrm{param}(x)} \sqsubseteq \mathit{Lifetime}_{\mathrm{arg}(x)}$$2

and (in whole-program context):

$$\forall\,x, \tau.\; \mathit{Lifetime}_{\mathrm{param}(x)} \sqsubseteq \mathit{Lifetime}_{\mathrm{arg}(x)}$$3

1. Proof Automation: Coq tactics automate the discharge, typically via reflexivity or structural induction (e.g., on loop counters).

Performance:

• Small examples: ~1.8 s end-to-end.
• Real-world mini-benchmarks: ~4.0 s w/ cached LLBC (up to 15 s uncached).

The verification pipeline thus provides machine-checked behavioral preservation for refactorings lying within the representable fragment of CHARON/AENEAS, supporting a practical, formalized refactoring workflow (Britton et al., 27 Jan 2026).

5. Comparative Evaluation and Compatibility

REM2.0 is evaluated across three benchmark suites: the original REM artefact, a set of 40 feature-rich extractions from high-profile GitHub repositories, and twenty verification benchmarks.

Comparison Table:

Feature	Original REM (rustc)	REM2.0 (rust-analyzer)
Integration	IntelliJ plugin / rustc internals	JSON-RPC daemon / VSCode extension
Language Coverage	Core Rust; limited async/generics	Async/await, const fn, HRTBs, std::ops::ControlFlow
Lifetime Repair	Cargo check + borrow-oracle loop	Decoupled repair, optional inline
Performance	1000–3000 ms per extraction	2–9 ms extraction, 120–260 ms editor RT
Verification	None	Optional CHARON/AENEAS→Coq pipeline
Compatibility	Fragile wrt. rustc versions	Robust, editor-agnostic

This comparative assessment demonstrates that REM2.0 not only preserves compatibility and repair robustness but also achieves a dramatic speedup and greater Rust language feature support.

6. Significance and Future Implications

REM2.0 establishes a new standard for IDE-integrated, correctness-preserving automated refactoring in Rust. Its persistent service-based design, advanced lifetime repair, and opt-in formal verification pipeline collectively transform extract-method refactoring from a fragile, compiler-coupled research prototype to a practical, editor-agnostic toolchain. The architecture’s decoupling from rustc internals enhances cross-version robustness and fosters future extensibility. A plausible implication is that REM2.0’s methodology could be generalized to other safe systems languages with nontrivial ownership and effect typing disciplines, given suitable analysis pipelines and formal artifacts (Britton et al., 27 Jan 2026).