-
Notifications
You must be signed in to change notification settings - Fork 27
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
Fix reparse trailing escape #67
base: master
Are you sure you want to change the base?
Fix reparse trailing escape #67
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense, thanks!
Ah actually the test seems to be falling |
Ok, great! There is another bug still: escaping is for some reason not handled correctly at all in the presence of Unicode, e.g. |
9c20c7a
to
1a9e169
Compare
Oops, force-pushed just as you added a review, maybe it was on the thing that I fixed in any case. |
1a9e169
to
2989e66
Compare
Ok everything seems to be fine now |
Oh of course this is still is still wrong in the ASCII case now too and needs to be fixed there too. Sorry about that, should have read the surrounding code more carefully before pushing the PR! |
2989e66
to
bedf70d
Compare
This also fixes an unrelated bug when parsing needles which contain non-ASCI Unicode.
bedf70d
to
e87b446
Compare
Now the parsing code is changed even more. I added some tests with all of the edge cases that I found in the previous implementation, so hopefully the new one is more correct, but to be honest with manual parsing code like this without extremely good test coverage I am always a bit concerned.
|
Two changes here:
First, fixes #66 to check for a trailing unescaped
\
.The other fix, which is in the second commit and which I am slightly less sure about, is to replace an ASCII whitespace check with a
is_whitespace
check inAtom::new
. This behaviour was previously changed in #65 forPattern::(re)parse
, is it also correct for this to take place inAtom::new
? If this is incorrect I'll drop the second commit.