Presenter(s)
Hamilton Ferris
Abstract
Rust Crates are concise, safe ways to abstract compilation units in the Rust programming language. Each crate can be compiled individually, or some may depend on others (i.e. function `bar` may depend on crate `foo`). However, there is no standard way to compile Rust crates in a `no_std` configuration, which targets the compilation at embedded systems. Existing research into this topic mostly focuses on developer opinion. Sharma et al. (2025) discovered that only 68% of developers thought that Rust crate support was sufficient. In addition, 92% of developers surveyed also used C for embedded systems, and 64% of them claimed an improvement in code safety after switching to Rust, implying a market for Rust features, but not some of the baggage that comes with the language. This paper tests the open problem P0.1 from the 2025 paper authored by Sharma et al., which hypothesizes the idea of compiling a given Rust crate and its dependencies using a binary constraint satisfaction algorithm to derive the correct compilation flags. This paper expands the hypothesized algorithm to be able to derive the minimum required compilation flags for a given Rust crate. The Rust crates are downloaded from lib.rs, filtered by `no_std` compatability, then piped into the Binary Constraint Object Model (BCOM), which is modeled using the python library PuLP. The model then determines what, if any flags need to be enabled in order to achieve a successful compilation (i.e. no errors during compilation), then displays them to the console. In addition to this, a manually compiled set of crates using `cargo build –no-default-features` are collected, the “human” set to compare the accuracy and minimal feature flag derivation of the BCOM. During testing, the BCOM successfully detected and printed feature flags for some of lib.rs’ most popular crates, but only if they declared such features in the `Cargo.toml` file, specifying configuration options for each Rust crate build. The model is expected to be extended to support in-line code derivations as well as lib.rs declarations, in order to be fully applicable to all Rust crates.
College
College of Science & Engineering
Department
Computer Science
Campus
Winona
First Advisor/Mentor
Mingrui Zhang
Second Advisor/Mentor
Trung Nguyen
Location
Kryzsko Great River Ballroom, Winona, Minnesota; United States
Start Date
4-23-2026 1:00 PM
End Date
4-23-2026 2:00 PM
Presentation Type
Poster Session
Format of Presentation or Performance
In-Person
Session
2a=1pm-2pm
Poster Number
19
Exploring Boolean Dependency Mapping for Rust Crates Aimed at Embedded Systems
Kryzsko Great River Ballroom, Winona, Minnesota; United States
Rust Crates are concise, safe ways to abstract compilation units in the Rust programming language. Each crate can be compiled individually, or some may depend on others (i.e. function `bar` may depend on crate `foo`). However, there is no standard way to compile Rust crates in a `no_std` configuration, which targets the compilation at embedded systems. Existing research into this topic mostly focuses on developer opinion. Sharma et al. (2025) discovered that only 68% of developers thought that Rust crate support was sufficient. In addition, 92% of developers surveyed also used C for embedded systems, and 64% of them claimed an improvement in code safety after switching to Rust, implying a market for Rust features, but not some of the baggage that comes with the language. This paper tests the open problem P0.1 from the 2025 paper authored by Sharma et al., which hypothesizes the idea of compiling a given Rust crate and its dependencies using a binary constraint satisfaction algorithm to derive the correct compilation flags. This paper expands the hypothesized algorithm to be able to derive the minimum required compilation flags for a given Rust crate. The Rust crates are downloaded from lib.rs, filtered by `no_std` compatability, then piped into the Binary Constraint Object Model (BCOM), which is modeled using the python library PuLP. The model then determines what, if any flags need to be enabled in order to achieve a successful compilation (i.e. no errors during compilation), then displays them to the console. In addition to this, a manually compiled set of crates using `cargo build –no-default-features` are collected, the “human” set to compare the accuracy and minimal feature flag derivation of the BCOM. During testing, the BCOM successfully detected and printed feature flags for some of lib.rs’ most popular crates, but only if they declared such features in the `Cargo.toml` file, specifying configuration options for each Rust crate build. The model is expected to be extended to support in-line code derivations as well as lib.rs declarations, in order to be fully applicable to all Rust crates.
