Unexpected "expected function" error with unit type

[Ezrashaw]

I tried this code:

fn main() {
    let x = 5

    ()
}

I expected to see this happen:

error: expected `;`, found `}`
 --> src/main.rs:2:14
  |
2 |     let x = 5
  |              ^ help: add `;` here
3 | }
  | - unexpected token

One error occurs from the missing semicolon.

Instead, this happened:

error: expected `;`, found `}`
 --> src/main.rs:4:7
  |
4 |     ()
  |       ^ help: add `;` here
5 | }
  | - unexpected token

error[E0618]: expected function, found `{integer}`
 --> src/main.rs:2:13
  |
2 |       let x = 5
  |  _____________^
3 | |
4 | |     ()
  | |______- call expression requires function

An additional unexpected error occurs when when I obviously do not want to invoke a closure. Also note that the semicolon error is after the supposed closure invocation, when I would expect it to be after the let x = 5.

Meta

Occurs on latest stable and nightly.

[fmease]

@rustbot label A-diagnostics D-newcomer-roadblock D-terse

[lyming2007]

The compiler would consider the case

fn main() {
    let x = 5

    ()
}

the same as

fn main() {
    let x = 5()
}

I think it's hard to determine if the user wants invoke a closure or not by writing the "()" to the next line.
Rust allows syntax like this(actually a lot of languages allow this type of syntax)

// Rust example  of a closure
#![allow(unused_variables)]
fn main() {
let closure_variable = |x: i32| x * 10;
  
assert_eq!(100,closure_variable
                    
(10));
}

[fmease]

I think it's hard to determine if the user wants invoke a closure or not by writing the "()" to the next line.

We should definitely be able to look at the spans of the callee and the argument list, determine if they are on separate lines (via the SourceMap) & don't originate from a macro expansion and if so at least add a note to the diagnostic suggesting to add a semicolon. Of course, there will always be false positives.

[estebank]

The case should be handled in both the parser and the call error. In the parser we can't be certain that the call expression is incorrect, except for maybe literals, but if you had

fn main() {
    let x = 5;
    let y = x
    ()
}

we are back to ambiguity, so that should be handled in E0618 and suggest a semicolon there as well. You could also have

fn main() {
    let x = 5;
    let y = x
    ();
}

which would parse successfully but fail only in the call.

[lyming2007]

@rustbot claim

[Noratrieb]

When adding a nice parser error you have to make sure that you never emit a parser error for valid rust syntax.
So for the example Esteban described above handling it in the parser is fine since the let statement is missing a semicolon, making it invalid syntax.
But you have to make sure that something like

fn foo() {
  1
  ()
}

doesn't give a parser error but only errors during type checking.

This is because of macros, which may transform code that is valid syntax but invalid semantically into something entirely valid.

[estebank]

At the very least, these cases should be handled

fn a() {
    let x = 5;
    let y = x //~ ERROR expected function
    ()
} //~ ERROR expected `;`, found `}`

fn b() {
    let x = 5;
    let y = x //~ ERROR expected function
    ();
}
fn c() {
    let x = 5;
    x //~ ERROR expected function
    ()
}
fn d() { // ok
    let x = || ();
    x
    ()
}
fn e() { // ok
    let x = || ();
    x
    ();
}
fn f()
 {
    let y = 5 //~ ERROR expected function
    ()
} //~ ERROR expected `;`, found `}`
fn g() {
    5 //~ ERROR expected function
    ();
}

[Ezrashaw]

I guess I should also be clear that the suggestion currently provided by rustc could never be correct: function (and closure) names can't start with integer

[fmease]

I guess I should also be clear that the suggestion currently provided by rustc could never be correct: function (and closure) names can't start with integer

The diagnostics currently emitted by the compiler are absolutely correct: An integer cannot be called and the let-statement must be followed by a semicolon. Indeed, identifiers (“function (and closure) names”) cannot start with a digit. However, this is not relevant here: Syntactically speaking, the callee (the thing being called) in a call expression can be an arbitrary expression. Consider (T {} + "")() (this might even be well-typed depending on the definition of T and its impls).

So 5() is syntactically well-formed but semantically it is not (according to the trait solver) as there is no primitive integer type (e.g. i32) that implements FnOnce or friends. Technically speaking, core could very well add a FnOnce implementation for i32 that makes 5() semantically well-formed, too.

This is the reason why you see the error messages you posted. Edit: I hope it's already clear from context but I'd like to emphasize that I am not saying that the diagnostics as emitted today should stay the way they are (we should definitely suggest to add a ; as mentioned above), I am just trying to clarify the semantics and disputing the quoted statement.

[Ezrashaw]

Ahh right, I forget briefly that function calls could be on values, I was thinking of the integer literal being seen as an identifier only (and of course integer identifiers don't exist). Silly me!