Repository navigation
Conversation
State what the inline block is and why, instead of how it came to be. It mirrors scan_lexeme(), so the pointer keeps the two copies in sync.
Each of these comments repeated the byte that the condition right above it already checks. Comments that label less obvious skips stay.
The pattern matches a single literal backslash, so it can be written directly instead of being built with preg_quote() on every call.
Both lexers repeated the ASCII characters allowed in an unquoted identifier in read_identifier() and in the "@" variable name scan.
MySQL reads "t.1", "t.1st", and "order.id" as qualified names, but both lexers failed on them: they scanned ".1" as a decimal number, and they emitted "order" as the ORDER keyword. Follow MySQL's MY_LEX_IDENT_SEP lexer state: - A "." right after an unquoted identifier separates name parts, and digits after it start an identifier. After a quoted identifier or whitespace, ".1" stays a number. - A word right before a "." and a name is an identifier, even when it is a reserved keyword. After "@@", it stays a keyword, so system variable scopes like "@@session.sql_mode" keep working. The fix applies to the mysql-parser lexer and to the mysql-on-sqlite lexer that the driver still uses. The MySQL server corpus query that covers this case now parses in both, and driver tests run such queries end to end. See: https://github.com/mysql/mysql-server/blob/mysql-8.4.10/sql/sql_lex.cc
|
Important Draft PR not reviewedDraft PRs are not automatically reviewed by default.
To automatically review draft PRs, update your CodeRabbit configuration: reviews:
auto_review:
drafts: true
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Contributor
🤖 Lexer benchmarkChanges to lexer-related files were detected and triggered a benchmark:
Note: Hosted runners are noisy, and absolute numbers vary. Treat the results with caution and verify them locally. To reproduce locally: |
JanJakes
changed the title
t.1 and order.id
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
MySQL reads
t.1,t.1st, andorder.idas qualified names, but both of our lexers failed on them. They scanned.1as a decimal number and emittedorderas theORDERkeyword, so such queries didn't parse.This change makes both lexers handle qualified names like MySQL's own lexer. It covers the new
mysql-parserlexer and themysql-on-sqlitelexer that the driver still uses:t.1andt.1e5are qualified names.order.idworks, while@@session.sql_modekeeps its meaning.All cases were checked against MySQL 8.4, and one more query from the MySQL server test corpus now parses.
The PR also applies smaller notes from the review of the new lexer:
Follows up on #429.