A Lightweight Formalism for Reference Lifetimes and Borrowing in Rust

Abstract

Rust is a relatively new programming language that has gained significant traction since its v1.0 release in 2015. Rust aims to be a systems language that competes with C/C++. A claimed advantage of Rust is a strong focus on memory safety without garbage collection. This is primarily achieved through two concepts, namely, reference lifetimes and borrowing . Both of these are well-known ideas stemming from the literature on region-based memory management and linearity / uniqueness . Rust brings both of these ideas together to form a coherent programming model. Furthermore, Rust has a strong focus on stack-allocated data and, like C/C++ but unlike Java, permits references to local variables. Type checking in Rust can be viewed as a two-phase process: First, a traditional type checker operates in a flow-insensitive fashion; second, a borrow checker enforces an ownership invariant using a flow-sensitive analysis. In this article, we present a lightweight formalism that captures these two phases using a flow-sensitive type system that enforces “ type and borrow safety .” In particular, programs that are type and borrow safe will not attempt to dereference dangling pointers. Our calculus core captures many aspects of Rust, including copy- and move-semantics, mutable borrowing, reborrowing, partial moves, and lifetimes. In particular, it remains sufficiently lightweight to be easily digested and understood and, we argue, still captures the salient aspects of reference lifetimes and borrowing. Furthermore, extensions to the core can easily add more complex features (e.g., control-flow, tuples, method invocation). We provide a soundness proof to verify our key claims of the calculus. We also provide a reference implementation in Java with which we have model checked our calculus using over 500B input programs. We have also fuzz tested the Rust compiler using our calculus against 2B programs and, to date, found one confirmed compiler bug and several other possible issues.

Verus: Verifying Rust Programs using Linear Ghost Types (extended version)

“…The goal of this lambda calculus is to serve as a model to demonstrate particular features and their type safety. We do not attempt to capture all of the semantics of Rust and Verus, since formalizing Rust semantics is by itself a large and challenging problem [Jung et al 2018a;Pearce 2021;Weiss et al 2019]. Instead, we focus on a small set of topics that are novel to Verus and are particularly relevant for type safety:…”

“…Third, our lambda calculus is a mostly-functional language that manipulates values, rather than an imperative language that mutates values stored in locations. (This contrasts with more detailed formalizations of Rust centered on locations [Pearce 2021;Weiss et al 2019].) The model language does, however, include two forms of mutation.…”

Linearity and Uniqueness: An Entente Cordiale

“…Ownership was first developed as a framework for understanding aliasing in object-oriented languages [34], and is intended to give a high-level structural view of objects and references in much the same way that powerful type systems give a high-level structural view of data. Ownership is now most familiar due to being pervasive in the Rust programming language, for which multiple formalisations have been attempted; RustBelt [24] gives a lower-level encoding of Rust intended for formal verification while Oxide [64] is a higher-level encoding designed for more theoretical work, among others [39]. Extending these ideas to other languages is an active area of research; RefinedC [44] is one example.…”

Rusty Links in Local Chains

“…Rust [23,19,24] is well-known as a language that combines control of memory use, safe concurrency, and excellent compiler error messages. Rust achieves this balance thanks to a version of ownership types [13,32,12] (also known in the literature as "ownership types" [22,28]) which statically track the lifetime (or owner) of each allocated object; when an object goes out of scope, all the memory owned by that object is deallocated. So far, so C++ [31], but Rust's ownership types ensure that programs remain memory safe, so really not C++.…”