The problem is that when parsing a Zon document, it is probably impossible to specify an upper bound.
This means that complex Zon documents will get errors.
A ZON document can’t contain control flow.
It is the ZON parser that do control flow.
The problem is in zon.parse.canParseTypeInner, when parsing structs and unions with the default branch quota.
In my schema, I have 3 structs and 1 union.
I think I would just give the zon document to a run step which then can be a normal program that checks / validates / transforms the zon and spits out something which is added to the build.
So basically why do you want to deal with such an unpredictable zon at comptime? (build time seems easier)
1 Like
Ah, I thought you meant you were doing @import("file.zon") at compile time, not parsing at runtime.
This proposal was accepted 2 weeks ago, which hopefully will help with reflection code that iterates over many struct fields, which from my own experience is where you most often run into annoying branch quota limits.
Comptime is used by the parser; the generated struct (in my case) is a normal struct.
The problem is that the author of the zon parser did not add a custom branch quota, in order to consider the number of fields and the number of struct/union visited.
I just meant that if you use another way to handle the zon that doesn’t use comptime (run-step using runtime zon parsing to generate something to import or direct @import) then you can’t have the branch quota problem, because then you don’t use comptime at all.
Ok, thanks.
I tried to use the zon tokenizer to change the value of a field, and it was rather simple.
The problem is with the parser/AST; I’m not sure it works.
There is a Parser in std.zon.parse, but it is not public.
The documentation says that
For lower level control over parsing, see std.zig.Zoir`.
Is this the correct way? There are no tests in std.zig.Zoir.zig`.
Thanks
I think it would make sense that you describe what you are doing more specifically:
- where/how do you get the zon
- what parts are comptime and what isn’t
- who does the parsing
- etc.
Otherwise this might be a xy problem.
I also would like this answered:
I might be missing something, because I haven’t used zon in every way imaginable, but that seems like a easy pragmatic solution to just bump the quota to some arbitrary amount that works out.
If this can’t work for some reason that would be good to know as well.
It would also be good if you could provide an example with the failing zon and the code that tries to parse it.
Is this related to this issue?
Yes, I filled the issues as bug.
There is an working code, it fails but you can try to comment some fields (the z1 - z7).
Thanks, I will try to use it so can compare the two implementations.
I thought I did recognise it. You should have pointed to that in your original post, that way @Sze would not have had to ask for some example (as that is in the codeberg issue).