Suspicious scope parsing (compile error)

[stanislav-tkach]

I tried this code:

fn foo() -> u8 {
    1
}

fn bar() -> bool {
     { foo() } != 0
}

I would expect it to compile successfully, but I got the compile error instead:

error: expected expression, found `!=`
 --> src/main.rs:6:16
  |
6 |      { foo() } != 0
  |                ^^ expected expression

warning: unnecessary braces around block return value
 --> src/main.rs:6:6
  |
6 |      { foo() } != 0
  |      ^^^^^^^^^ help: remove these braces
  |
  = note: `#[warn(unused_braces)]` on by default

error[E0308]: mismatched types
 --> src/main.rs:6:8
  |
6 |      { foo() } != 0
  |        ^^^^^- help: try adding a semicolon: `;`
  |        |
  |        expected `()`, found `u8`

It is a minimal reproducible example, so it triggers the "unnecessary braces around block return value" warning. In the real code an unsafe block that cannot be removed is used.

Meta

rustc --version --verbose:

rustc 1.51.0 (2fd73fabe 2021-03-23)
binary: rustc
commit-hash: 2fd73fabe469357a12c2c974c140f67e7cdd76d0
commit-date: 2021-03-23
host: x86_64-unknown-linux-gnu
release: 1.51.0
LLVM version: 11.0.1

rustc 1.53.0-nightly (42816d61e 2021-04-24)
binary: rustc
commit-hash: 42816d61ead7e46d462df997958ccfd514f8c21c
commit-date: 2021-04-24
host: x86_64-unknown-linux-gnu
release: 1.53.0-nightly
LLVM version: 12.0.0

[ehuss]

Thanks for the report! I believe this currently is expected behavior due to lookahead concerns. There is some more discussion in #7909 and #54482. Similar confusion has also been reported in #74854. There's a bit of a description in https://doc.rust-lang.org/nightly/reference/statements.html#expression-statements that discusses how the tail expression of a block is handled:

An expression that consists of only a block expression or control flow expression, if used in a context where a statement is permitted, can omit the trailing semicolon. This can cause an ambiguity between it being parsed as a standalone statement and as a part of another expression; in this case, it is parsed as a statement. The type of ExpressionWithBlock expressions when used as statements must be the unit type.

In this situation, the block is interpreted as a statement. Then it moves on and sees !=, and gives the error of expecting an expression.

The error could be better, though.

[stanislav-tkach]

@ehuss Thanks for the explanation! I'm going to close this as a duplicate.