Fix parsing stream with first token size > parser's chunk size-4#45
Open
n-peugnet wants to merge 3 commits into
Open
Fix parsing stream with first token size > parser's chunk size-4#45n-peugnet wants to merge 3 commits into
n-peugnet wants to merge 3 commits into
Conversation
n-peugnet
force-pushed
the
issue-44-long-first-token
branch
3 times, most recently
from
84c07ed to
eab3a71
Compare
n-peugnet
changed the title
n-peugnet
changed the title
n-peugnet
changed the title
n-peugnet
force-pushed
the
issue-44-long-first-token
branch
from
2e9b9e9 to
99801b8
Compare
bzick
reviewed
Jul 12, 2026
| defer stream.Close() | ||
|
|
||
| require.True(t, stream.IsValid()) | ||
| assert.True(t, stream.CurrentToken().IsKeyword()) |
Owner
There was a problem hiding this comment.
please use require instead of assert
When (first token size) > (parser's chunk size-4), the next chunks are loaded during the parsing of the first token. This triggers the end of the parsing loop, leaving the frist token as the only one parsed, and thus having its "next" field set to nil. This in turn, lead Stream.GoNext() to detect the end of the stream. To fix this, Stream.GoNext() now starts by checking the next field of the current token, parsing the current chunk if needed, before deciding if the end of the stream is reached. Fixes bzick#44
NextToken() also assumed that the next token was always parsed, which is not the case. Add a new ensureParseNext() function that can be used in both GoNext() and NextToken(), and that makes sure the next token is parsed if the end of the stream has not been reached yet.
n-peugnet
force-pushed
the
issue-44-long-first-token
branch
from
99801b8 to
fda5579
Compare
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
2 participants
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.
When (first token size) > (parser's chunk size-4), the next chunks are
loaded during the parsing of the first token. This triggers the end of
the parsing loop, leaving the frist token as the only one parsed, and
thus having its "next" field set to nil. This in turn, lead
Stream.GoNext() to detect the end of the stream.
To fix this, Stream.GoNext() now starts by checking the next field of
the current token, parsing the current chunk if needed, before deciding
if the end of the stream is reached.
NextToken() also assumed that the next token was always parsed, which is
not the case. Add a new ensureParseNext() function that can be used in
both GoNext() and NextToken(), and that makes sure the next token is
parsed if the end of the stream has not been reached yet.
Tests have been added to prevent regressions.
Fixes #44