Recover from pub let

[obeis]

Closes #101622

[rustbot]

r? @michaelwoerister

(rustbot has picked a reviewer for you, use r? to override)

[Noratrieb]

The issue has the following idea:

Detect pub let specifically, and suggest either let or pub static/const. (This might be part of a general improvement to handling confusion between items and statements.

Presumably because some people try to use let for global variables (when they should use static instead).
I think it would make sense to recover pub let as pub static. For this, you'd have to modify the item parsing code instead of the visibility parsing code to also catch let just like static. You can then emit an error and actually recover to a ItemKind::Static.
You have to make sure to not break normal let local variables with it :D (for example by only recovering let when not in a statement context). You might even be able to fix #92615 with it depending on how you do it.

[michaelwoerister]

r? diagnostics

[obeis]

@rustbot ready

[compiler-errors]

I'm still not confident that this is the right place to put this code.

Have you tried placing the recovery into parse_item_kind instead? There's basically a big if-else chain that parses every item kind. You could probably add a recovery for let there?

Ideally, we'd consolidate this code into that as well:

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

Lines 72 to 76 in 21f6839

	let label = if self.is_kw_followed_by_ident(kw::Let) {
	"consider using `const` or `static` instead of `let` for global variables"
	} else {
	"expected item"
	};

[obeis]

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

Lines 67 to 80 in 21f6839

	if !self.eat(term) {
	let token_str = super::token_descr(&self.token);
	if !self.maybe_consume_incorrect_semicolon(&items) {
	let msg = &format!("expected item, found {token_str}");
	let mut err = self.struct_span_err(self.token.span, msg);
	let label = if self.is_kw_followed_by_ident(kw::Let) {
	"consider using `const` or `static` instead of `let` for global variables"
	} else {
	"expected item"
	};
	err.span_label(self.token.span, label);
	return Err(err);
	}
	}

When i converted the code above to this:

 if !self.eat(term) { 
     self.maybe_consume_incorrect_semicolon(&items); 
 } 

I got this weird error when main() function is exists

error[E0601]: `main` function not found in crate `r#main`
 --> main.rs:1:4
  |
1 | pub let x = 0;
  |    ^ consider adding a `main` function to `main.rs`

Also when moving the recover code to parse_item_kind, we need to figure out is the let inside function or outside function, I don't know how this can be done.

[bors]

☔ The latest upstream changes (presumably #105670) made this pull request unmergeable. Please resolve the merge conflicts.

[compiler-errors]

When i converted the code above to this [...] I got this weird error when main() function exists.

(edited) I'm not sure. You need to share an example of the code :/

Also when moving the recover code to parse_item_kind, we need to figure out is the let inside function or outside function, I don't know how this can be done.

I guess that's a good point :/

[bors]

☔ The latest upstream changes (presumably #107840) made this pull request unmergeable. Please resolve the merge conflicts.

[compiler-errors]

@rustbot author

[obeis]

@rustbot ready

[bors]

☔ The latest upstream changes (presumably #108682) made this pull request unmergeable. Please resolve the merge conflicts.

[compiler-errors]

r? @Nilstrieb since you like reviewing parser recoveries 😸 and i've given this pr enough review, and don't want to block it

[Noratrieb]

This looks good.

[Noratrieb]

The name of the function is parse_stmt_without_recovery, so I don't think it's a good idea to do recovery here. I think there was some kind of other function that gets called on invalid statements (I forgot the name but -Ztreat-err-as-bug may guide you there). Maybe you could check there?

[Dylan-DPC]

@obeis any updates on this?

[Dylan-DPC]

Closing this as inactive. Feel free to reöpen this pr or create a new pr if you get the time to work on this. Thanks