-
-
Notifications
You must be signed in to change notification settings - Fork 102
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 #578: lexer wrongly interprets ".e[0-9]" as a number with scientific notation. #579
Conversation
… 4, causing wrong lexing process.
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.
Could you please add a test with the example from the issue?
Yup, that's done 🙂 You can see on |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## 5.10.x #579 +/- ##
============================================
+ Coverage 96.81% 96.83% +0.01%
+ Complexity 2294 2259 -35
============================================
Files 70 71 +1
Lines 5248 5152 -96
============================================
- Hits 5081 4989 -92
+ Misses 167 163 -4 ☔ View full report in Codecov by Sentry. |
@williamdes Here is my fix about #578.
On the first and fourth (because I forgot to move from state 10 to state 4) commits, you can see that token ".e4" is parsed as is and wrongly considered as a number, causing the effect of not being able to detect the "." in "database_name.table_name" as an operator, and cascading to a failure in the parser.
On the second commit, with the fix, you can see ".e4" is no longer a token, but instead "." is a token, and "e4" is another one, which is not a number.
On the third commit… eh, please don't look, I just forgot to remove a debuging stuff 😓