Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error recovery #2033

Draft
wants to merge 95 commits into
base: main
Choose a base branch
from
Draft

Error recovery #2033

wants to merge 95 commits into from

Conversation

PieterOlivier
Copy link
Contributor

@PieterOlivier PieterOlivier commented Sep 24, 2024

This is a feature-tracking PR, will remain draft while we are working on the error recovery feature. Other smaller PRs will target this branch, and when ready we can merge this one. Where possible we try to do most of the reviewing in the open PRs that target the error-recovery branch, but sometimes stuff is missed there, and then it's better to comment on changes in this global-tracking-PR.

History:

  • in 2012 @jurgenvinju wrote an initial implementation of parser recovery that was based on user supplied recovery hints.
  • in 2022 @jurgenvinju resurrected that recovery attempt and got into a decent shape, now without user supplied recovery hints, but lacked bandwidth to finish it.
  • in 2024 @PieterOlivier picked this backup as part of swat.engineering's effort to invest in some larger scale rascal infrastructure improvements.
  • Implement basic error recovery #2020 the first PR that was reviewed and merged into this feature branch.
  • TODO: more PRs to follow

jurgenvinju and others added 30 commits March 30, 2022 16:45
Sometimes recovery nodes start before the current location where
the parser failed to continue. Since the parser works with a
short queue of schedulede TODO's around the current cursor, we
might end up outside of this queue when recovering. This breaks
several unspecified invariants of the SGTBF implementations. For
now I added a detection that a recovery node is to be planned
before the currently retained history and filter that recovery
node. The next step will be to make sure backtracking over the
current location is made possible.
… because the next parser loop iteration always wants to advance one character
…e version of Rascal and (b) the edit command is wired to the edit IDEService
…t in the scheme by copyinhthe contents to a tmp file
@jurgenvinju
Copy link
Member

Do I comment on #2020 changes here, or on the other PR?

@DavyLandman
Copy link
Member

DavyLandman commented Sep 24, 2024

@jurgenvinju you can comment here (except for the changes in a open PR that targets this branch,). But commenting on closed PRs is not wise as the code might have evolved, and it will be hard to keep track of it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants