Prune parts of the data tree that have discards in them

[DRMacIver]

Key Idea: If we've discarded an example then everything below that point in the tree necessarily contains discards and thus is redundant and so we might as well prune it out of the tree, encouraging us to pursue parts of the tree that just skip out on the discarded bits altogether in future.

I've been thinking about how to do this for a while and all of the attempts I've thought about have been awful, and then ~I realised this morning that it's fairly easy to do by using the first completed discarded example as the point after which we know that going deeper into the tree is redundant.

The big big win here is on integer_range which no longer creates huge redundant sequences on small ranges that aren't a multiple of two. e.g. @given(integers(0, 2)) used to produce a lot of examples (until it hit some heuristics I hacked in to block it off in #2030) because our deduplication logic would push it deeper and deepr into the tree. Now because we mark those parts of the tree as exhausted we will only try up to twice as many valuesas the size of the range (we get arbitrarily close to twice when the range size is 2 ** n + 1).

I wanted to make use of this in weighted_coin but currently we don't use discards there and it's quite hard to change it so that it does, so I punted that for future work.

[DRMacIver]

It looks like this potentially improves our data generation quality a fair bit, as one of the reasons it's making the tests fail is that it's finding a bunch of examples that they previously didn't!

[DRMacIver]

(The failing build is for unrelated reasons that I will fix tomorrow in a separate PR. It shouldn't block reviewing this)

[Zac-HD]

LGTM 👍

[Zalathar]

I vaguely recall that there is logic in the shrunken to handle cases where removing discards doesn’t actually work.

Is that something we need to worry about here? Or is it fine to proactively prune any part of the death tree beyond a discard point?

[DRMacIver]

I vaguely recall that there is logic in the shrunken to handle cases where removing discards doesn’t actually work.
Is that something we need to worry about here? Or is it fine to proactively prune any part of the death tree beyond a discard point?

It's something I thought about and should have documented my thoughts on, but basically I think it's fine.

The failure mode is that if you filter (or use assume in a map or something) using a function with a side effect then this pruning is technically invalid. However this only causes a problem if there is no way to generate a good example without triggering a discard.

In particular note that we do not delete the discarded subtree. During shrinking we can still generate new examples in that subtree (I tried making it so we declared all examples that passed a known discard invalid, and that didn't work out so well). All the exhaustedness checks are used for is generating novel prefixes and determining whether we've done enough generation.