Beyond $k$-Limiting: Pointer-Flow-Guided Context Sensitivity for Scalable and Precise Rust Pointer Analysis

Rust’s heap encapsulation naturally leads to layered heap construction and access.

Rust’s slice abstraction exemplifies a layered memory-access mechanism that upholds borrowing and lifetime rules. Rust provides a unified abstraction for contiguous memory through its Dynamically Sized Types (DSTs), most notably slices ([T]) and string slices (str) for UTF-8 text. A slice is a safe view of any contiguous region of memory – heap, stack, or static – and is internally represented by a fat pointer containing a data pointer and metadata (e.g., length). Slice references such as &[T] and &str therefore offer lightweight, zero-cost access to contiguous data without copying or reallocating it.

Slices serve as Rust’s canonical abstraction for contiguous memory. The standard library implements most contiguous-data operations – indexing, iteration, splitting, searching, and pattern matching – directly on slices. High-level containers expose their underlying memory as slice references (e.g., &[T] for Vec<T> and &str for String), inheriting this functionality rather than reimplementing it. This design centralizes memory access in one abstraction and ensures that safe operations on contiguous data follow consistent slice-based semantics.

Containers provide methods that return slice references explicitly, such as as_slice(), as_mut_slice(), and as_str(), yielding &[T], &mut [T], or &str, respectively. In idiomatic Rust, however, slice references are more often obtained implicitly through the Deref and DerefMut traits: taking a reference to a container automatically coerces it into the appropriate slice reference. In both cases, the conversion requires a layered reconstruction of the slice’s fat pointer from the container’s internal raw pointer and associated metadata.

Figure 4 illustrates Rust’s use of slices. Consider the foo() ($f_9$) and bar() ($f_{10}$) functions, where g and v own the heap-allocated objects o3 and o4. Because str::is_ascii() and slice::get() expect &str and &[T], the compiler automatically performs a deref coercion: taking &g and &v, invoking their deref() implementations, and producing &str and &[u8]. These implicit deref() calls are inserted at lines 3 and 8, respectively.

The conversion to a slice at line 8 calls Vec::deref() (line 21), which invokes Vec::as_slice() (line 24). This retrieves the raw pointer via as_ptr() and reconstructs a slice reference using slice::from_raw_parts() (line 26). The pointer obtained at line 25 traverses several internal layers for runtime safety checks before forming the final fat pointer that combines the data pointer and length. The conversion at line 3 follows a similar pattern. String::deref() (line 17) obtains a &[u8] slice from the string’s internal Vec<u8> buffer by calling g.vec.as_slice() (line 18), implemented by Vec::as_slice(). It then reinterprets this slice as a &str at line 19.

As shown in the call graph for this example, slice conversions introduce their own deep call chains in addition to those from layered heap access via as_ptr(). In our example, dereferencing Vec<u8> into &[u8] at line 8 involves five calls: $f_{10}$ $\stackrel{l_8}{\to }$ $f_{13}$ $\stackrel{l_{22}}{\to }$ $f_{14}$ $\stackrel{l_{26}}{\to }$ $f_{21}$ $\stackrel{l_{55}}{\to }$ $f_{22}$ $\stackrel{l_{59}}{\to }$ $f_{23}$. Similarly, dereferencing String into &str at line 3 also follows a five-call chain: $f_9$ $\stackrel{l_3}{\to }$ $f_{12}$ $\stackrel{l_{18}}{\to }$ $f_{14}$ $\stackrel{l_{26}}{\to }$ $f_{21}$ $\stackrel{l_{55}}{\to }$ $f_{22}$ $\stackrel{l_{59}}{\to }$ $f_{23}$.

Rust’s centralized slice operations apply uniformly to all contiguous memory regions – heap, stack, and static – further exacerbating points-to conflation beyond heap objects alone. In baz() (line 12), the reference &a points to the stack-allocated array o5. The indexing expression &a[0..5] is compiled into the array-specific array::index() (line 15), which delegates to slice-indexing utilities: it performs raw-pointer arithmetic and constructs the resulting slice’s fat pointer via ptr::slice_from_raw_parts(). A similar indexing path is used by slice::get() (line 10) when slicing a Vec<u8>. Both array::index() and slice::get() ultimately rely on the same SliceIndex<[u8]>::get_unchecked() implementation and converge on ptr::slice_from_raw_parts() to build the subslice’s fat pointer.

