Fix #9000: Avoid spurious cyclic errors for toplevel matches #9001
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.
I still don't know why the match type
compiled OK if it appeared in a user defined object, but failed with a cyclic
reference when written on the top level. But the logic for cyclic detection was
clearly very fragile, and unadapted to the case at hand. Essentially, it's a
type map that inserts LazyRefs when it detects legal cycles. The problem is that
these insertions cause recomputations of applied types in the TypeMap. And these
fail since the type constructor (A2B in this case) has not yet been completed.
So after a LazyRef was inserted, the cycle checker fails again in an unrecoverable
way because it tries to get the type parameters of an uncompleted type constructor.
So the question would be rather - why did this work if the match type appears in
a user-defined object? I could not answer that question, but I could fix the logic
to handle these cases.