Problem
qjd_parse currently returns an opaque QJD_PARSE_ERROR on malformed JSON with no position information. Callers cannot tell the user where the JSON is broken, making debugging difficult.
Proposal
Extend the error surface to include:
- Byte offset of the first invalid byte detected during Phase 1 (structural scan).
- Optionally a path context string (e.g.
"[42]" for an error inside the 43rd array element) — this is harder and may be deferred further.
Minimal viable version: expose the byte offset only.
API sketch
// New field on the existing error type, or a companion query function:
size_t qjd_parse_error_offset(const qjd_doc *doc);
The offset is only meaningful when qjd_parse returns QJD_PARSE_ERROR; it is SIZE_MAX otherwise.
Implementation notes
validate_brackets in src/scan/mod.rs already returns the failing usize offset; it is currently discarded.
- Store the error offset in
Document and expose it via the new FFI call.
- Update the LuaJIT wrapper to surface the offset in the error message string:
"JSON parse error at byte 1234".
- Lua busted tests: verify offset is correct for truncated input, unbalanced braces, and bare invalid bytes.
Problem
qjd_parsecurrently returns an opaqueQJD_PARSE_ERRORon malformed JSON with no position information. Callers cannot tell the user where the JSON is broken, making debugging difficult.Proposal
Extend the error surface to include:
"[42]"for an error inside the 43rd array element) — this is harder and may be deferred further.Minimal viable version: expose the byte offset only.
API sketch
The offset is only meaningful when
qjd_parsereturnsQJD_PARSE_ERROR; it isSIZE_MAXotherwise.Implementation notes
validate_bracketsinsrc/scan/mod.rsalready returns the failingusizeoffset; it is currently discarded.Documentand expose it via the new FFI call."JSON parse error at byte 1234".