ZON support merged

ZON support was merged today :tada:

I’ve been keeping my eye on this PR for quite some time. Big thanks to MasonRemaley for implementing, and everyone else in the PR who contributed!

17 Likes

If you’re wondering what’s the point of this, there are a few talking points here which I’ll make sure land in the release notes, but I’ll leave you with this one:

You can directly @import .zon files, which skips parts of the compiler pipeline, potentially reducing compilation times, especially for large data sets.

For example, x86_64: use ZON for encodings by mlugg · Pull Request #22736 · ziglang/zig · GitHub

It remains to be seen whether this is true in reality, we’ll see what @mlugg reports after finishing that follow-up caching work he mentions in the linked PR.

It’s also going to be handy to @import("build.zig.zon") from build.zig scripts.

11 Likes

FWIW, my local testing without the caching in place shows negligible performance difference building the compiler with encodings.zig vs encodings.zon; it might just be that this part of the compiler is faster than we give it credit for! But I’ll update the PR with the data I get once I sort out caching. (I’m currently a few more yaks deep, but we’ll get there.)

1 Like
  1. I’d like to replace my makeshift build.zig.zon parser with the new zon support.

What’s the suitable type for this?

The PR indicates this should be possible:

const zon = @import("build.zig.zon");

which yields error: '@import' of ZON must have a known result type

I got it to work without dependencies in the zon file, but what would the type be for the dependencies field?

const zon: struct {
    name: []const u8,
    version: []const u8,
    paths: []const []const u8,
    dependencies: ???
} = @import("build.zig.zon");

my initial attempts with tuples have failed. Suggestions welcome!

  1. When using @import(“my.zon”), I noticed is that changes to the zon file (one I have in src/) does not cause recompilation, so the cached result is used. Turning the zon file into a module fixes that - this is perhaps by design?
2 Likes

Hm, that’s actually a good point – build.zig.zon has a slightly weird schema which you can’t actually model in Zig’s type system. In theory I guess it should be allowed to @import ZON without a result type (and hence infer the type like a Zig literal would) but that’s a little tricky to hook up properly with incremental etc.

I’ll try to get this implemented for 0.14.0, but no promises…

10 Likes

When using @import(“my.zon”), I noticed is that changes to the zon file (one I have in src/) does not cause recompilation, so the cached result is used. Turning the zon file into a module fixes that - this is perhaps by design?

This sounds like a bug, I’ll look into it.

[EDIT] I have a PR that fixes the caching bug here, but it probably needs review from someone familiar with how caching works to make sure it’s correct.

7 Likes

You can directly @import .zon files

Oh nice, I wanted this for my Z80 CPU emulator to describe the instruction decoding and wondered why I can’t simply import a .zon file :slight_smile: (eventually I went for a regular Zig file with functions with declarative-looking bodies)

6 Likes