Recover from for-else and while-else

[y21]

This recovers from attempts at writing for-else or while-else loops, which might help users coming from e.g. Python.

for _ in 0..0 {
  // ...
} else {
  // ...
}

Combined with trying to store it in a let binding, the current diagnostic can be a bit confusing. It mentions let-else and suggests wrapping the loop in parentheses, which the user probably doesn't want. let-else doesn't make sense for for and while loops, as they are of type () (which already is an irrefutable pattern and doesn't need let-else).

Current diagnostic

error: right curly brace `}` before `else` in a `let...else` statement not allowed
 --> src/main.rs:4:5
  |
4 |     } else {
  |     ^
  |
help: wrap the expression in parentheses
  |
2 ~     let _x = (for _ in 0..0 {
3 |         
4 ~     }) else {
  |

Some questions:

• Can the wording for the error message be improved? Would "for...else loops are not allowed" fit better?
• Should we be more "conservative" in case we want to support this in the future (i.e. say "for...else loops are currently not allowed/supported")?
• Is there a better way than storing a &'static str for the loop type? It is used for substituting the placeholder in the locale file (since it can emit either for...else or while...else). Maybe there is an enum I could use that I couldn't find

[rustbot]

r? @michaelwoerister

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

[Nilstrieb]

Thanks! Having a dedicated error is great, but I don't like the suggestion.

[michaelwoerister]

r? diagnostics

[mejrs]

When this sort of thing comes up I tend to recommend https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.try_for_each, and ControlFlow, which seems to work for most people.

Maybe there is an enum I could use that I couldn't find

You can invent one, and implement IntoDiagnosticArg if you want to insert it into the string.

Or you can change your error type to:

pub enum LoopElseNotSupported{
    While { .. },
    For { .. }
}

[compiler-errors]

Thanks! This looks great. One suggestion?

[mejrs]

As for the suggestion, remember that the user themselves might not know what they want. When you ask people what they think Python's for..else does you'll get a split of:

• The else body is executed if the loop body is never executed
• The else body is executed if the loop manages to complete fully (i.e. without break).

In Rust, a reasonable interpretation might also be "the else branch is executed if the loop never breaks with a value" i.e. they wrote

for _ in iterator {
  break value
} else {
  fallback_value
}

[y21]

By the way, I intentionally did not add this recovery to loop {} else {} (only for and while) because I don't think such code actually makes sense to write (there is no condition that can become false, you can only manually break out of it).
Should I add it anyway, for consistency?

[compiler-errors]

I don't see why not, especially since pointing out the loop keyword that the else is associated might help the user realized they got their braces wrong.

[y21]

There was a failing ui test under let-else that was checking for the old error when let pat = loop {} else {}; is encountered.
I moved it to its own file, because the new error isn't about let-else anymore. Not sure if that test makes sense anymore tho or if I should just remove it entirely.

[compiler-errors]

@bors r+

[bors]

📌 Commit 13b8497 has been approved by compiler-errors

It is now in the queue for this repository.

[y21]

Looks like this failed in a rollup because Parser::parse_else_expr was removed, or, I guess renamed to parse_expr_else.
Rebased/updated the PR.

[compiler-errors]

@bors r+

[bors]

📌 Commit 0758c05 has been approved by compiler-errors

It is now in the queue for this repository.