Describe the bug
eigs_json_lint_allow_for (src/lint.c:3228) calls eigs_json_parse_value directly without clearing g_json_parse_err first, so it is a seventh lenient JSON parse root beyond the six named in #777. When the flag is already set from an earlier parse in the same thread, the lint allow-list document decodes to an empty dict and warning suppression silently stops applying — the lint then emits warnings the allow-list was configured to suppress.
Surfaced while doing #777, whose fix routes the six entry points you named through eigs_json_parse_root. That leaves this one unmigrated; it neither caused nor fixes this.
Scope, stated up front because it matters: this is not reachable through any shipped binary. --lint handles one file per process with no JSON parse before it, and the LSP path goes through lint_collect rather than this function. It affects embedders and in-process callers that use the public C API and parse JSON before linting in the same thread. Line resolved against main @ e17f936.
To reproduce
There is no .eigs-level reproducer, for the scope reason above — the trigger requires two parses in one process, which the CLI never does. From an embedder over the public C API:
- Lint a file with an allow-list that suppresses a warning, and confirm it reports
no issues found (rc=0).
- In the same thread, call the public
eigs_json_parse_value on a malformed document, leaving g_json_parse_err set.
- Lint the same file again with the same allow-list.
Expected behavior
Step 3 behaves identically to step 1 — the allow-list still decodes and still suppresses, because a fresh parse should not inherit error state from an unrelated earlier one.
Actual behavior
Step 3 emits warning[W001] and exits rc=1. The well-formed allow-list document decodes to an empty dict, so every entry in it is silently dropped.
Environment
- OS: Debian 13 (x86_64)
- GCC version: 14
- EigenScript version: 0.34.0 (
main @ e17f936)
Describe the bug
eigs_json_lint_allow_for(src/lint.c:3228) callseigs_json_parse_valuedirectly without clearingg_json_parse_errfirst, so it is a seventh lenient JSON parse root beyond the six named in #777. When the flag is already set from an earlier parse in the same thread, the lint allow-list document decodes to an empty dict and warning suppression silently stops applying — the lint then emits warnings the allow-list was configured to suppress.Surfaced while doing #777, whose fix routes the six entry points you named through
eigs_json_parse_root. That leaves this one unmigrated; it neither caused nor fixes this.Scope, stated up front because it matters: this is not reachable through any shipped binary.
--linthandles one file per process with no JSON parse before it, and the LSP path goes throughlint_collectrather than this function. It affects embedders and in-process callers that use the public C API and parse JSON before linting in the same thread. Line resolved againstmain@e17f936.To reproduce
There is no
.eigs-level reproducer, for the scope reason above — the trigger requires two parses in one process, which the CLI never does. From an embedder over the public C API:no issues found(rc=0).eigs_json_parse_valueon a malformed document, leavingg_json_parse_errset.Expected behavior
Step 3 behaves identically to step 1 — the allow-list still decodes and still suppresses, because a fresh parse should not inherit error state from an unrelated earlier one.
Actual behavior
Step 3 emits
warning[W001]and exits rc=1. The well-formed allow-list document decodes to an empty dict, so every entry in it is silently dropped.Environment
main@e17f936)