Fix #9171: Eliminate difference _ and Any in MT #9172
Conversation
| instantiateParams(instances)(body) | ||
| case _ => | ||
| body | ||
| body.simplified |
There was a problem hiding this comment.
The added test case (with case Int => instead of case _ =>) fails to compile on master with the following:
11 | val fib2: Fib[2] = 1
| ^
| Found: (1 : Int)
| Required: LazyRef(Test2.Fib[(2 : Int) - (1 : Int)]) +
| LazyRef(Test2.Fib[(2 : Int) - (2 : Int)])That's because when match type reduction simply reduces to body without going through instantiateParams reduction would stop without trying to further simplify the body in question.
| } | ||
| def a: L[Boolean] = ??? | ||
| def b: L[Int] = ??? | ||
| // def b: L[Int] = ??? // times out |
There was a problem hiding this comment.
Why do these time out now? Isn't that a problem?
There was a problem hiding this comment.
Why do these time out now?
Because instead of stoping after one step of reduction we now try to keep reducing the match type body after the first step, which causes in infinite loop.
All the infinite loops that we encountered in match type reduction would eventually run out of stack, but this nicely trampolines and ultimately fails with an out of memory error.
This is indeed a problem, but the only solution I see would be to add some sort of reduction counter to match type reduction similar to -Xmax-inlines.
`case _ =>` use to be typed as a `HKTypeLambda`, despite not binding anything. As a result, result of match type reduction going through `case _` would get further reduce that their `case Any` counterpart. This commit eliminates this distinction with the following changes: - Eliminate this distinction in typing (type `case _ =>` *as* `case Any =>`) - Simplify the body of match types in non-binding cases - Change the match type/expression unification to treat the `case _ =>` in a pattern like `case _: Any =>` Unfortunately this change introduces a regression in `matchtype-loop.scala` where the loop suddenly turns into an infinite loop that doesn't stack overflow. I don't see any other way to nicely fail than to introduce a new fuel-like counter to keep track of match type reductions.
OlivierBlanvillain
force-pushed
the
fix-9171
branch
from
413cdf8 to
97d92ad
Compare
2 participants
case _ =>use to be typed as aHKTypeLambda, despite not binding anything. As a result, result of match type reduction going throughcase _would get further reduce that theircase Anycounterpart. This PR eliminates this distinction with the following changes:case _ =>ascase Any =>)case _ =>in a pattern likecase _: Any =>Unfortunately this change introduces a regression in
matchtype-loop.scalawhere the loop suddenly turns into an infinite loop that doesn't stack overflow. I don't see any other way to nicely fail than to introduce a new fuel-like counter to keep track of match type reductions.