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

Don't use the external scanner for ... #228

Merged
merged 1 commit into from
Sep 9, 2022

Conversation

alex-pinkus
Copy link
Owner

We now have better invalidation of operators in the custom scanner than we did when we added the various .-prefixed operators. This means we can bail out quickly and avoid marking a token incorrectly.

This simplifies downstream handling of ..., which, in addition to being a Swift operator, is also used by Semgrep.

In order to make this happen, we do also have to be a bit more careful with mark_end. If we're possibly going to emit a _semi, we have to make sure not to mark_end, because we don't want that to be "part of" the semi. This theoretically means that if we were chasing a longer operator, but failed to find it, and had a shorter operator that was cross_semi, it would get parsed incorrectly -- but this seems unlikely since such a longer operator would be likely to match the custom_operator pattern to begin with.

Fixes #226

We now have better invalidation of operators in the custom scanner than
we did when we added the various `.`-prefixed operators. This means we
can bail out quickly and avoid marking a token incorrectly.

This simplifies downstream handling of `...`, which, in addition to
being a Swift operator, is also used by Semgrep.

In order to make this happen, we do also have to be a bit more careful
with `mark_end`. If we're possibly going to emit a `_semi`, we have to
make sure not to `mark_end`, because we don't want that to be "part of"
the semi. This theoretically means that if we were chasing a longer
operator, but failed to find it, and had a shorter operator that was
`cross_semi`, it would get parsed incorrectly -- but this seems unlikely
since such a longer operator would be likely to match the
`custom_operator` pattern to begin with.

Fixes #226
@alex-pinkus alex-pinkus merged commit f58deb7 into main Sep 9, 2022
@alex-pinkus alex-pinkus deleted the fix-operator-handling-for-semgrep branch September 9, 2022 04:30
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.

Whitespace allowed in open end range expression
1 participant