Suggest removing semicolon at the end of non-unit function

[jody-frankowski]

fn add(a: i32, b: i32) -> i64 {
    a + b;
}

With this code, rustc doesn't print a message such as:

help: consider removing this semicolon:
a + b;

It only prints

error: not all control paths return a value [E0269]

rustc 1.0.0-nightly (c5961ad06 2015-01-28 21:49:38 +0000)
binary: rustc
commit-hash: c5961ad06d45689b44ff305c15d6ec7ec65755a9
commit-date: 2015-01-28 21:49:38 +0000
host: x86_64-unknown-linux-gnu
release: 1.0.0-nightly

[nagisa]

Removing the semicolon would cause a type error, therefore the compiler is correct not printing the help message.

EDIT: pointing out which branches don’t return a value might be useful though.

[jody-frankowski]

It's two errors at once.
The help message is helpful for beginners, and is tightly related to the E0269 error. So I don't see why it shouldn't be printed when there is a E0269 error.

[frewsxcv]

Another option: only suggest removing the semicolon if the expression before the semicolon matches the return type of the function.

[nagisa]

@frewsxcv it already does exactly that.

[frewsxcv]

Ah nevermind then

[nagisa]

I got bit today by a more complex example:

src/lex.rs:151:5: 189:6 error: not all control paths return a value [E0269]
src/lex.rs:151     fn lex_number(&mut self) -> Option<LiteralToken<'source>> {
src/lex.rs:152         self.source.chars().next().and_then(|d| {
src/lex.rs:153             if let '0'...'9' = d {
src/lex.rs:154                 let number = self.source.char_indices()
src/lex.rs:155                     .filter(|x| // Filter out convenience underscores
src/lex.rs:156                         x.1 != '_'
               ...
src/lex.rs:151:5: 189:6 help: run `rustc --explain E0269` to see a detailed explanation
error: aborting due to previous error

which happened because I accidentally a semicolon after a pretty big and_then. The span is pretty confusing in a sense that it suggests the error is somewhere in the filter. It also did not suggest removing the semicolon, even though the types were correct.

[steveklabnik]

Triage: no change, other than the new error format.

[Mark-Simulacrum]

Closing in favor of collective issue for this general problem: #41897.