fix: parse errors show meaningful messages instead of internal 'fail' label#1022
Merged
stephenamar-db merged 1 commit intoJun 24, 2026
Merged
Conversation
… label
Motivation:
Parse errors exposed fastparse's internal combinator name "fail"
(e.g., "Expected fail:1:12"), which is meaningless to users.
Root cause: Several parser rules used bare `Fail` instead of
`Fail.opaque("descriptive message")`, causing fastparse to use
the default "fail" label in error messages.
Fix: Replace bare `Fail` with descriptive `Fail.opaque(...)`:
- String literal parsing: "string literal"
- Verbatim string (@): "verbatim string literal (@\" or @')"
- Expression parsing: "expression"
Result:
- Before: "Expected fail:1:12, found ..."
- After: "Expected expression:1:12, found ..."
Also includes error test files for format %c validation (from PR databricks#1015).
Cross-implementation comparison (local x = ; x):
| Implementation | Error message |
|---|---|
| C++ jsonnet | "unexpected: \";\" while parsing terminal" |
| go-jsonnet | "Unexpected: \";\" while parsing terminal" |
| sjsonnet (before) | "Expected fail:1:12" |
| sjsonnet (after) | "Expected expression:1:12" ✅ |
stephenamar-db
approved these changes
Jun 24, 2026
4 tasks
He-Pin
added a commit
to He-Pin/sjsonnet
that referenced
this pull request
Jun 24, 2026
…ged code behavior PR databricks#1022 added format_c error test files (intended as part of PR databricks#1015's %c validation coverage). However, PR databricks#1022's CI ran at 08:07 UTC, before PR databricks#1015 was merged at 16:51 UTC. The golden files were generated from code without %c rejection, so they contained success output instead of error messages. Two minutes after databricks#1015 merged, databricks#1022 was squash-merged — the stale golden files entered master without a CI re-run on the combined state. Fix both golden files to contain the actual sjsonnet.Error output: - error.format_c_multichar.jsonnet.golden: "AB" → error message - error.format_c_empty_string.jsonnet.golden: "" → error message
stephenamar-db
pushed a commit
that referenced
this pull request
Jun 24, 2026
…ehavior (#1031) ## Summary PR #1022 added format_c error test files intended as part of PR #1015 `%c` validation coverage. However, PR #1022 CI ran at 08:07 UTC, before PR #1015 was merged at 16:51 UTC. The golden files were generated from code without `%c` rejection, so they contained success output instead of error messages. Two minutes after #1015 merged, #1022 was squash-merged. The stale golden files entered master without a CI re-run on the combined state. ## Timeline ``` 08:07 PR #1022 CI runs, master has NO %c rejection code "%c" % "" outputs "" golden correct at this time "%c" % "AB" outputs "AB" golden correct at this time CI all green 16:51 PR #1015 merged, %c rejection code enters master 16:53 PR #1022 merged, stale golden files enter master with no CI re-run After All PRs branch from master with both %c rejection and stale goldens "%c" % "" errors, golden "" is now wrong "%c" % "AB" errors, golden "AB" is now wrong ``` ## Fix Update both golden files to contain the actual `sjsonnet.Error` output: | File | Before stale | After correct | |---|---|---| | `error.format_c_multichar.jsonnet.golden` | `"AB"` | `sjsonnet.Error: [std.format] %c expected 1-sized string got: 2` | | `error.format_c_empty_string.jsonnet.golden` | `""` | `sjsonnet.Error: [std.format] %c expected 1-sized string got: 0` | ## Implementation behavior comparison Behavior verified with go-jsonnet and jrsonnet latest local binary, `jrsonnet 0.5.0-pre99`. Both implementations reject empty and multi-character strings for `%c`, and accept single Unicode code points. | Expression | go-jsonnet 0.21.0 | jrsonnet 0.5.0-pre99 | Expected sjsonnet behavior | |---|---|---|---| | `std.format("%c", "")` | exit 1, `%c expected 1-sized string got: 0` | exit 1, `%c expected 1 char string, got 0` | exit 1, `%c expected 1-sized string got: 0` | | `std.format("%c", "AB")` | exit 1, `%c expected 1-sized string got: 2` | exit 1, `%c expected 1 char string, got 2` | exit 1, `%c expected 1-sized string got: 2` | | `std.format("%c", "A")` | exit 0, `"A"` | exit 0, `"A"` | exit 0, `"A"` | | `std.format("%c", "世")` | exit 0, `"世"` | exit 0, `"世"` | exit 0, `"世"` | | `std.format("%c", 127757)` | exit 0, `"🌍"` | exit 0, `"🌍"` | exit 0, `"🌍"` | ## Verification ``` ./mill "sjsonnet.jvm.2_13_18.test" -- "*FileTests*" Tests: 102, Passed: 102, Failed: 0 rtk ./mill "sjsonnet.jvm[3.3.7]".test.testOnly sjsonnet.FileTests Tests: 3, Passed: 3, Failed: 0 rtk ./mill "sjsonnet.jvm[3.3.7]".test SUCCESS ``` ## Test plan - [x] FileTests.new_test_suite passes with corrected golden files - [x] Full JVM Scala 3.3.7 test suite passes locally - [x] go-jsonnet and jrsonnet behavior compared for `%c` empty, multi-character, single ASCII, single Unicode, and numeric codepoint cases - [ ] CI green on all 4 build targets: js, jvm, native, wasm
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.
fix: parse errors show meaningful messages instead of internal "fail" label
Motivation
Parse errors exposed fastparse's internal combinator name
"fail"(e.g.,Expected fail:1:12), which is meaningless to users. Root cause: several parser rules used bareFailinstead ofFail.opaque("descriptive message").Modification
Parser.scala: Replaced 5 bareFailwith descriptiveFail.opaque(...):"string literal"@) →"verbatim string literal (@\" or @')""expression"Result
local x = ; xExpected fail:1:12❌Expected expression:1:12✅@helloExpected fail:1:2❌Expected verbatim string literal✅{a: }Expected fail:1:6❌Expected expression:1:6✅