"function cannot return without recursing" should deny by default

[Y0h4n3s]

Code

#[derive(Default)]
struct VariantA {
    pub name: String
}

#[derive(Default)]
struct VariantB {
    pub name: String
}

enum DefaultEnum {
    A(VariantA),
    B(VariantB)
}

impl Default for DefaultEnum {
    fn default() -> Self {
        Default::default()
    }
}

fn main() {
    let default_enum: DefaultEnum = Default::default();
}

Current output

Compiling playground v0.0.1 (/playground)
warning: function cannot return without recursing
  --> src/main.rs:19:5
   |
19 |     fn default() -> Self {
   |     ^^^^^^^^^^^^^^^^^^^^ cannot return without recursing
20 |         Default::default()
   |         ------------------ recursive call site
   |
   = help: a `loop` may express intention better if this is on purpose
   = note: `#[warn(unconditional_recursion)]` on by default

warning: `playground` (bin "playground") generated 1 warning
    Finished dev [unoptimized + debuginfo] target(s) in 0.63s
     Running `target/debug/playground`

Desired output

should be an error instead of a warning

Rationale and extra context

This causes a stack overflow and should not compile

Other cases

No response

Anything else?

No response

[workingjubilee]

Whether this function causes a stack overflow depends on optimization settings. This function will in fact simply loop forever if you use --release, as it is tail-recursive, and thus LLVM will recognize this and perform the appropriate tail-call optimization.

As noted, there are legitimate reasons to use tail-recursion, even unconditional tail recursion, and Rust deliberately allows infinite loops, so I do not believe we will be upgrading this warning into an error.

[workingjubilee]

It is conceivable the diagnostic messages could be improved in the case of a simple constructor function, however, and this repros with a much simpler case:

enum DefaultEnum {
    A,
}

impl Default for DefaultEnum {
    fn default() -> Self {
        Default::default()
    }
}

fn main() {
    let default_enum: DefaultEnum = Default::default();
}

[eggyal]

Surely the return type of an unconditionally tail-recursive function should be !, in which case the warning can be suppressed; and any other return type ought to be an error?

[workingjubilee]

I think the "never" type was slightly too aptly named:

• Tracking issue for promoting ! to a type (RFC 1216) #35121

[eggyal]

It's (always been?) stable in return position: playground.

[workingjubilee]

Hm. I'm worried there's a case someone who is more clever at abusing the type system than me can contrive where you can get an unconditionally recursive function that by all rights this warning should detect that would still not be -> !, or that cannot be correctly and stably type-annotated with -> !.

[dbregman]

Ran into this stack overflow / infinite loop today and took a fair while to figure out what the issue was. I'm often ignoring warnings because they're so noisy while refactoring work is in progress (dead code etc) so didn't even think to check if it could be in warnings.

+1 for making it an error instead, if the compiler KNOWS the code will crash then there's no reason why that shouldn't be an error.