The `if cfg!(debug_assertions)` make the `unconditional_recursion` lint not work (e.x. when using `debug_assert_eq!`)

[joshuachp]

I tried this code:

struct Buf<'a> {
    len: u16,
    buf: &'a [u8],
}

impl Buf<'_> {
    fn len(&self) -> usize {
        if core::cfg!(debug_assertions) {
            let _ = self.len();
        }

        self.len.into()
    }
}

fn main() {
    let buf = Buf {
        len: 3,
        buf: &[1, 2, 3],
    };

    println!("{}", buf.len());
}

I expected to see this happen: a lint on the infinite recursion for calling self.len().

Instead, this happened: the debug assertion doesn't make the lint visible.

This is the simplification of the following code:

struct Buf<'a> {
    len: u16,
    buf: &'a [u8],
}

impl Buf<'_> {
    fn len(&self) -> usize {
        debug_assert_eq!(self.len(), self.buf.len());

        self.len.into()
    }
}

fn main() {
    let buf = Buf {
        len: 3,
        buf: &[1, 2, 3],
    };

    println!("{}", buf.len());
}

Meta

I think there are other issues regarding this kind of infinite recursion, but I wanted to focus on the issue about the debug_assert... case, since it's a common pattern and the error is not easy to debug and is misleading:

thread 'main' (68424) has overflowed its stack
fatal runtime error: stack overflow, aborting
fish: Job 1, 'cargo +nightly r' terminated by signal SIGABRT (Abort)

I understand it's not actually unconditional_recursion, but it's really hard to understand when this error is encountered.

Tried with nightly

rustc --version --verbose:

rec ❯ rustc +nightly --version --verbose
rustc 1.93.0-nightly (518b42830 2025-11-16)
binary: rustc
commit-hash: 518b428304e0008859cb1fd81d1ac20efb2a064a
commit-date: 2025-11-16
host: x86_64-unknown-linux-gnu
release: 1.93.0-nightly
LLVM version: 21.1.5

[bjorn3]

As far as pretty much all static analysis (including typeck, borrowck and the unconditional_recursion lint) in rustc are concerned, fn foo() { if true { foo(); } } is indistinguishable to fn foo() { if random() { foo(); } } which doesn't have unconditional recursion.

[workingjubilee]

It seems unconditional_recursion doesn't fire if it sees an if condition.

That seems to be working as intended.

[workingjubilee]

I suppose that's not very helpful, but it seems a bit puzzling. The assertion that the debug_assert! case is a common pattern seems doubtful to me.

@joshuachp Out of curiosity, why were you using a type that occupies size_of::<*mut u8>() * 3 bytes when the internal &[u8] occupies size_of::<*mut u8>() * 2 and tracks its length already?

[joshuachp]

Thanks for responding, but as I have written in the original issue, I already understood this is not an unconditional_recursion per se, and I am not familiar with Rust internal to argue that is not a possible way to simplify fn foo() { if true { foo(); } } into fn foo() { foo(); } for the special case of a literal true value in the if condition. I can only trust you on that.

However, is there really nothing we can do to improve this lint, or the error message?

After you debug a case of infinite recursion for the first time, you'll be aware of this error case. Although, it's not usual in safe Rust to encounter a SIGABRT, and a new user would be confused by a stack overflow, this can cause confusion. I would argue, even experience users could get confused by this, since there are other cases of stack overflow.

For example, in my case, I thought I've allocated something too big on the Stack and I had to open gdb to find where the SIGABRT happened and to understand this was just an infinite recursion in a debug_assert, which is a bit frustrating after using wasting time debugging.

Is it not possible to create a Clippy lint for this specific type of expression? To catch using the same function in a debug_assert in the function body, since I believe it's a particular case of unconditional_recursion.

If we cannot catch this with static analysis, can we maybe improve the error message for stack overflows in debug builds? With some explanation on probable causes?

Furthermore, I believe in the specific case of the debug_assert! the macro expands to an if, but the issue wouldn't be present if the code used a block with #[cfg(debug_assertions)]. I say this, even though I am not aware of why it was implemented this way, and the tradeoffs between using if cfg!() and #[cfg] in the debug_assert,

I suppose that's not very helpful, but it seems a bit puzzling. The assertion that the debug_assert! case is a common pattern seems doubtful to me.

In my experience it is, if you want to check that a property of a struct that is checked during construction is respected as a precondition of method calls and checked during tests, and some example could be: getting the first element of a non-empty Vec, an only ASCII string, etc...

We can code defensively to prevent this kind of bugs, like name of fields different to the name of methods, but is there no way to improve or prevent this kind of error?

[joshuachp]

I suppose that's not very helpful, but it seems a bit puzzling. The assertion that the debug_assert! case is a common pattern seems doubtful to me.

@joshuachp Out of curiosity, why were you using a type that occupies size_of::<*mut u8>() * 3 bytes when the internal &[u8] occupies size_of::<*mut u8>() * 2 and tracks its length already?

@workingjubilee this was a simplification of the original code that uses zerocopy to parse a MQTT network packet. In the len() method, I wanted to make sure the len field is the same length as the parsed packet data.

Original code

use zerocopy::{network_endian::U16, *};

#[derive(SplitAt, ByteEq, FromBytes, IntoBytes, KnownLayout, Immutable)]
#[repr(C)]
pub struct Buff {
    pub(crate) len: U16,
    pub(crate) data: [u8],
}

impl Buf {
    pub fn len(&self) -> usize {
        // debug_assert_eq!(usize::from(self.len.get()), self.data.as_ref().len());
        debug_assert_eq!(self.len(), self.data.as_ref().len());

        self.len.into()
    }
}

[joshuachp]

As far as pretty much all static analysis (including typeck, borrowck and the unconditional_recursion lint) in rustc are concerned, fn foo() { if true { foo(); } } is indistinguishable to fn foo() { if random() { foo(); } } which doesn't have unconditional recursion.

This seems unfortunate for cases like:

fn foo() {
    if true {
        foo();

        return;
    }

    // No warning
    println!("this is dead code");
}

Event thought I don't think are that common :)

Edit: or maybe it's actually used in some cases "if true {" lang:rust

[joshuachp]

If the compiler is not a good place to do this, do you think it would be possible to do something similar to clippy::assertions_on_constants and clippy::debug_assert_with_mut_call?

Something like debug_assertion_recurtion

[workingjubilee]

Yes, I do appreciate that this is very frustrating, to be clear.

I wonder if solving a dynamic problem through static analysis is the right approach? If some of our unwinding code was async-signal-safe, it might be possible to even extract a backtrace.