Based on the call graph shown in Figure 4, we see that when , the context-sensitive analysis fails to separate the three memory objects o3, o4, and o5, leading to conflated points-to information. This conflation propagates to g_slc, v_slc, the return value of slice::get(), and the return value of array::index().

Trait-driven operations introduce additional abstraction layers beyond raw pointer manipulation. Rust’s abstraction model is fundamentally trait-oriented: shared behaviors are defined once and reused across many types without relying on inheritance or dynamic dispatch. Traits provide static, compositional interfaces that the compiler aggressively specializes via monomorphization, enabling zero-cost reuse of shared logic across different types.

Leveraging this architecture, the Rust standard library implements many high-level operations as sequences of delegated trait calls. A method defined on a container forwards to a trait implementation, which may in turn invoke helper traits that encode reusable semantics, forming layered chains of trait-driven computation.

The same example in Figure 4 also illustrates how trait-driven operations introduce their own layered call chains. Slices provide the implementation of the Index trait for range-based indexing. The Index trait defines the public interface for indexing and delegates the actual slicing logic to the subslicing machinery. For the operator &a[0..5] (line 15) in baz() ($f_{11}$), the compiler constructs a Range object (line 14) and routes the array and range through the array’s Index implementation ($f_{16}$). The array reference is coerced into a slice reference so that slice-based indexing can be applied. Specifically, Index<Range>::index() ($f_{17}$) forwards the operation to the helper trait SliceIndex via SliceIndex<[u8]>::index() ($f_{19}$), which centralizes range-based indexing across slice-backed types. The final subslice is produced by SliceIndex<[u8]>::get_unchecked() ($f_{20}$).

As shown in the call graph, this delegation passes through four intermediate layers ($l_{15}\to l_{33}\to l_{36}\to l_{44}$), starting at $f_{11}$ and ending at $f_{20}$, before reaching ptr::slice_from_raw_parts() ($f_{22}$) at line 48 ($l_{48}$) for subslice construction.

Such layering is not unique to slice operations; many core Rust APIs follow the same trait-driven delegation. For instance, (1) the Iterator API uses an adaptor pattern in which each adaptor (e.g., Enumerate, Zip, Flatten, Rev) wraps the previous iterator, forming a nested chain of adaptor layers. Any call to next(), next_back(), or nth() must traverse this entire stack, triggering a cascade of trait-method dispatches. (2) Error propagation also proceeds through a sequence of trait calls rather than a language-level exception mechanism: the Try trait separates success from failure, and the FromResidual trait adapts the error type before early return, introducing at least two layers of calls.

These high-level layers frequently converge on shared low-level implementations, further amplifying the conflation effects already introduced by Rust’s heap abstractions and slice-centric memory model.

Rust’s multi-layered pointer operations form chains of functions that take pointers as input and produce new pointers, propagating information across abstraction levels. At the lower layers of these chains are routines such as Unique::new_unchecked() and NonNull::new_unchecked() (see Figure 3), which directly wrap raw pointers. Because many higher-level abstractions eventually call these routines to initialize or reconstruct internal pointers, they become convergence points for diverse pointer flows. Such functions must therefore be analyzed under distinct contexts to avoid conflating unrelated points-to sets; a context-insensitive treatment would merge flows arriving along different call paths.

In this paper, we identify a function as precision-critical if its return value depends on pointer flows originating from its parameters, as determined by a lightweight interprocedural pointer-flow pre-analysis. Such functions require context sensitivity to avoid merging unrelated pointer flows arriving along different call paths. Concretely, Rceus classifies a function as precision-critical when its return value depends on one of its parameters through either (1) intraprocedural flows or (2) interprocedural flows.

In Figure 3, functions $f_3$ (ManuallyDrop::new()) and $f_8$ (NonNull::new_unchecked()) illustrate the first case, with return values derived directly from their parameters. By contrast, all other functions (except $f_0$, main()) fall into the second case, where parameter-derived pointer information propagates through one or more callees before contributing to the function’s return.

