Closed ion232 closed 1 year ago
Wow, that's a chonker!
As the error points out, you can use @setEvalBranchQuota
to increase the amount of backwards branches the compiler can use before giving up (and erroring out). When testing the JSON payload you provided (one data object), a quota of 1800
worked for me.
I'm not sure what the best practice is for setting branch quotas in libraries, but for now I think I'll keep using the default in Getty (1000 branches). Users who work with larger types can set their own quotas. They have more insight into the types they're working with so they can set more accurate quotas. Plus, even if I did set a quota in Getty, I'm sure there'll be somebody out there who'll run into it eventually. 😅
P.S. After fixing the quota issue, I ran into an UnknownVariant
error due to Username.empty
being renamed to ""
. Pretty sure that's a bug in Getty, so I'll look into it.
Before making this issue I tried a quota of 10000, which seemed to be enough for all cases, but I did this in the library itself. I didn't realise you could set it within user code 🤔.
With regards to best practice, I've seen examples of the quota being calculated based on number of fields - e.g. https://github.com/ziglang/zig/blob/master/lib/std/fmt.zig#L532. There are also just arbitrary limits in the standard library too.
That being said, I think it would be more user-friendly to try and approximate the required quota based on the type, given this is an implementation detail that can be automated (cheaply and decideably) by the library. A somewhat analogous scenario is how a user doesn't want to try and estimate buffer sizes, they would prefer to pass an allocator that can be used by the library to get memory as needed. In this case the quota estimate might still not be enough, like you say, but would handle many more cases and save the user time from having to experiment with quotas.
The default limit is fine for now given that the user can actually change it, but I think an automated limit is worth considering for a future version.
With regards to best practice, I've seen examples of the quota being calculated based on number of fields - e.g. https://github.com/ziglang/zig/blob/master/lib/std/fmt.zig#L532.
I like that.
I'll update the struct visitor over the weekend to set a quota based on the number of fields. If everything looks good, I'll go ahead and update other spots in Getty as well.
Description
I've encountered the following error message when attempting to deserialize into a large type auto-generated from a large JSON file.
It also looks like there is an error in
src/de/impls/visitor/struct.zig:29
.How to Reproduce the Bug
Attempt to deserialize the given JSON into the given Zig type:
Zig type:
JSON (one data object only - to keep under limit)
Additional Context
No response