Skip to content

Attempt error recovery for no-matches as well#594

Closed
Xanewok wants to merge 1 commit intoNomicFoundation:mainfrom
Xanewok:error-recovery-delimited-no-match
Closed

Attempt error recovery for no-matches as well#594
Xanewok wants to merge 1 commit intoNomicFoundation:mainfrom
Xanewok:error-recovery-delimited-no-match

Conversation

@Xanewok
Copy link
Copy Markdown
Contributor

@Xanewok Xanewok commented Sep 9, 2023

Based on #586.

This relies on using almost entirely skipped parse rules to stop at
terminators such ';' in the contract members list. In the future,
we'd need to expand the recovery boundary token set and handle that
appropriately ourselves.

@changeset-bot
Copy link
Copy Markdown

changeset-bot bot commented Sep 9, 2023

⚠️ No Changeset found

Latest commit: fd9359b

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

This relies on using almost entirely skipped parse rules to stop at
terminators such ';' in the contract members list. In the future,
we'd need to expand the recovery boundary token set and handle that
appropriately ourselves.
@Xanewok
Copy link
Copy Markdown
Contributor Author

Xanewok commented Sep 25, 2023

I'd like to close this in favour of #601, as there might not be enough benefit for doing that in a general case and recovering from unknown statements at a terminator should probably be a result of improving the synchronizing token set (#600), instead.

@Xanewok Xanewok closed this Sep 25, 2023
github-merge-queue bot pushed a commit that referenced this pull request Sep 27, 2023
…inside (#601)

Simpler variant of #594.

While writing an issue for the potential null parse recovery, it just
hit me that we might not need to support that generally but rather just
limiting that to the delimited group would give us enough bang for the
buck.

TerminatedBy null parse recovery can be a bit too greedy, i.e. we might
recover some unexpected item definition just because... we recovered at
the final terminator. However, the delimited group is a reasonable
boundary since it's simple (2-3 kinds of general delimiters versus
different kinds of potentially versioned terminated statements) and the
opening delimiter must always match the closing one, so it produces more
reliable and self-contained recovered phrases, hence attempting to
recover from a null parse in a delimited group makes more sense.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant