Improve diagnostics for 'let…else' without 'guard'

[jrose-signal]

Motivation

The following code produces a generic "consecutive statements on a line must be separated by ';'" error:

let specific = general as? Specific else {
  return nil
}

However, there's a reason somewhat might write this: this is the Rust syntax for pattern-match-or-exit-scope (though in Rust it's closer to guard case than guard let). Even without that justification, else is not normally the start of a statement anyway, so better recovery is possible.

Proposed solution

If a let or var decl is followed by else, ideally recover as if the user had written guard let instead. If that's not possible, at least add a dedicated diagnostic for the else rather than just "consecutive statements…" followed by "expected expression".

Alternatives considered

No response

Additional information

No response

[AnthonyLatsis]

New parser:

stdin:1:37: error: extraneous code at top level
1 | let specific = general as? Specific else {
  |                                     `- error: extraneous code at top level
2 |   return nil
3 | }

[jrose-signal]

Ah, I meant in a function body, at top level in a non-script file that's probably reasonable.

[AnthonyLatsis]

2 | func f() {
3 |   let specific = general as? Specific else {
  |                                       `- error: unexpected code in function
4 |     return nil
5 |   }

@hamishknight Does the new parser have a parse-as-library setting?

[hamishknight]

Does the new parser have a parse-as-library setting?

Not AFAIK, parsing a SourceFileSyntax always just allows top-level code currently. The "extraneous code at top level" error is because it's failing to parse else as anything useful and just treating it as unexpected