This pointer-flow-based strategy identifies precision-critical functions approximately but effectively. Although it may misclassify a function in either direction in theory, in practice applying $k$-limited context sensitivity only to these functions achieves precision nearly identical to uniform $k$-limiting while substantially reducing computational cost (as validated in our evaluation), demonstrating the practical accuracy of the classification.

Rust’s deeply layered abstractions make traditional $k$-limited context-sensitive pointer analyses ineffective: small $k$ values fail to preserve the calling structure needed to separate distinct pointer flows, whereas increasing $k$ quickly becomes prohibitively expensive. To address this, Rceus preserves only the flow-entry callsites – one per context – that distinguish how parameter-derived pointer flows reach each precision-critical function, providing the necessary separation while keeping the analysis both scalable and precise.

In Rust’s layered abstractions, pointer flows descend from higher-level precision-critical functions into lower-level ones and eventually return upward through nested abstraction layers. The first callsite where a pointer enters a precision-critical function provides the only context that distinguishes flows reaching the same callee from different callers. Once a pointer has propagated into deeper layers, downstream callsites no longer encode its origin and thus are ineffective as context boundaries for separating flows from different call paths.

Motivated by this observation, we define a flow-entry callsite as a callsite where a pointer first enters an upper-layer precision-critical function. For each function transitively reached downstream along this pointer flow, we preserve the corresponding flow-entry callsite as its context with respect to that precision-critical function. Propagating this flow-entry callsite along the entire call chain consistently encodes the pointer’s origin, keeping flows from different callers distinguishable even deep within lower-layer routines.

In Figure 3, $f_1$ (into_vec()) is the topmost precision-critical function. Two pointer flows, originating from b1 and b2, enter it at callsites $l_3$ and $l_8$ in $f_0$ (main()), respectively. Each flow then descends to $f_3$ along $l_{14}\to l_{19}$, binds the returned value to ptr, and continues through $f_4$ – $f_8$ along $l_{15}\to l_{26}\to l_{29}\to l_{32}\to l_{35}$ before returning upward. These two flows ultimately reach v1 and v2 separately, making $l_3$ and $l_8$ the flow-entry callsites for the two distinct pointer flows. Figure 5 shows the context-sensitive call graph generated by Rceus, where each context is written as $[\mathrm{\dots }]$. Call chains rooted at $l_3$ are annotated with context $[l_3]$, and those rooted at $l_8$ with context $[l_8]$. By preserving these flow-entry callsites, Rceus keeps the two pointer-propagation paths separated throughout the analysis, preventing conflation of the points-to information for v1 and v2.

Similarly, in Figure 4, $f_{12}$ (String::deref()), $f_{13}$ (Vec::deref()), $f_{15}$ (slice::get()), and $f_{16}$ (array::index()) serve as the topmost precision-critical functions. Their callsites $l_3$, $l_8$, $l_{10}$, and $l_{15}$ are therefore identified as the flow-entry callsites. As shown in Figure 6, the context-sensitive call graph produced by Rceus preserves these entry contexts, allowing the analysis to cleanly separate pointers to both heap-allocated and stack-allocated objects.

We build an over-approximate call graph using Rapid Type Analysis (RTA) [1], adapted to Rust following [18]. RTA is a fast whole-program technique that resolves potential calls from the set of types instantiated in reachable code [1, 39, 46, 33]. The Rust-adapted variant further supports static dispatch, trait-object dispatch, trait upcasting, and function-pointer calls [18]. The resulting call graph $G_c=(F_c,E_c)$ forms the basis of our analysis, where $F_c$ is the set of RTA-reachable functions and $E_c\subseteq F_c\times F_c\times 𝕃$ contains edges $f\stackrel{\ell }{\to }g$ for calls at callsites $\mathrm{\ell }\in 𝕃$, with $f,g\in F_c$, and $𝕃$ denoting the set of all program locations.

Given the RTA call graph $G_c=(F_c,E_c)$, we trace interprocedural pointer flows for each function $f\in F_c$ by constructing a pointer-flow graph $G_f=(V_f,E_f)$, where $V_f$ contains the local variables of $f$ and $E_f$ represents flows induced by assignments, dereferences, address-of expressions, loads/stores, and calls in $f$. This tracing need not be sound: missing flows merely cause some functions to be treated context-insensitively by Rceus, reducing precision but not the soundness of the main analysis. The goal is simply to capture the essential flows needed to identify precision-critical functions for context-sensitive treatment.

