A Synthesis Method of Safe Rust Code Based on Pushdown Colored Petri Nets

Abstract: Safe Rust guarantees memory safety through strict compile-time constraints: ownership can be transferred, borrowing can temporarily guarantee either shared read-only or exclusive write access, and ownership and borrowing are scoped by lifetime. Automatically synthesizing correct and safe Rust code is challenging, as the generated code must not only satisfy ownership, borrowing, and lifetime constraints, but also meet type and interface requirements at compile time. This work proposes a synthesis method based on our newly defined Pushdown Colored Petri Net (PCPN) that models these compilation constraints directly from public API signatures to synthesize valid call sequences. Token colors encode dynamic resource states together with a scope level indicating the lifetime region in which a borrow is valid. The pushdown stack tracks the entering or leaving of lifetime parameter via pushing and popping tokens. A transition is enabled only when type matching and interface obligations both hold and the required resource states are available. Based on the bisimulation theory, we prove that the enabling and firing rules of PCPN are consistent with the compile-time check of these three constraints. We develop an automatic synthesis tool based on PCPN and the experimental results show that the synthesized codes are all correct.

• The paper introduces a PCPN-based method that synthesizes safe, compile-time validated Rust code using API signatures.
• It models Rust's resource semantics with colored tokens and pushdown stacks, accurately enforcing ownership, borrowing, and lifetimes.
• Experiments demonstrate 100% correctness under bounded synthesis, offering a decidable and modular approach to automated safe code generation.

Pushdown Colored Petri Nets for Safe Rust Code Synthesis

Introduction and Motivation

The synthesis of safe and compilable Rust code is constrained by the language's affine type system, which mechanizes memory safety through compile-time rules including ownership, borrowing, and lifetimes. Automating such synthesis necessitates not only type correctness, but also strict adherence to Rust’s aliasing and lifetime requirements at a fine-grained level, especially across complex API boundaries. The paper introduces an overview methodology based on the Pushdown Colored Petri Net (PCPN) formalism, enabling systematic exploration of valid resource transformations—directly corresponding to legal Rust program traces—while ensuring type, ownership, and lifetime correctness (2604.02399).

Formalization of Synthesis Targets and Resource Semantics

The approach formulates Rust program synthesis as a reachability problem: generating call sequences that transform an initial configuration of values and references—defined in terms of Rust's module signatures—into one satisfying a goal, such as producing a required output. This is modeled in a core language that abstracts all resource-affecting operations as atomic state transitions (function calls, structured resource transformers, borrowing/discharging, projections, and explicit drops). Ownership is tracked at the granularity of values, with explicit modeling of affine vs Copy semantics; borrowing introduces further state distinctions, enforced through stack-like discipline for region-based lifetimes.

To bridge the gap between source-level Rust and operational semantics, each API item is treated as a parametric state transformer—specified solely by its signature and obligations (trait, associated types, outlives)—and composed symbolically via Petri net transitions.

Pushdown Colored Petri Net (PCPN) Construction

The core innovation is the definition and mechanization of the PCPN:

• Places are indexed by capabilities (own, frozen, blocked) and type instances, reflecting ownership and borrow states.
• Token colors encode identifier, type, and region instantiations, allowing the tracking of value provenance, polymorphic bindings, and concrete lifetime regions.
• Transitions encompass both API-derived call schemas and structural steps encoding moves, borrows, drops, field projections, duplications for Copy/Clone, dereferencing, and (re)borrowing.
• Pushdown stack mechanisms encode the entrance and exit of borrow/lifetime regions, ensuring that nested lifetimes are tracked exactly at the point of creation and discharge.

Enabling of transitions requires successful type/lifetime unification (solving for generic parameters in the presence of ground types), evidence discharge (trait and lifetimes), and satisfaction of stack discipline for region-scoped borrows. The firing rules and guard satisfaction problems correspond structurally to compile-time checks performed by Rust’s compiler (i.e., borrow checker and trait/lifetime system).

Bisimulation Correctness and Strong Claims

The paper establishes a strong bisimulation result: the operational semantics of structurally valid (closed-world) Rust code executions under their signature-level abstract machine is provably equivalent—modulo renaming of region or value IDs—to forward traces in the corresponding PCPN instance. The implication is that the net's reachability precisely characterizes all and only those program traces that would be accepted at compile time given a set of APIs and type instantiations. Notably, the construction avoids the need for introspection into function bodies or implementation specifics, relying solely on public API signatures and trait/associated type/lifetime facts.

Bounded Reachability and Synthesis Pipeline

Due to the undecidability of Petri net reachability in unbounded settings, the approach introduces explicit bounds on resource duplication and borrow depth. Under these bounds, the system constructs a finite, canonical reachability graph by saturating the state space up to β-equivalence (canonicalization modulo renaming). Synthesis proceeds via goal-directed search in this graph—enabling witness extraction (traces leading to objectives such as value creation or transformation)—and deterministic suffix completion to ensure all borrows are closed, producing valid Rust snippets.

All code emitted is guaranteed to be signature-compliant, borrow-safe, and memory-safe under the Rust type system. Evaluations (as stated in the abstract) report 100% correctness: “experimental results show that the synthesized codes are all correct,” though full quantitative data are not detailed in the available text.

Theoretical and Practical Implications

The PCPN construction and its formal correspondence with Rust resource semantics have several implications:

• Decidability: By bounding token counts and borrow stack depth, synthesis becomes decidable and tractable over realistic modules and libraries, avoiding state-space explosion by leveraging symbolic canonicalization.
• Generality: The approach is agnostic to the internal implementation of functions/methods, requiring only signatures and a small derived fact base (trait implementors, associated types), making it suitable for modular synthesis and verification, API exploration, and trusted code search.
• Precision: The signature-induced semantics support precise generic constraint solving without requiring concrete type instantiations for all cases, and do not over-approximate in the presence of complex lifetime or trait constraints.

On the theoretical side, the method provides a model-theoretic foundation for aligning affine resource logics, typestate analysis, and concurrent systems techniques (Petri nets) within practical language engineering. Practically, it enables program synthesis, protocol conformance verification, and compiler test-case generation for safe fragments of Rust, with the prototype publicly accessible (see (2604.02399)).

Future Directions

Open directions stated in the paper include relaxing the under-approximation inherent in explicit bounding, integrating unsafe and async features, and leveraging heuristic-guided exploration of the canonical reachability graph for more scalable synthesis with complex generic APIs. Further application to fuzzing, model-checking, and synthesis for other affine or region-based languages is suggested.

Conclusion

This work provides a rigorous and effective formalism for synthesizing safe Rust code from API signatures via Pushdown Colored Petri Nets, with strong semantic guarantees stemming from a bisimulation correspondence to a signature-induced operational semantics. The approach yields a tractable, decidable solution space under finite resource bounds, and supports correct-by-construction snippet generation for complex, generic, and lifetime-rich Rust code, advancing both theory and practice in automated safe code synthesis for modern type systems (2604.02399).