Two problem with Zon parsing

Explain
1

Recently I’m implementing a indoor cycling workout, using zon for the workout program.

I tried do parse a zon document, but I used zon.parse.fromSlice instead of zon.parse.fromSlice, getting an user unfriendly error:

install
└─ install workout
   └─ compile exe workout Debug native 1 errors
/home/manlio/.local/share/sdk/zig/0.16.0/lib/std/debug.zig:420:14: error: reached unreachable code
    if (!ok) unreachable; // assertion failure
             ^~~~~~~~~~~
/home/manlio/.local/share/sdk/zig/0.16.0/lib/std/zon/parse.zig:270:20: note: called at comptime here
    comptime assert(!requiresAllocator(T));
             ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~

I think that using assert in this case is incorrect.
Why not using @compileLog? In this case it is possible to report a friendly message.

The second problem is more problematic.

I found that if the workout schema has too many fields, during build I got:

install
└─ install workout
   └─ compile exe workout Debug native 1 errors
/home/manlio/.local/share/sdk/zig/0.16.0/lib/std/zon/parse.zig:874:16: error: evaluation exceeded 1000 backwards branches
        inline for (field_found, 0..) |found, i| {
        ~~~~~~~^~~
/home/manlio/.local/share/sdk/zig/0.16.0/lib/std/zon/parse.zig:874:16: note: use @setEvalBranchQuota() to raise the branch limit from 1000

This is problematic, because the user can not change the branch quota.

Thanks

1 Like
2

Agree about first issue. And about second this proposal should fix most of problems with running out of branch quota exempt known-finite operations (`for` loops) from eval branch quota · Issue #16983 · ziglang/zig · GitHub

3

I do not think the assert is incorrect here (unless there is a bug in requiresAllocator), you should be using fromSliceAlloc if the type you are parsing contains fields that need heap allocation(s).

As for the branch quota, this error can only occur at compile time, so your comment of “the user can not change the branch quota.” does not apply.

2 Likes
4

The problem is that since the user can’t change the branch quota, there will always a possible comptime error, unless there is a fixed limit (maybe the limit can be checked against the schema) or using the exempt known-finite operations proposal.

5

I’m not sure with what you mean by “user”? Is this a library? In that case I think you as the library author should bump the eval quota to whatever you need so the library compiles. If it is an end-user, none of this applies as you would have already distributed a compiled program?

6

The code for parsing a Zon document is in the std.zon.parse.zig file, as you can see in the compiler error message I posted.

7

What is stopping you from just bumping the eval branch quota with @setEvalBranchQuota?

Zon parsing and eval quota