For $u,v\in V_f$, where $f$ is an arbitrary function, we write $\pi :u{\rightsquigarrow }_{G_f}v$ for a program path in $G_f$, and $\mathrm{𝑙𝑎𝑏𝑒𝑙𝑠}(\pi )$ for its set of edge labels. All intraprocedural edges are labeled $ϵ$, while interprocedural edges are labeled with their callsites. Finally, let ${\mathrm{𝑝𝑎𝑟𝑎𝑚}}_f^i$ denote the $i$-th parameter of $f$, and ${\mathrm{𝑟𝑒𝑡}}_f$ its return variable.

Figure 9 summarizes the rules used to extract coarse-grained interprocedural pointer flows in Rust. The first six rules capture intraprocedural flows by modeling assignments derived from the MIR syntax in Figure 8, where each place $p$ is instantiated as $v.j$ (a local variable $v$ with an optional projection $j$). The final rule models interprocedural flow by propagating pointer information across call statements.

Let us first examine how Rceus traces intraprocedural flows. The [P-AddrOf] rule models the creation of references or raw pointers (). References (e.g., let x = &y) are fundamental to safe memory access, whereas raw pointers arise through coercions (e.g., &v as *const _) or explicit syntax (e.g., &raw const v) and are common in unsafe code. [P-Assign] captures assignments $v_1.j_1=v_2.j_2$, covering ownership moves, reference copies, and raw-pointer duplication. In MIR, array and struct copies are element-wise; therefore, we add a flow from $v_2$ to $v_1$ whenever the assigned value is a pointer or contains pointer fields. [P-Cast] handles pointer casts ($v_1.j_1=v_2.j_2\mathrm{𝑎𝑠}\tau$), frequently used in libraries and low-level code manipulating raw pointers. [P-Gep] models field access through a dereferenced pointer (), common in struct and container access. [P-Load] captures projection-based loads ($v_1.j_1=(\ast v_2).j_2$), typical when reading heap fields through references. Conversely, [P-Store] models field updates ($(\ast v_1).j_1=v_2.j_2$), where a value is written into a field reachable from a pointer – a pattern frequent in low-level libraries.

Finally, [P-Call] lifts these flows across function boundaries. It models interprocedural propagation between call arguments and the value assigned at a callsite. For a callsite $\mathrm{\ell }:v_0=g(v_1,\mathrm{\dots },v_r)$ in function $f$ with a call-graph edge $f\stackrel{\ell }{\to }g\in E_c$, if, in $g$, the parameter ${\mathrm{𝑝𝑎𝑟𝑎𝑚}}_g^i$ can reach its return value (i.e., ${\mathrm{𝑝𝑎𝑟𝑎𝑚}}_g^i{\rightsquigarrow }_{G_g}{\mathrm{𝑟𝑒𝑡}}_g$), then we add an interprocedural edge $v_i\stackrel{\ell }{\to }{v}_0$ to $G_f$, indicating that argument $v_i$ contributes to the callsite’s assigned value.

Given each function’s pointer-flow graph $G_f=(V_f,E_f)$, Rceus computes the set $\mathrm{𝐶𝑟𝑖𝑡𝐹𝑢𝑛𝑐𝑠}$ of precision-critical functions – those whose return values depend on pointer flows originating from their parameters. This dependency is encoded directly in $G_f$: if any parameter can reach the return variable along a pointer-flow path, $f$ is classified as precision-critical.

As formalized in Figure 10, the [C-Intra] and [C-Inter] rules classify functions based on whether the parameter-to-return dependence is purely intraprocedural or arises through interprocedural flows. A function $f$ is added to $\mathrm{𝐶𝑟𝑖𝑡𝐹𝑢𝑛𝑐𝑠}$ whenever there exists a path $\pi :{\mathrm{𝑝𝑎𝑟𝑎𝑚}}_f^i{\rightsquigarrow }_{G_f}{\mathrm{𝑟𝑒𝑡}}_f$. If $\mathrm{𝑙𝑎𝑏𝑒𝑙𝑠}(\pi )=\{ϵ\}$, we record $ϵ\Rightarrow f$, indicating an intraprocedural dependence. If $\pi$ traverses any callsite $l$ (i.e., $l\in \mathrm{𝑙𝑎𝑏𝑒𝑙𝑠}(\pi )$), we record $l\Rightarrow f$, indicating that the parameter flows to the return value via an interprocedural call.

A function may therefore receive multiple such annotations, reflecting distinct flow paths through which its parameters may influence its return value.

In Figure 3, all functions except main() are precision-critical. For example, into_vec() is classified as such because its parameter flows to its return value interprocedurally via ${\mathrm{\ell }}_{14}\Rightarrow \text{into\_vec()}$ and ${\mathrm{\ell }}_{15}\Rightarrow \text{into\_vec()}$. In Figure 4, all except foo(), bar(), baz(), and is_ascii() are precision-critical. In particular, String::deref() is precision-critical due to the interprocedural parameter-to-return flow across ${\mathrm{\ell }}_{18}\Rightarrow$String::deref().

In context-sensitive pointer analysis, the MIR assignment forms in Figure 8 are abstracted through the eight pointer-flow rules shown in Figure 11. Each allocation site $\mathrm{\ell }\in 𝕃$ introduces a fresh abstract object $o_{\mathrm{\ell }}\in 𝕆$, with type $\tau$ written as $o_{\mathrm{\ell }}:\tau$ when needed, where $𝕆$ denotes the set of pointed-to memory locations. Calling contexts $c$ range over either the empty context $[]$ or a singleton $[\mathrm{\ell }]$ containing exactly one callsite.

The following auxiliary functions are used in these rules:

• $\mathrm{■}$

  $\mathrm{𝑝𝑡}(c,p)$ – the context-sensitive points-to set of pointer $p$ under context $c$.

• $\mathrm{■}$

  $\mathrm{𝑐𝑡𝑥}(f)$ – the set of contexts under which function $f$ is analyzed.

• $\mathrm{■}$

  $\mathrm{𝑝𝑡𝑟}\mathrm{\_}\mathrm{𝑝𝑟𝑜𝑗}(p)$ – the set of pointer-typed projections of place $p$ (e.g., struct fields, tuple components, slice elements), including $ϵ$ for no projection.

• $\mathrm{■}$

  $\mathrm{𝑑𝑒𝑟𝑒𝑓}\mathrm{\_}\mathrm{𝑡𝑦}(\tau )$ – the dereferenced type of a pointer type $\tau$.

• $\mathrm{■}$

  $\mathrm{𝑡𝑟𝑎𝑛𝑠𝑚𝑢𝑡𝑒}(c,o,\tau )$ – the $\tau$-specific variant of object $o$ under context $c$.

• $\mathrm{■}$

  $\mathrm{𝑑𝑖𝑠𝑝𝑎𝑡𝑐ℎ}(c,f^{\prime },p)$ – the set of call targets resolved for a call to $f^{\prime }$ under context $c$.

• $\mathrm{■}$

  $\mathrm{𝑟𝑐𝑒𝑢𝑠}\mathrm{\_}\mathrm{𝑐𝑡𝑥}$$(f,c,\mathrm{\ell },g)$ – the context for callee $g$ at callsite $\mathrm{\ell }$ in $f$ under context $c$.

The eight inference rules in Figure 11 for analyzing a function $f$ follow the standard formulation [19, 18]; Rceus is distinguished by how it computes calling contexts. [AllocHeap] introduces a fresh object $o_{\mathrm{\ell }}$ for each allocation. [Assign] propagates points-to sets from $p_2$ to $p_1$, and [Addrof] records that $p_1$ points to $p_2$. [Gep] computes field addresses, [Load] reads field contents, and [Store] writes them. [Cast] performs type reinterpretation by creating type-specific variants of objects. Finally, [Call] resolves callees at callsite $\mathrm{\ell }$ under context $c\in \mathrm{𝑐𝑡𝑥}(f)$ via $\mathrm{𝑑𝑖𝑠𝑝𝑎𝑡𝑐ℎ}$, constructs for each callee $g$ a new context $c^{\prime }=\mathrm{𝑟𝑐𝑒𝑢𝑠}\mathrm{\_}\mathrm{𝑐𝑡𝑥}(f,c,\mathrm{\ell },g)$ that preserves only the appropriate flow-entry callsite, transfers arguments to formals, and propagates return values back to the caller, thereby enabling the analysis of $g$ under context $c^{\prime }$. Below we define $\mathrm{𝑟𝑐𝑒𝑢𝑠}\mathrm{\_}\mathrm{𝑐𝑡𝑥}$, which determines the callee’s context.

The auxiliary function $\mathrm{𝑟𝑐𝑒𝑢𝑠}\mathrm{\_}\mathrm{𝑐𝑡𝑥}(f,c,\mathrm{\ell },g)$, central to Rceus, computes the context used to analyze a callee $g$ invoked at callsite $\mathrm{\ell }$ in caller $f$ under caller context $c$:

where the three cases are evaluated sequentially, following an if–elseif–else structure:

• $\mathrm{■}$

  Case 1. $c^{\prime }=[]$: $g$ is not precision-critical (i.e., $\mathrm{\_}\Rightarrow g\notin \mathrm{𝐶𝑟𝑖𝑡𝐹𝑢𝑛𝑐𝑠}$) and is therefore analyzed context-insensitively (i.e., under the empty context $[]$).

• $\mathrm{■}$

  Case 2. $c^{\prime }=[\mathrm{\ell }]$: $g$ is precision-critical (i.e., $\mathrm{\_}\Rightarrow g\in \mathrm{𝐶𝑟𝑖𝑡𝐹𝑢𝑛𝑐𝑠}$), but the callsite $\mathrm{\ell }$ does not lie on any parameter-to-return flow in $f$ (i.e., $\mathrm{\ell }\Rightarrow f\notin \mathrm{𝐶𝑟𝑖𝑡𝐹𝑢𝑛𝑐𝑠}$). Thus, any pointer reaching $g$ must originate within $f$ rather than from its callers, making $\mathrm{\ell }$ the appropriate flow-entry callsite for $g$. Thus, Rceus assigns context $[\mathrm{\ell }]$ to $g$.

• $\mathrm{■}$

  Case 3. $c^{\prime }=c$: Both $f$ and $g$ are precision-critical (i.e., $\mathrm{\_}\Rightarrow g\in \mathrm{𝐶𝑟𝑖𝑡𝐹𝑢𝑛𝑐𝑠}$ and $\mathrm{\ell }\Rightarrow f\in \mathrm{𝐶𝑟𝑖𝑡𝐹𝑢𝑛𝑐𝑠}$), and $\mathrm{\ell }$ lies on an interprocedural parameter-to-return flow that passes through $g$. The corresponding flow-entry callsite is already encoded in $f$’s context $c$, and this flow continues through $g$. Hence, $g$ inherits the caller’s context $c$.

Consider the program in Figure 3. All functions except main() are precision-critical. Let us see how their contexts, as shown in Figure 5, are derived. For Case 2, the calls to into_vec() at lines ${\mathrm{\ell }}_3$ and ${\mathrm{\ell }}_8$ occur under the empty context $[]$, so Rceus assigns $[{\mathrm{\ell }}_3]$ and $[{\mathrm{\ell }}_8]$, respectively – each marking a distinct flow-entry callsite. For Case 3, when into_vec() is reached under $[{\mathrm{\ell }}_3]$ or $[{\mathrm{\ell }}_8]$, its precision-critical callees (e.g., Vec::from_raw_parts() at ${\mathrm{\ell }}_{15}$) inherit the same context. Thus, the call at ${\mathrm{\ell }}_{15}$ is analyzed under $[{\mathrm{\ell }}_3]$ when the flow originates from ${\mathrm{\ell }}_3$, and under $[{\mathrm{\ell }}_8]$ when it originates from ${\mathrm{\ell }}_8$. This propagation continues through deeper precision-critical calls at ${\mathrm{\ell }}_{26},{\mathrm{\ell }}_{29},{\mathrm{\ell }}_{32},$ and ${\mathrm{\ell }}_{35}$. Rceus therefore preserves the flow-entry callsite throughout the precision-critical call chain, ensuring that all heap allocations remain associated with their correct origins (either ${\mathrm{\ell }}_3$ or ${\mathrm{\ell }}_8$).

