ReMeX: Rust Refactoring & Verification Toolchain

• ReMeX is a Rust extract-function refactoring toolchain that uses rust-analyzer integration to perform compiler-guided repair for lifetimes and signatures.
• It combines a persistent daemon with a VSCode extension to manage extraction, repair, and an optional equivalence-verification pipeline producing Coq proofs.
• The system achieves rapid extraction (2–9 ms) and robust verification, effectively handling complexities from async, generics, and non-local control flow in Rust.

Searching arXiv for the specified paper and closely related REM/verification context. arXiv Search Query: (Britton et al., 27 Jan 2026) REM Rust equivalence refactoring CHARON AENEAS ReMeX, in the sense most closely associated with Rust refactoring and equivalence checking, denotes the expanded REM2.0 toolchain: an end-to-end approach that combines fast, rust-analyzer–based extract-function refactoring with automated lifetime/signature repair and an opt-in equivalence-verification pipeline that produces machine-checked Coq proofs via CHARON and AENEAS. The term itself does not appear in the underlying paper; the authors consistently refer to REM2.0, rem-server, the REM Repairer, and the optional verification pipeline. ReMeX is therefore best understood not as a separate verification component or a different algorithm, but as an external shorthand for the re-engineered and extended successor to the original Rusty Extraction Maestro (REM) artefact (Britton et al., 27 Jan 2026).

1. Definition and scope

In this usage, ReMeX refers to a practical extract-function refactoring system for Rust that preserves REM’s unique compiler-guided lifetime-repair loop while replacing the original compiler-centric architecture with a persistent rust-analyzer–based design. Its scope is narrower than arbitrary semantics-preserving transformation: it is centered on extract-function refactoring, signature and lifetime repair, and optional proof-producing equivalence checking for a supported safe-Rust subset. This combination is the defining characteristic of the system (Britton et al., 27 Jan 2026).

The central motivation is that extract-function refactoring in Rust is difficult for reasons that are specific to the language. Extracting a fragment changes where values are owned, how and when they are borrowed, and which scopes govern the lifetimes of references. Even small moves can trigger borrow-checker rejections, alter permitted aliasing and mutation, or force explicit lifetime parameters that did not appear in the original code. Modern Rust features further complicate the transformation boundary: async/await, const fn, non-local control flow, generics with trait bounds, dynamic trait objects, and higher-ranked trait bounds all interact with extraction.

The toolchain is therefore positioned against three limitations of earlier approaches. Earlier pipelines invoked cargo check repeatedly and relied on unstable rustc internals, which made latency high and maintenance brittle. Other tools handled only restricted fragments of Rust. Most importantly, prior systems usually treated successful compilation as the end of the assurance story, whereas REM2.0 adds an optional machine-checked equivalence layer.

2. Refactoring problem setting in Rust

The technical difficulty addressed by ReMeX is not merely syntactic extraction. In Rust, extraction changes program obligations seen by the borrow checker. References must not outlive data, mutable borrows must remain disjoint from overlapping immutable borrows, and extraction boundaries can expose missing lifetime parameters or insufficient trait bounds. The resulting problem is therefore one of ownership-preserving and borrow-preserving transformation, rather than simple code motion (Britton et al., 27 Jan 2026).

Several feature classes are especially relevant. Async/await is compiled into state machines with suspension points, so extraction must preserve lifetimes across awaits and keep the state machine well formed. Non-local control flow requires return, break, and continue inside the selected region to be reified across a function boundary. Const contexts require const evaluability to survive extraction. Generics and HRTBs require propagation or explicit recovery of generic parameters, trait bounds, and lifetime binders. Dynamic trait object heavy patterns and complex bounds form a recurrent failure mode.

A representative case is inline mutation of a vector. A naive extraction that passes the vector by value moves ownership and breaks later uses. The repaired outcome instead passes &mut Vec<i32>, preserving mutation-in-place and subsequent uses. The paper presents the same issue for async code: the extracted function remains async where needed, keeps the Result-typed boundary, and relies on repair when lifetimes around await points become too restrictive.

3. Toolchain architecture and workflows

The toolchain is organized as a persistent daemon plus editor integration. A VSCode extension acts as a thin UI client, serializing extraction requests over JSON-RPC, applying edits to the buffer, and surfacing verification outcomes. The daemon, rem-server, maintains a persistent rust-analyzer analysis context and orchestrates extraction, repair, and verification (Britton et al., 27 Jan 2026).

The core components can be summarized as follows:

Component	Role
VSCode extension	Sends extraction requests, applies edits, displays verification results
Extraction engine	Invokes rust-analyzer’s Extract Function assist in a single-file workspace
REM Repairer	Iteratively adjusts parameters, lifetimes, and bounds using compiler diagnostics
Verification pipeline	Builds virtual crates, runs CHARON and AENEAS, checks Coq equivalence theorem

The extraction engine works atop rust-analyzer in a single-file workspace while merging in a persistent std/core workspace so standard types such as Vec<T> and Option<T> remain fully inferred. The engine returns a structured edit consisting of a new function with inferred generics, lifetimes, and where-clauses, plus a rewritten call site. The repairer then post-processes that extraction when cargo check exposes borrow or signature problems.

The verification workflow is opt-in and deliberately isolated. REM2.0 snapshots both original and refactored versions into minimal virtual crates, translates each crate’s MIR to LLBC with CHARON, translates LLBC to pure functional Coq with AENEAS, generates an EquivCheck.v module, and invokes coqc. Success is reported separately from unsupported-feature diagnostics and ordinary verification failure.

4. Repair strategy and formal equivalence

The REM Repairer preserves the original REM’s compiler-guided repair loop. After naive hoisting, it decides per captured variable whether to pass by value, by &T, or by &mut T, guided by compiler diagnostics and while avoiding clones unless necessary. When inference fails, it introduces explicit lifetimes such as 'a and 'b, propagates them across inputs and outputs, refines relationships until borrow-checker constraints are met, and then applies lifetime elision where permissible (Britton et al., 27 Jan 2026).

The same strategy extends to advanced language features. For non-local control flow, extraction reifies return, break, and continue via std::ops::ControlFlow at the call boundary, after which the caller reconstructs the original behavior by pattern matching. For async/await, the extracted function remains async where needed, and lifetimes are not widened across await points. For const contexts, const qualifiers are propagated where applicable. For generics and HRTBs, the extractor copies generic parameters and trait bounds, while the repairer explicitly captures lifetimes when inference is insufficient.

The formal equivalence obligation is stated in simplified functional form as

$$\forall x \in \mathrm{Dom}(f).\; \llbracket f \rrbracket(x) = \llbracket f' \rrbracket(x).$$

This expresses that, for all inputs, the semantic interpretations of the original function $f$ and its refactored counterpart $f'$ coincide. The paper emphasizes that this simplified obligation is retained because the AENEAS translation targets pure functional semantics, the setting is safe Rust, and REM2.0 ensures that the extracted fragment is well typed and borrow checked.

The verification subset is explicitly limited. Supported cases include safe Rust, structured control flow, traits, many generic functions without nested borrows in type parameters, and loops subject to remaining restrictions. Unsupported or limited cases include unsafe Rust, closures and function pointers, nested borrows in signatures, interior mutability, concurrency, and some dynamic trait object or macro-heavy patterns. Practical failure can also arise at Coq termination checking even when the Rust loop terminates.

5. Evaluation, assurance, and failure modes

The evaluation covers three benchmark families: the original REM artefact, a feature-focused corpus drawn from 20 highly starred GitHub repositories, and verification benchmarks. On the original REM artefact, 40 cases were considered, with 39 usable because one had no selection. REM2.0 achieved 100% compatibility on the usable cases. Relative to the earlier REM prototype, latency dropped from around 1000 ms per extraction to low single-digit milliseconds in the daemon, typically 2–9 ms. On the feature corpus, 33/40 extractions compiled successfully; most async/await, const fn, non-local control flow, generics, and HRTB examples succeeded, while failures clustered around dynamic trait objects and complex generic bounds. On twenty verification benchmarks, the CHARON/AENEAS pipeline constructed end-to-end equivalence proofs for cases within its current subset (Britton et al., 27 Jan 2026).

Verification cost is substantially higher than extraction cost. Trivial or targeted verification cases completed in around 1.7–2.2 s per check, with most time in Coq checking. Real-world supported cases succeeded in about 3.8–4.4 s with cached intermediates. Fresh LLBC translation could take 9–15 s, dropping to 1.6–1.9 s with cache reuse, while Coq conversion and checking took around 1.0–1.4 s each. Negative tests consisting of hand-modified, type-correct but behavior-changing refactorings were rejected by the Coq equivalence theorem.

The assurance model is deliberately conditional. When verification applies and succeeds, users receive machine-checked assurance under pure functional semantics for safe, sequential Rust fragments. When verification is not applicable, the system emits unsupported-feature diagnostics. When proof search fails, failure is surfaced distinctly from unsupported-feature errors, and the design preference is to fail conspicuously rather than risk false positives. The extraction and repair loop itself remains compiler guided; machine-checked behavior preservation is obtained only when verification is enabled and succeeds.

Threats to validity are also explicit. Timing depends on OS and caching. Benchmark selection centered on popular GitHub projects. Correctness was judged by compilation and, when enabled, equivalence proofs; non-functional differences such as logging, performance, and concurrency are not modeled. Planned extensions include deeper rust-analyzer integration, broader verification support as CHARON and AENEAS evolve, smarter repair strategies, and borrow-repair patterns for harder cases.

6. Nomenclature, misconceptions, and disambiguation

A recurrent misconception is to treat ReMeX as the name of a standalone verifier. In the Rust refactoring context, that interpretation is inaccurate. The term does not appear in the paper, and the closest accurate interpretation is the expanded REM2.0 toolchain as a whole: fast extraction, repair, and optional equivalence verification. It is neither a separate component nor a different algorithm from REM2.0 (Britton et al., 27 Jan 2026).

The label is also ambiguous across the literature. In referring expression comprehension, ReMeX names a relation-aware, multi-entity REC benchmark with 16,530 images, 23,402 entity bounding boxes, and 6,645 directed relations, introduced alongside ReMeREC (Hu et al., 22 Jul 2025). In data storytelling, Remex denotes a JupyterLab-based tool that suggests and applies meta relations between findings (Li et al., 7 Jan 2025). Some papers explicitly note that “ReMeX” is not their official term and instead refers to methods named ReMix or REMO; examples include the generalized person re-identification method ReMix (Mamedov et al., 2024) and the prompt-optimization framework REMO (Wu et al., 26 Aug 2025).

This terminological dispersion suggests that “ReMeX” is better treated as a context-dependent label than as a stable technical name. In Rust refactoring and equivalence checking, its most precise encyclopedia definition is therefore the one attached to REM2.0: a rust-analyzer–based extract-function refactoring toolchain with automated lifetime/signature repair and an opt-in CHARON/AENEAS-to-Coq equivalence pipeline.