Strange extra type error after missing semicolon error

[jruderman]

Given the following code (playground):

fn f() -> f32 {
    3
    5.0
}

fn main() {
}

The current output is:

error: expected `;`, found `5.0`
 --> epp.rs:2:6
  |
2 |     3
  |      ^ help: add `;` here
3 |     5.0
  |     --- unexpected token

error[E0308]: mismatched types
 --> epp.rs:2:5
  |
2 |     3
  |     ^ expected `()`, found integer

What is this second error trying to tell me? What did it expect to be unit type and why? Does it make sense for this error to be emitted despite the first error correctly identifying my problem?

[compiler-errors]

What is this second error trying to tell me?

It's trying to tell you nothing in particular. This is a bug, due to the fact that we eat the 5.0 token and replace it with ;, so the "fixed" body ends up being:

fn f() -> f32 {
  3
  ;
}

[jruderman]

That theory doesn't seem right to me, for two reasons:

• I would expect eating the 5.0 to result in a type error like "expected f32 because of return type", but the actual error involves integer and unit.
• Repeating the missing-semi error results in repeating the type error as well, even though it's all within one function. For example:

fn f() -> f32 {
    2_u32
    3_i8
    5.0
}

fn main() {
}

gives two missing-semi errors and two type errors:

error: expected `;`, found `3_i8`
 --> src/lib.rs:2:10
  |
2 |     2_u32
  |          ^ help: add `;` here
3 |     3_i8
  |     ---- unexpected token

error: expected `;`, found `5.0`
 --> src/lib.rs:3:9
  |
3 |     3_i8
  |         ^ help: add `;` here
4 |     5.0
  |     --- unexpected token

error[E0308]: mismatched types
 --> src/lib.rs:2:5
  |
2 |     2_u32
  |     ^^^^^ expected `()`, found `u32`

error[E0308]: mismatched types
 --> src/lib.rs:3:5
  |
3 |     3_i8
  |     ^^^^ expected `()`, found `i8`

[chenyukang]

The error is reported at this point

rust/compiler/rustc_parse/src/parser/diagnostics.rs

Line 459 in 9be2f35

return Ok(true);

Then it's considered as recovered, and the mismatched types are reported at type anlysising phase.

@compiler-errors
Should we treat it as unrecovered, or make the expr dummy so that type anlysising won't report error messages?

[chenyukang]

@rustbot claim

[compiler-errors]

@chenyukang please first understand what the AST doing on the semicolon recovery path, then once that's done, you can probably try to make it recover like: 3; 5.0 properly so it type-checks correctly.