Consider now the program in Figure 4. All functions except foo(), bar(), baz(), and is_ascii() are precision-critical. Let us see how their contexts, as shown in Figure 6, are derived. For Case 1, is_ascii() (called at ${\mathrm{\ell }}_4$) is not precision-critical and thus analyzed context-insensitively. For Case 2, the calls to String::deref() at ${\mathrm{\ell }}_3$, Vec::deref() at ${\mathrm{\ell }}_8$, slice::get() at ${\mathrm{\ell }}_{10}$, and array::index() at ${\mathrm{\ell }}_{15}$ each occur under the empty context and therefore generate the contexts $[{\mathrm{\ell }}_3]$, $[{\mathrm{\ell }}_8]$, $[{\mathrm{\ell }}_{10}]$, and $[{\mathrm{\ell }}_{15}]$ for analyzing their respective callees. These four flow-entry callsites ensure complete separation of the corresponding pointer flows.

Unlike standard $k$-limiting [19, 9, 45, 35], which requires a sufficiently large $k$ to keep these call chains distinct ($k⩾6$ for Figure 3 and $k⩾4$ for Figure 4), Rceus separates the same call paths using only a single flow-entry callsite per context.

Rceus is sound: regardless of the pre-analysis, the rules in Figure 11 ensure that every function reachable from main() is analyzed under at least one context.

Although Rceus is presented as an enhancement to standard $k$-limited context-sensitive pointer analysis, it can also be used as a drop-in improvement to existing $k$-limited techniques, substantially boosting both scalability and precision (Section 4). This enables analyses to retain tunable precision without paying the high cost of large-$k$ sensitivity.

Rceus is designed for achieving scalable precision in Rust by applying context sensitivity only where it matters – namely, to precision-critical functions – and by representing each calling context with exactly one flow-entry callsite. As a result, Rceus does not aim to be strictly more precise than uniform $k$-limiting, nor does it preserve its precision in every case; rather, it achieves a different, Rust-oriented balance that mitigates points-to blow-up while retaining sufficient precision for real-world analyses.

A small example in Figure 12 illustrates this tradeoff. Since Rceus identifies ${\mathrm{\ell }}_4$ as the sole flow-entry callsite for both zip() and the two into_iter() calls, all iterator constructions are analyzed under the same context $[{\mathrm{\ell }}_4]$, conflating the points-to sets for a and b. Avoiding this imprecision would require $k=5$ under standard $k$-limiting.

Crucially, this imprecision is narrowly scoped: it affects only the two iterator fields of the same Zip object, does not propagate beyond this context, and does not hinder Rceus’s ability to eliminate the far more severe points-to blow-up caused by Rust’s deeply layered abstractions. While this imprecision could be reduced by enriching the context with parameter indices, doing so yields limited additional precision in practice while increasing analysis cost. We therefore adopt the current design as a better balance between precision and efficiency, and view parameter-aware contexts as a direction for future work.

For scalability, $\mathrm{𝑘𝑐𝑠}$ fails to complete within the memory budget on the largest benchmarks – including meilisearch ($\mathit{1}cs$ and $\mathit{2}cs$), qdrant ($\mathit{2}cs$), and wasmtime ($\mathit{2}cs$) – whereas Rceus scales to all 16 programs while also using less memory throughout.

For precision, Rceus reduces #avg-pts by 86.6% over $\mathit{1}cs$ and 80.0% over $\mathit{2}cs$ on average across all benchmarks. The largest improvements occur on grin (94.3%, $52.09\to 2.95$) and qdrant (94.2%, $84.23\to 4.86$) vs. $\mathit{1}cs$, and on grin (93.7%, $46.53\to 2.95$) and resvg (92.4%, $29.00\to 2.19$) vs. $\mathit{2}cs$. These precision gains also eliminate many spurious call edges (#dce), most prominently in wasmtime ($\downarrow 170$ under $\mathit{1}cs$), atuin ($\downarrow 148$ under $\mathit{1}cs$; $\downarrow 76$ under $\mathit{2}cs$), and fselect ($\downarrow 71$ under $\mathit{1}cs$; $\downarrow 70$ under $\mathit{2}cs$).

