Regression in katrix/perspective (stack overflow with match types) #16706
Assignees
Labels
Milestone
Comments
jchyb
added
itype:bug
regression
Kordyjan
added
area:match-types
and removed
stat:needs triage
|
Bisection seems to point to #15625 |
odersky
added a commit
to dotty-staging/dotty
that referenced
this issue
Jan 17, 2023
The previous check, meant to address scala#15618, tested whether all alternatives of a match type had the same class tag and only then permitted a classtag for the match type. This was the wrong test. It did not work for recursive match types, because it could lead to stack overflow for them. And it did not take into account that match types could be reduced. A better test is to simply declare that match types themselves don't have a stable erasure, just like TypeBounds don't have a stable erasure. If we find an applied type with a match type as definition, we proceed to its translucent superytype, which will try a match type reduction. If that succeeds we produce the classtag of the redux. If not, we end up with an unreduced matchtype and refuse to generate a classtag for it. Fixes scala#16706 Fixes scala#16707
odersky
added a commit
to dotty-staging/dotty
that referenced
this issue
Jan 17, 2023
The previous check, meant to address scala#15618, tested whether all alternatives of a match type had the same class tag and only then permitted a classtag for the match type. This was the wrong test. It did not work for recursive match types, because it could lead to stack overflow for them. And it did not take into account that match types could be reduced. A better test is to simply declare that match types themselves don't have a stable erasure, just like TypeBounds don't have a stable erasure. If we find an applied type with a match type as definition, we proceed to its translucent superytype, which will try a match type reduction. If that succeeds we produce the classtag of the redux. If not, we end up with an unreduced matchtype and refuse to generate a classtag for it. Fixes scala#16706 Fixes scala#16707
odersky
added a commit
that referenced
this issue
Jan 23, 2023
The previous check, meant to address #15618, tested whether all alternatives of a match type had the same classtag and only then permitted a classtag for the match type. This was the wrong test. It did not work for recursive match types, because it could lead to stack overflow for them. And it did not take into account that match types could be reduced. A better test is to simply declare that match types themselves don't have a stable erasure, just like TypeBounds don't have a stable erasure. If we find an applied type with a match type as definition, we proceed to its translucent supertype, which will try a match type reduction. If that succeeds we produce the classtag of the redux. If not, we end up with an unreduced matchtype and refuse to generate a classtag for it. Fixes #16706 Fixes #16707
sjrd
added a commit
to sjrd/perspective
that referenced
this issue
Aug 9, 2023
We cannot use 3.3.0 because of scala/scala3#16706 but that issue is fixed in the latest RCs for 3.3.1.
sjrd
added a commit
to sjrd/perspective
that referenced
this issue
Sep 6, 2023
We cannot use 3.3.0 because of scala/scala3#16706 but that issue is fixed in 3.3.1.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Community-build
Compiler version
3.2.2-RC2 (but stopped compiling somewhere between 3.2.0 and 3.2.1)
Minimized code
Output (click arrow to expand)
Expected outcome
Should compile like it did in 3.2.0
The text was updated successfully, but these errors were encountered: