I found a situation where the body of a function affects whether another function (which doesn't call or otherwise use it) compiles. Normally Rust can compile print_stuff below, unless the broken feature is enabled, in which case compiling print_stuff hits the recursion limit.

main.rs:

use std::fmt::Display; fn main() { print_stuff(&[2, 3, 5, 7, 11, 13, 17]); } pub fn print_stuff<'a, T>(vals: &'a T) where &'a T: IntoIterator<Item: Display>, { println!("Values:"); for val in vals { println!(" {val}"); } } #[allow(dead_code)] fn random_unrelated_code() { #[cfg(feature="broken")] rust_broken_local_reasoning::no_op(); }

lib.rs:

pub fn no_op() {} // Note: The rest isn't pub... struct Wrapper<T>(T); impl<'a, T> IntoIterator for &'a Wrapper<T> where &'a T: IntoIterator, { type Item = <&'a T as IntoIterator>::Item; type IntoIter = <&'a T as IntoIterator>::IntoIter; fn into_iter(self) -> Self::IntoIter { (&self.0).into_iter() } }

(for convenience I've made a tiny repo demonstrating this)

I expected to see the code compile even with the broken feature enabled.

Instead, it hits recursion limits.

This was surprising to me for a few reasons:

• print_stuff doesn't use random_unrelated_code in any way, so I wouldn't expect the body of random_unrelated_code to impact whether print_stuff compiles.
• I wouldn't expect privately implementing Wrapper to be a breaking change, yet it causes previously working consumer code to fail to compile. This is doubly surprising because print_stuff and Wrapper each compile in isolation; it's not until used together that you discover that Wrapper is problematic.
• I'm also surprised that Wrapper hits recursion limits because its IntoIterator impl just hands things off to the wrapped implementation, and Rust has no difficulty compiling a nearly-identical IntoIterator implementation with the references removed.

Meta

This is reproducible on stable, nightly and beta.

rustc --version --verbose:

rustc 1.89.0 (29483883e 2025-08-04) binary: rustc commit-hash: 29483883eed69d5fb4db01964cdf2af4d86e9cb2 commit-date: 2025-08-04 host: x86_64-unknown-linux-gnu release: 1.89.0 LLVM version: 20.1.7