Issue #1163: std: a JSON reader for tools (cargo JSON, comptime artifacts)

Open and answer this issue on GitHub.

ready · opened 2026-11-02 · updated 2026-11-03 · 1 comment

Found while moving comptime_run and diagnostics into Nikaia (Part of #125): artifacts_in (comptime) and the cargo --message-format=json reading in diagnostics parse JSON with serde. Nikaia’s std has no JSON reader, so both stay in Rust.

Supervisor decision (obvious by the principles: a library module written in Nikaia, no language change): a small JSON reader in std, written in Nikaia, returning a tree value (object, array, string, number, bool, null) with errors as values.

To build

1. std json: parse text into a tree value; object fields in source order; errors carry the byte offset.
2. tests/compiler tests: a nested document, an error case.
3. Then move artifacts_in (comptime) and the cargo JSON reading (diagnostics).

Comments

keywan-ghadami, 2026-11-02

Decision needed: where the tools’ JSON reader lives

While building this issue we found a naming collision.

User programs already reach the official json package (Part III 13, ADR-344, packages/json) as json::. A std::json module in the prelude would give json::parse two meanings. For the same reason lib.rs names its module http1 rather than http.

Without the prelude entry it fails too: use std::json lowers to a comment, and rustc then stops with “Cannot find module json”.

What exists already: the reader is written in Nikaia and runs. It handles byte offsets and surrogate pairs and has a depth limit of 512. It is on the local branch wip/b1163-json, not pushed, with its lib.rs entry, contracts and two tests that still lack .stdout files.

Options

1. A std-internal module under another name, for example std::tools::json_read. Only the compiler’s tools see it, and it is kept out of the prelude. This is quick, but it means a second JSON reader next to packages/json.
2. The tools use packages/json. Then there is one reader, in one place. This requires tools/*.nika to be able to depend on a package, which the lowering does not support yet.
3. Rename the std module publicly, for example std::jsonread. This adds a second public meaning beside the package, which works against “one meaning per word”.

Recommendation: option 2 for the long run, with option 1 as an interim step. The interim module would stay out of the prelude and be marked to be replaced once tools can depend on packages.

Blocks: moving artifacts_in and waited out of process.rs. #1177 is done separately as 3fd009e1 (pushed).

---

Generated by Claude Code

Back to Open Issues