Infinite recursion is not catched by the compiler.

[wdanilo]

Hi, consider this code:

#![deny(unconditional_recursion)]

struct Object {
    
}

impl Object {
    // RENAME HERE:
    fn foo(&self) -> f32 {
        7.0
    }
}

impl ToObject for Object {
    fn to_object(&self) -> &Object {
        self
    }
}

trait ToObject {
    fn to_object(&self) -> &Object;
}


trait ObjectOps : ToObject {
    fn foo(&self) -> f32 {
        self.to_object().foo()
    }
}

impl<T:ToObject> ObjectOps for T {}

fn main() {
    let x = Object{};
    println!("{}",x.foo());
}

It works fine. Let's rename foo to foo2 next to the comment "RENAME HERE". What happens is that this code has infinite recursion now and rustc doesn't report any error nor warning despite the usage of #![deny(unconditional_recursion)].

This is a serious problem, as a simple refactoring can cause something like that and it is very, very hard to debug, especially on WASM platform, where infinite recursion can just return a random number (it is UB). This problem could be solvable if I was able to write somehow MAGIC::Object::foo(self.to_object()) instead of self.to_object().foo() but in such a way, that the methods from ObjectOps would not be visible in MAGIC::Object. Currently, when refactoring such code we can get infinite recursion and spend hours debugging it :(

[jumbatm]

Thanks for the report!

Very slightly trimmed test case:

#![deny(unconditional_recursion)]

struct Object;

trait ToObject {
    fn to_object(&self) -> &Object;
}

impl ToObject for Object {
    fn to_object(&self) -> &Object {
        self
    }
}

impl<T: ToObject> ObjectOps for T {}

trait ObjectOps : ToObject {
    fn foo(&self) -> f32 {
        self.to_object().foo()
    }
}

fn main() {
    let x = Object;
    println!("{}", x.foo());
}

The (false?) negative for unconditional_recursion essentially boils down to this case:

#![deny(unconditional_recursion)]
fn bar() {
    foo();
}

fn foo() {
    bar();
}

fn main() {
    foo();
}

ie, when the cycle in the callgraph is formed with at least one other function. This is because the lint currently only fires if a function directly calls itself, eg:

fn foo() {
    foo();
}

Relevant comment here:

rust/src/librustc_mir_build/lints.rs

Lines 29 to 37 in 548afdb

	//FIXME(#54444) rewrite this lint to use the dataflow framework
	// Walk through this function (say `f`) looking to see if
	// every possible path references itself, i.e., the function is
	// called recursively unconditionally. This is done by trying
	// to find a path from the entry node to the exit node that
	// *doesn't* call `f` by traversing from the entry while
	// pretending that calls of `f` are sinks (i.e., ignoring any
	// exit edges from them).

[jonas-schievink]

Part of #57965

Is this the same issue or should I open an extra issue?

struct Floaty {}

impl From<f64> for Floaty {
    fn from(value: f64) -> Floaty {
        value.into()
    }
}

fn main() {
    let _: Floaty = 1.0.into();
}

This does not generate any recursion warnings.

On musl any recursion segfaults, which I reported here: #75667. The above was my original case, util I realized that it segfaults for any recursions.

[jonas-schievink]

@Etherealist Yeah, same issue

[jhg]

Maybe this is also same issue:

use std::fmt;

#[derive(Copy, Clone)]
pub enum MyEnum {
    A,
    B,
}

impl AsRef<str> for MyEnum {
    fn as_ref(&self) -> &str {
        match self {
            Self::A => "a",
            Self::B => "b",
        }
    }
}

impl fmt::Display for MyEnum {
    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
        write!(f, "{}", &self)
    }
}

fn main() {
    println!("{}", MyEnum::A);
}

Maybe it is calling recursively to Display::fmt but the compiler does not detect it is calling to itself when it is a trait.

Edit: I see now #45838, maybe this is like that other issue more than like this issue.