Increase the maximum parsing depth for parsing JSON to 10000

[itchyny]

This is the same limit as encoding/json in Go and should be sufficient for most use cases.
Closes #2846, closes #3158, and addresses #1214.

[thaliaarchi]

Have you seen #3063 (Make maximum depth configurable via CLI option)?

[itchyny]

Of course. But it's better if you can use for most use cases without having to worry about the depth option.

[wader]

Looked up the original issue where @mgree ran into the limit, seems to have been querying some deeply nested AST #3063 (comment), but didn't find what limit would have worked in this case. I think it's a good idea to increase the default limit as a start, an option to change it could be done separately later.

[itchyny]

Thanks. We could reconsider whether we really need option if the limit is 10000.

[liquidaty]

Appreciate the update, thank you. FWIW it is not always better to have a fixed-but-high limit vs a configurable limit. If I'm processing a very large JSON input that should never have a depth > N, I certainly have many use cases where I'd rather quickly disqualify the invalid input than continue to process it.

That said, I agree that enforcing a configurable limit is merely a nice-to-have (esp compared to raising a hardcoded limit that is too low)

[mgree]

I could find out what depth would have worked if that would help the PR get merged, but the key thing for us would be the option to turn off the maximum depth, since our JSON is homemade.

(Let me know if it's worth resolving the merge skew on #3063. If it won't help it get merged, though, I won't bother.)

[itchyny]

I don't understand why many people think limiting the depth is enough to prevent invalid or huge input. Why you don't need to limit the number of elements in arrays and objects, or string literal length.

[liquidaty]

Just because it does not comprehensively address the entire problem space by itself does not make it worthless.

[mgree]

I don't know if you're including my use case in "many people", but our AST-parsing use case requires no depth limit, not a fixed one. Changes like this one aren't (in general) going to solve our problem.