Inlining can affect whether overflow checks are performed, when mixing `overflow-checks` across crates.

View all comments

Consider the following code across two crates (crate foo depends on crate dep):

src/main.rs (crate foo):

fn main() {
    let _ = dep::add_one(255_u8);
}

dep/src/lib.rs (crate dep):

pub fn add_one(x: u8) -> u8 {
    x + 1
}

This code causes an arithmetic overflow. Since the addition is done in the crate dep, I expect the code to panic if the dep crate has overflow-checks turned on, and not panic if the dep crate has overflow-checks turned off.

However, with the following Cargo.toml, running the code with cargo run causes the code to not panic, even though the dep crate has overflow-checks turned on.

[workspace]
resolver = "3"
members = ["dep"]

[package]
name = "foo"
version = "0.1.0"
edition = "2024"

[dependencies]
dep = { version = "0.1.0", path = "dep" }

[profile.dev]
opt-level = 3
incremental = false
overflow-checks = false

[profile.dev.package.dep]
overflow-checks = true

Removing the opt-level = 3 line or the incremental = false line makes the code panic as expected.

Here's a zip of the code, for your inconvenience.

Meta

rustc --version --verbose:

rustc 1.98.0-nightly (f46ec5218 2026-06-30)
binary: rustc
commit-hash: f46ec5218fe7829ac18323b5ee0b409a63169f27
commit-date: 2026-06-30
host: aarch64-apple-darwin
release: 1.98.0-nightly
LLVM version: 22.1.8

Reproduce the behavior with src/main.rs, dep/src/lib.rs, and the supplied Cargo.toml by running cargo run. Start by examining how cross-crate inlining interacts with the two crates' overflow-checks and optimization settings. Done means the behavior consistently follows the overflow-checks setting of the crate containing the addition, including with opt-level = 3 and incremental = false.