Error output improvement: when using semicolon, it leads to more than one possibility where developer might be going wrong.

[ghost]

Code

use std::env;

fn main() {
    let args: Vec<String> = env::args().collect();
    dbg!(args) // missing the semi colon here gives rise to two cases, either developer is missing the semi colon or he is actually passing a wrong return type
}

Current output

Compiling rustgrep v0.1.0 (C:\Users\<user>\Documents\Personal Workspace\rustgrep)
error[E0308]: mismatched types
 --> src\main.rs:5:5
  |
3 | fn main() {
  |           - expected `()` because of default return type
4 |     let args: Vec<String> = env::args().collect();
5 |     dbg!(args)
  |     ^^^^^^^^^^ expected `()`, found struct `Vec`
  |
  = note: expected unit type `()`
                found struct `Vec<String>`
  = note: this error originates in the macro `dbg` (in Nightly builds, run with -Z macro-backtrace for more info)

For more information about this error, try `rustc --explain E0308`.

Desired output

the desired output would be to allow the user to know all the possible cases that he might want to do. The current behaviour isn't wrong and it does help in a way.

Still, rust is a language where sometimes you put a semicolon and sometimes you don't, depending on the use case. I feel it would be more developer friendly if error messages were defined well in this case.

For example: (roughly saying what should be expected in output)
Hey developer, missing a semicolon had led to two possible things you might be doing wrong ->
Case 1: you are returning the wrong type to the main function
Case 2: you are returning the right thing but possibly you don't want the last statement as an expression. Please use a semicolon here on this line bla bla.

Rationale and extra context

No response

Other cases

No response

Anything else?

No response

[john-h-k]

Remove dbg! and you get the expected help, the issue is that post-expansion, dbg!(foo) looks like

match foo {
            tmp => {
                eprintln!("[{}:{}] {} = {:#?}", file!(), line!(), stringify!(foo), &tmp);
                tmp
            }
        }

and this expression isn't eligible for suggest_missing_semicolon. The rules around when missing semicolon is suggested would need to be relaxed

[john-h-k]

Nevermind, it's actually to do with a restriction around suggesting semicolons on external macros

see #81943

[ghost]

Nevermind, it's actually to do with a restriction around suggesting semicolons on external macros

see #81943

Ahh, so I guess nothing to be done at present? I will just keep this open then.