fix(frontend): Remove chumsky fork, attempt 2

[pczarn]

Related issue

Resolves #853

Description

Summary of changes

Replace recovier_via of the chumsky fork with skip_parser from chumsky 0.9.2.

Dependency additions / changes

- chumsky = { git = "https://github.com/jfecher/chumsky", rev = "ad9d312" }
+ chumsky = "0.9.2"

Test additions / changes

None.

Checklist

• I have tested the changes locally.
• I have formatted the changes with Prettier and/or cargo fmt with default settings.
• I have linked this PR to the issue(s) that it resolves.
• I have reviewed the changes on GitHub, line by line.
• I have ensured all changes are covered in the description.

Documentation needs

• This PR requires documentation updates when merged.

Additional context

[pczarn]

This is a workaround: since spans of the recovery failure alternative do not match the spans of other alternatives, only check that spans match if neither error comes from a recovery failure.

[pczarn]

I am not sure whether we should drop recovery failures during this merging. They are meant to never be shown to the user.

[jfecher]

They should likely be dropped just in case, although I'm not aware of any time in which we ever merge a recovery error with a normal user-facing error.

[jfecher]

Looks good so far. A few suggestions:

[pczarn]

@jfecher

Here is the description of the problem I encountered when looking into the CI failure: With recovery, empty lambda arguments (||) fail to parse. Chumsky prefers to parse "something that is a failure to parse nothing as something recovered to be something" over "nothing". This case happens with recovery within a repetition (.repeated()) or optionality (.or_not()). An issue is filed for Chumsky: zesterer/chumsky#159

The workaround is: get two variants of a parser of a sequence: first without recovery, second with a recovery. Put them as alternatives: failing without recovery, the variant with recovery will be attempted.

[pczarn]

@jfecher Recovery doesn't seem to work after adding the workaround:

Expected 1 error(s) and got 2:

Expected an expression but found |
secondary: 
Expected an end of input but found :
secondary: 

From input:   let g = |a:| a
Expected AST: let g: unspecified = |error: error| -> unspecified { plain::a }
Actual AST:   let g: unspecified = plain::a

[jfecher]

@pczarn does this apply to most/all recovery or is it only not working for lambda parameters?

How would you say parser error recovery in general looks like before & after this change - I haven't yet pulled the PR to test myself. I suppose I'm alright with removing lambda parameter recovery as long as other recovery is working since it shows there may be a path to fixing it, but if recovery all around is worse then it is more difficult.

[pczarn]

@jfecher

does this apply to most/all recovery or is it only not working for lambda parameters?

For function parameter recovery: Unaffected since parameter types are mandatory, so there is always at least a colon present and no need to worry about an empty parameter list. We do not currently recover for garbage with a missing colon.

For block statement recovery: unclear why an empty block is unaffected.

No other places where a recovery is covered by optionality. Only one more place where a recovery is used.

[jfecher]

Closing this since it has become stale. I can revisit it after confirming there have been bugfixes to chumsky to fix the changed parser recovery strategies.