Warn on circular code

[orowith2os]

What it does

When code goes in a circular loop (fn1 calls fn 2, which then calls fn1), Clippy will emit a warning about this behavior, so the programmer won't have to wonder why their program apparently hangs.

In debug mode, it will crash with the following:

thread 'main' has overflowed its stack
fatal runtime error: stack overflow

This would be something along the lines of unconditional_recursion in rustc, unsure if these checks need to be in two separate places.

See #428 for a previous issue.

Advantage

Circular Rust code now won't compile without the programmer knowing it's circular, but can still do so if desired.

Drawbacks

None

Example

fn output1() {
    output2();
}

fn output2() {
    output1();
}

fn main() {
    output1();
}

[Noratrieb]

related rust-lang/rust issue: rust-lang/rust#57965
This was implemented in rustc in rust-lang/rust#75067, but it was a significant perf regression.

[Centri3]

I think it's reasonable in the case that it's 100% irrefutable and does nothing big before it, like output1 -> output2 in the example given, anything more complex though it shouldn't be added yeah due to performance reasons

Another problem then though is whether that should even be added in the first place, as if it only lints the simplest of conditions it'll likely not be too helpful

[orowith2os]

It might be useful to get a visual representation of a situation like this from the compiler, and go from there? Not sure if any tools exist for that already, but would be nice.

[Centri3]

Tools definitely do, debuggers :D But yeah if it wasn't a severe performance hazard then I'd be 100% for the compiler warning of this

[orowith2os]

Oh, I meant more a GUI, like a graph. Would make it easier to see what's going in loops and what isn't, then I can maybe poke around and see if I can figure anything out (or redo all the mistakes that came before)

[orowith2os]

Thoughts

Maybe a more thorough checking mode would be ideal? That way you have the normal stuff, day-to-day mistakes, and then you have more troublesome things like this.

The former would be used normally, on each compile, and the latter can be used e.g. in CI, or pre-commit hooks.

[Centri3]

As it stands currently lints must be ran even if they're always allowed, so that isn't really possible in current clippy/rustc. See rust-lang/rust#106983

If it's the same lint that would work better but just the simpler implementation would already be quite a bit slower, afaik