Parse rejects a final line comment with no trailing newline, which JWCC allows
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 68/100
Research direction
Start in parse.go at consumeComment, which returns -1 when no closing newline exists, and at consumeExtra, which turns that into io.ErrUnexpectedEOF. Check the null// case in json_test.go, which currently expects that error and will change with the fix, and the Extra.format path that must keep Format idempotent. Done means {} // end and the JWCC example 123 // no final U+000A byte parse, U+2028/U+2029 handling is preserved, and the existing tests and fuzz targets pass.
Written by the indexing model from the issue text.
Description
Hi!
hujson.Parse rejects a line comment at the very end of the input when no \n follows it:
_, err := hujson.Parse([]byte("{} // end"))
// hujson: line 1, column 4: parsing comment: unexpected EOF
The JWCC text allows this. Since its update of 2021-07-20 it says "A line comment at the end of the file may omit the final '\n' byte", and gives 123 // no final U+000A byte as valid JWCC. That example fails the same way, at column 5.
consumeCommentin parse.go looks for the closing\nand returns -1 when there is none, soconsumeExtrareportsio.ErrUnexpectedEOF.- The
null//case in json_test.go (474be09) expects that error, so it would change along with the fix.
I have a small fix ready: consumeExtra treats the end of the input as the end of a line comment and keeps the U+2028 and U+2029 check from b80ff77, and Extra.format adds the missing newline, so Format stays idempotent (the null// fuzz seed caught that). The tests and both fuzz targets pass. Happy to open a PR if you'd take one.
I found this while running a set of JWCC test files through several parsers. Tested at b80ff77.
Best,
Simon
- Dominant language
- Go
- Stars
- 876
- Forks
- 35
- PR merge metrics
- No merged PRs in 30d
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from tailscale/hujson
-
Standardize modifies its input slice; the doc comment does not say soPossibly taken @jihtsan claimed this today. Open
Difficulty 1/5 Under an hour Newbie friendliness 60/100
-
Value.Patch: "add" with an out-of-range array index appends instead of failingPossibly taken @SashaMIT claimed this 4 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
Value.Patch: "test" operation always fails for a null valuePossibly taken @RaphaelFakhri claimed this 6 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
-
Patching with commentsPossibly taken @Shubham-Padkonde claimed this 19 days ago. Open
Difficulty 4/5 3-5 days Newbie friendliness 45/100
-
Version TagOpen
Difficulty 2/5 1-3 hours Newbie friendliness 55/100
All issues in tailscale/hujson
Similar issues
-
Named Tuple element with a space in its name fails to parsePossibly taken @spicysharkco claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
ClickHouse/clickhouse-go#2073 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
ci: nothing regenerates the Go contract types, so a hand-edit to types.gen.go passesPossibly taken @shaiknoorullah claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
shaiknoorullah/hg-mono#993 · 2 comments ·
Maintainers usually reply within 1 day
-
type:bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
CarlosDanielDev/aiacc#78 · 1 comment ·
Maintainers usually reply within 1 day
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 68/100