Fix #578: lexer wrongly interprets ".e[0-9]" as a number with scientific notation.

[niconoe-]

@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 😓

[MauricioFauth]

Could you please add a test with the example from the issue?

[niconoe-]

Could you please add a test with the example from the issue?

Yup, that's done 🙂

You can see on parseLoad8.out that the tokens are correctly set up, and the statement is having the expected properties without any error.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 96.83%. Comparing base (afe9173) to head (a004a6c).
Report is 55 commits behind head on 5.10.x.

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.
📢 Have feedback on the report? Share it here.