Fix: std.json: Writing inf values returns InvalidJSON error

[bradcypert]

I believe this should fix #23253. First time contributor here, so please feel free to be as thorough as you'd like with feedback.

Abstract: Writing an infinite float in JSON produces the value inf which is not valid JSON. Since we can not convert an infinite value to JSON, introduce a new error type named InvalidJson and return that when attempting to write a value that can not be converted to valid JSON.

[bradcypert]

It looks like one of the errors in CI is related to this: #22107 . Anyone with more experience working on the std lib have any thoughts? I can cast the comptime floats to regular floats before the checks, but perhaps isInf is intended to also support comptime floats? I suppose I could also split the float and comptime float checks into two separate blocks in the switch, too.

[richard-powers]

#22107 (comment)
Seems it intentionally doesn't support comptime floats

[linusg]

• You'll have to update the error sets of all stringify functions, not just stringifyAlloc
• The doc comment bulletpoint Zig floats -> JSON number or string. should be updated to mention this behavior
• error.InvalidJson does not accurately describe the failure - this is serialization to JSON and the input value is invalid, not the other way around

[bradcypert]

@linusg Thank you for the feedback! I've updated the error type and split out the handling of comptime floats since they don't need the check. Additionally, I've updated the docstring comment as you suggested! I did have a question about the error return value from other functions. It looks like they're specifically returning the Error type that is defined earlier in the file. I looked at some of the other return values for all public methods and they look to be referencing that type, which I did already updated, too! Is there something else that needs to be done here?

[linusg]

It looks like they're specifically returning the Error type that is defined earlier in the file.

stringifyArbitraryDepth uses that (WriteStream(@TypeOf(out_stream), .checked_to_arbitrary_depth).Error), but stringify and stringifyMaxDepth don't (they probably should, though).

[bradcypert]

I see! Thank you for explaining that! I don't fully follow the types there, but will continue looking into it to get a better understanding of how things fit together. In the meantime, I did update the return type of those functions and the tests for that file are passing for me, so I went ahead and pushed that up! :)

Edit: I think I have a better understanding of how those types come into play and I do believe this is a more correct approach than what I had before! :)