Fix '#' inside string literals being lexed as a comment - #22
Merged
FallenAngel97 merged 1 commit intoJul 5, 2026
Merged
Conversation
Owner
|
Hello @lovesegfault ! May I ask you to update this PR as well? |
The comment token runs to end of line, so at a position like the content of "#fff" it outmatched the string-content token on length and the string interior was consumed as a comment, corrupting the parse of everything after it (with a later string in the file the quotes re-pair across rules). Give the quoted_string and raw_string content tokens lexical precedence over the comment token, mirroring the precedence the two interpolated string forms already had. Comments after strings on the same line still lex normally, since the string-content tokens are not valid outside string interiors. Adds corpus tests for '#' in quoted and raw strings and for a real comment following a string that contains '#'. Fixes FallenAngel97#21
lovesegfault
force-pushed
the
fix-hash-in-string
branch
from
July 4, 2026 23:47
d4ea9a5 to
46c904a
Compare
Contributor
Author
|
done! |
Owner
|
Thank you, @lovesegfault , I see that tests have passed, therefore all good. |
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.
Fixes #21.
Problem
The
commenttoken runs to end of line, so when the lexer sits at the interior of a string like"#fff", the comment token (5+ chars, through the closing quote and beyond) outmatches the string-content token (4 chars, stops at the quote) under the longest-match rule. The string interior is consumed as a comment and the parse of everything after it is corrupted — with a later string in the file, the quotes re-pair across rules:parses today with
#fff"as a(comment)inside anERROR.Fix
Give the
quoted_stringandraw_stringcontent tokens lexical precedence (prec(1)) over the comment token — exactly the precedence the two interpolated string forms (interpolated_string_double,interpolated_string_raw) already carry, which is why$"#..."was unaffected. Lexical precedence takes priority over match length, so string content wins inside string interiors, while comments after strings on the same line still lex normally (string-content tokens aren't valid outside string interiors):keeps
(quoted_string)followed by(comment).src/is regenerated withtree-sitter generate.Tests
New
test/corpus/strings.txtcovering#in quoted strings,#in raw strings, and a real comment following a string that contains#. Full corpus: 42/42 passing.