Output zig targets as ZON instead of JSON

[MasonRemaley]

As well as outputting ZON instead of JSON, this PR:

• Adds a few convenience functions to stringify to make this nicer
• Renames start*/finish* to begin*/end* in stringify
  • This is more consistent with the JSON API, and with other APIs out in the wild that follow this pattern
  • I didn't mark the old names as deprecated since they were live for such a short period, let me know if I should

I verified the output by diffing it with the JSON and glancing over it, and checking that it parses as ZON with the runtime parser.

The compile time parser on #22907 crashes on it right now, this is a bug there looking into it on that branch. (fixed)

[alexrp]

I guess this makes sense, though I'll be a little sad to see zig targets | jq -r .libc[] go... anyone want to implement zq real quick?

[MasonRemaley]

Hmm. If this reduces the utility of zig targets, it might make sense to wait--alternatively maybe it's good motivation for more tooling to be developed. I don't personally feel strongly either way.

(The changes to stringify.zig should probably make it in for 0.14 regardless, if we decide not to make this change I'm happy to pull them out.)

[Rexicon226]

Why not just have both? Put json behind a --json flag.

[tensorush]

I'll be a little sad to see zig targets | jq -r .libc[] go... anyone want to implement zq real quick?

Implemented very basic querying: https://codeberg.org/tensorush/zq

Examples (when run in zq repo):

$ zig build exe -- -f build.zig.zon .name
"zq"

$ cat build.zig.zon | zig build exe -- .dependencies.clap
.url = "git+https://github.com/Hejsil/zig-clap#e730233775300c0a8fe3137af880c7c58340930f"
.hash = "12205ef27929fba18101750677ff579c0b6aff670755cacbbe6f2bc5f073622e1783"

zig targets would potentially work like this:

zig targets | zq .libc

UPD: I decided to preserve original ZON value formatting, in order to tell values apart (e.g. enum_literal and string -> .enum_literal and "string"). And also it now prints struct literals' immediate values.

[MasonRemaley]

@tensorush nice, this looks very useful!

[perillo]

What is the rationale for using ZON instead of JSON?

Thanks.

[MatthiasPortzel]

This change grates on me for two reasons. As mentioned, this is a breaking change with no rational, other than "Not invented here."

But second, because JSON is valuable as a data interoperability format. Even if ZON is suitable for serialization and deserialization, and even if it's nicer to work with from the perspective of the Zig programmer, I don't see it ever competing with JSON as a ubiquitous data exchange language. And I didn't think that was a goal. For programmatic output that is meant to be consumed by other tools, it makes sense to use a data format that is easy for those tools to understand.

Edit: This is a drive-by critical comment in an unimportant part of the compiler, so I just want to also say thanks to the Zig team for their work towards 0.14 and thanks to @MasonRemaley for their work on ZON.

[andrewrk]

The rationale is to promote zon as a data interchange format.

It's also nice to remove json dependency from the compiler.