Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a new check that reports an error if a Struct, Union, or Exception (
ast.Struct) exceeds a specified maximum depth.The base depth is 1 (to leave 0 as not having a specified depth from the config). If a struct has a field whose type is also a struct, the depth of the parent struct is now 2.
It can be configured with:
max: The maximum allowed depth. This is used for every node mentioned above. However, a node can specify its own allowed depth with amaxDepthannotation.allow_cycles:true: when we find a cycle, we stop the traversal and the depth up to that point is simply another candidate for the max depth of the current node that is being checked.false: errors are reported for cycles. It can also be thought of as cycles having infinite depth.Note that lists, maps (key and value separately), and sets, also count as adding 1 unit of depth. That said, it'd be very simple to adjust this, and we could even make it configurable, not only with whether they should count or not, but by how much.
There are many things that could probably be improved, with one of the big ones being the fact that right now I'm modifying things outside of the check for purposes really only needed for this check. Tried some stuff like extracting code to have different functions for different use-cases, but wasn't liking the direction that was taking.
Caching the
Parseresults brings the time from ~18s to ~1.8s in my setup when running just this check with a max depth of99999and and allowing cycles (to explore as much as possible without returning early).Tests are missing because I wanted to first discuss this with you @jparise. Though to be fair they could have helped make this more understandable.
While working on this I encountered a bunch of errors with edge-cases, and I wouldn't be surprised if there are more. Tests could also help with that.