Enable shrinking on recursive generators
Description
Environment
Activity
gfredericks October 7, 2017 at 3:47 PM
I think there is a messy solution to this that is just barely okay.
To shrink to the children, you need to know what they are, including their shrink trees.
One way to do this would be for recursive-gen to wrap the generator it passes to the user function in some instrumentation that keeps track of what args the generator was called with (or what its return values were), and then prepends items to the final shrink tree that attempt to shrink directly to those values first.
A minor objection to this approach is that just because the generator passed in was called, does not mean that the values generated by those calls were actually used (e.g., they could have been filtered out by such-that).
However, I think this only amounts to possible confusion in the worst case, since anything generated by the generator passed to the user function is a valid thing for the whole structure to generate. So it shouldn't be invalid to shrink to, even if it is unrelated.
gfredericks June 23, 2016 at 2:58 AM
If TCHECK-112 ends up being figured out it might apply here too.
gfredericks June 23, 2016 at 1:36 AM
I'm not 100% sure there's a clean solution to this, but note to self: shrinking to sub-trees should be the first thing we try
gfredericks June 23, 2016 at 1:25 AM
So this looks like the same issue?
Timothy Baldridge June 23, 2016 at 1:17 AM
Yes, I'm using recursive-gen.
Details
Details
Assignee
Reporter
Priority
Minor
I wrote a AST generator for a search engine using test.check. It works quite well, but for some reason recursive generators don't shrink "vertically", instead they only shrink vertically. For exmaple, let's say this AST failed:
After Shrinking
The problem is in `{:op :term}` but for some reason test.check doesn't try to remove the recursive `:and` nodes. Not a big deal, but would be a nice feature to have.