Beyond precision, Rceus also delivers substantial efficiency gains, averaging 4.9$\mathbf{\times }$ faster than $\mathit{1}cs$ and 20.4$\mathbf{\times }$ faster than $\mathit{2}cs$. The largest speedups are $14.9\times$ on wasmtime and $10.2\times$ on atuin (vs. $\mathit{1}cs$), and $55.5\times$ on mdbook and $48.0\times$ on grin (vs. $\mathit{2}cs$).

As program size increases, Rceus yields progressively larger speedups while maintaining consistently high – and often increasing – reductions in #avg-pts. Detailed results appear in Table 2, with overall trends relative to $\mathit{1}cs$ shown in Figure 13.

Finally, Rceus lowers memory usage by 74.8% relative to $\mathit{1}cs$ and 93.1% relative to $\mathit{2}cs$, on average, owing to the substantially reduced points-to sets it computes.

SF-$kcs$ [18] augments $\mathrm{𝑘𝑐𝑠}$ with stack-object lifetime filtering, improving precision (#avg-pts reductions of 59.0% at $k=1$ and 59.3% at $k=2$) and efficiency ($2.2\times$ and $2.7\times$ speedups). However, because raw pointers mediating heap objects do not carry lifetimes, SF-$kcs$ cannot refine them. In addition, SF-$kcs$ applies uniform $k$-limiting to all functions, causing unnecessary context construction and analysis. As a result, it exhausts memory on the largest benchmarks (meilisearch, qdrant, wasmtime) under $\mathit{2}cs$, although lifetime filtering allows it to scale to meilisearch at $\mathit{1}cs$. In contrast, Rceus scales to all 16 benchmarks.

Beyond scalability, Rceus outperforms SF-$kcs$ in both precision and efficiency. At $k=1$, Rceus reduces #avg-pts by 68.9%, runs 2.4$\mathbf{\times }$ faster, and uses 61.9% less memory. At $k=2$, it reduces #avg-pts by 50.8%, runs 7.6$\mathbf{\times }$ faster, and requires 88.9% less memory.

Overall, Rceus delivers superior precision and efficiency to SF-$kcs$ across all 16 benchmarks, achieving consistently smaller #avg-pts and faster analysis, with only a single deviation in #dce on meilisearch. This deviation, similar to Figure 12 (Section 3.3), arises when multiple trait objects invoke a method returning a reference to the receiver, and the returned references are used in subsequent calls. Because Rceus preserves only the flow-entry callsite, these flows may be analyzed under the same context. While this avoids context blow-up, it can increase the number of dynamically resolved call edges. Even so, Rceus still achieves substantially smaller #avg-pts, and adding one most-recent callsite (Section 4.3) eliminates this isolated conflation while preserving scalability.

Sel-$kcs$ [25, 20] applies $k$-limiting only to precision-critical functions in $\mathrm{𝐶𝑟𝑖𝑡𝐹𝑢𝑛𝑐𝑠}$, improving efficiency at the cost of modest precision loss. It scales on 14 of the 16 benchmarks (failing on meilisearch and wasmtime under $\mathit{2}cs$) and speeds up $\mathrm{𝑘𝑐𝑠}$ by $2.5\times$ at $k=1$ and $6.9\times$ at $k=2$, though sometimes increasing #avg-pts or the number of resolved call edges (#dce). These results align with prior findings for Java, where the technique originated [25, 20].

In lsd, fselect, atuin, and qdrant, Sel-$kcs$ produces slightly higher #dce than $\mathrm{𝑘𝑐𝑠}$. This is because Sel-$kcs$’s selection of precision-critical functions targets layered-abstraction flows rather than allocation-site precision; consequently, some allocation-related functions are classified as non-precision-critical, leading to minor heap-object conflation.

Compared with Sel-$kcs$, Rceus provides substantially higher precision and efficiency. At $k=1$, it reduces #avg-pts by 87.9%, runs 2.2$\mathbf{\times }$ faster, and uses 57.4% less memory. At $k=2$, it reduces #avg-pts by 80.7%, runs 2.9$\mathbf{\times }$ faster, and consumes 71.3% less memory.