`RangeFromIter` gives wrong values when mixing crates with different `overflow-checks` settings

[theemathas]

The implementation of the unstable core::range::RangeFromIter does different things depending on whether the current crate has overflow-checks turned on or not. This logic was introduced in #148703. It does not function properly when mixing multiple crates with different overflow-checks settings.

In particular, when the iterator's next method is called in a crate with overflow-checks = true, the first field is set to false. This logically signifies that the next value that the iterator should produce is start + 1. Then, the iterator can be passed to a crate with overflow-checks = false, which always makes the iterator produce the value of start, disregarding the first field.

The code for reproducing this bug is given below. The code prints 10. The correct behavior is to print 11.

For your convenience, all files required to run the program are also available as a zip file.

src/dep1/lib.rs

#![feature(new_range_api)]

use std::range::{RangeFrom, RangeFromIter};

pub fn make_iter() -> RangeFromIter<u8> {
    let mut iter = RangeFrom { start: 10 }.iter();
    let _ = iter.next();
    iter
}

src/dep2/lib.rs

#![feature(new_range_api)]

use std::range::RangeFromIter;

pub fn use_iter(mut iter: RangeFromIter<u8>) {
    println!("{}", iter.next().unwrap());
}

src/main.rs

use dep1::make_iter;
use dep2::use_iter;

fn main() {
    let iter = make_iter();
    use_iter(iter);
}

Cargo.toml

[workspace]
resolver = "3"
members = ["dep1", "dep2"]

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

[dependencies]
dep1 = { version = "0.1.0", path = "dep1" }
dep2 = { version = "0.1.0", path = "dep2" }

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

[profile.dev.package.dep2]
overflow-checks = false

Meta

rustc --version --verbose:

rustc 1.96.0-nightly (bcf3d36c9 2026-03-19)
binary: rustc
commit-hash: bcf3d36c997dd9b5db4bb7f40cb91dd4cf46a305
commit-date: 2026-03-19
host: aarch64-apple-darwin
release: 1.96.0-nightly
LLVM version: 22.1.0