Fix a bug in tactics preventing split of split #520
Merged
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.
The
auto
tactic attempts to prune unhelpful branches in order to avoid an exponential blowup of search space. On one these optimizations is to not build a data constructor if it doesn't result in new types to solve. For example, we're trying to avoid the following pathological example:The reasoning here is that both goals in
Branch _ _
have typeTree a
, which is already the type we're trying to solve, so introducingBranch
doesn't make any progress.This check is performed in the
splitAuto
tactic, but I got it backwards and it wasn't explicitly tested for. The only code which hit it waspure @[]
--- but because[]
doesn't have any subgoals, this hit a vacuous case and flipped the result of the bad logic. Two wrongs made a hard to find bug.This PR:
splitAuto
auto
our way through any permutation of a tuple (which is where we originally noticed the bug)unsafeRender
from crashing whenunsafeGlobalDynFlags
is unset, such as during testing.