Specific Error Message or Note for Final Expression being Loop and Return not Unit

[Havvy]

fn loop_ending() -> i32 {
    loop {
        if false { break; }
        return 42;
    }
}

produces

error[E0308]: mismatched types
 --> <anon>:2:5
  |
2 |       loop {
  |  _____^ starting here...
3 | |         if false { break; }
4 | |         return 42;
5 | |     }
  | |_____^ ...ending here: expected i32, found ()
  |
  = note: expected type `i32`
  = note:    found type `()`

error: aborting due to previous error

But the compiler can check that the final expression is a loop and must always evaluate into (), so we can recommend more advanced information.

This has caused real confusion.

[nikomatsakis]

What would you think we ought to suggest?

[nikomatsakis]

(In other words, I'm trying to understand what users might be going for when writing code like this... I guess we could say something like "no value returned along this control-flow path" or something?)

[Havvy]

Perhaps saying that the i32 is the expected type because the loop is the implicit return. I forgot about break value; actually being a thing when I initially posted the issue, though for loops also have the issue.

I guess the issue might actually be that we're not showing where the i32 came from.

[nikomatsakis]

Another example (Derived from #18390):

fn main() {
    let _ = foo();
}

fn foo() -> i32 {
    let x = 5;
    match x {
        1 => {
            return 1
        },
        2 => {
            return 2
        },
        3 => {
            return 3
        },
        4 => {
            return 4
        },
        5 => {
            return 5
        },
        _ => { }
    }
}

gives:

error[E0308]: mismatched types
  --> src/main.rs:23:14
   |
23 |         _ => { }
   |              ^^^ expected i32, found ()
   |
   = note: expected type `i32`
              found type `()`

I guess the key point in both cases is that the user is writing more "C-style" code and not expecting to make use of the "implicit return" here, so the error is sort of surprising.

[nikomatsakis]

It seems to me that we could cover this by a similar rule to the one we use to suggest removing a semicolon -- in particular, if the expected type is not unit, but we are returning unit from a tail expression, and that tail expression is some kind of "control-flow" structure, we might point to the end of it and say something like "no return along this path":

error[E0308]: no return along this path
 --> src/main.rs:3:20
  |
3 |         if false { break; }
  |                    ^^^^^ following this path, no value is ever returned
  |

This will require a bit more state to be plumbed around, I imagine, not entirely sure what (and I'm not entirely sure where the error should be reported -- on the break, as I showed above?).

[estebank]

The current output is even worse, IMO:

error[E0308]: mismatched types
 --> src/main.rs:3:20
  |
3 |         if false { break; }
  |                    ^^^^^ expected (), found i32
  |
  = note: expected type `()`
             found type `i32`

[estebank]

Current output:

error[E0308]: mismatched types
 --> src/lib.rs:3:20
  |
3 |         if false { break; }
  |                    ^^^^^
  |                    |
  |                    expected i32, found ()
  |                    help: give it a value of the expected type: `break 42`
  |
  = note: expected type `i32`
             found type `()`