-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Array parameterized with match type causes ClassCastException at runtime #15618
Labels
Milestone
Comments
sbrunk
added
itype:bug
stat:needs triage
Every issue needs to have an "area" and "itype" label
labels
Jul 8, 2022
The erased type of |
smarter
added
area:erasure
prio:blocker
and removed
stat:needs triage
Every issue needs to have an "area" and "itype" label
labels
Jul 8, 2022
Are you sure? This issue also exists in 3.1.3 which doesn't include this PR. |
odersky
added a commit
to dotty-staging/dotty
that referenced
this issue
Jul 8, 2022
1. The erasure of an array of matchtypes should sometimes be Object instead of Object[] 2. Classtags of matchtypes can be created only if all alternatives produce the same classtag. About 1: If a matchtype with alternative types A_1, ... A_n is an array element, it should be treated in the same way as the type ? <: A_1 | ... | A_n. It's an _unknown_ subtype of A_1 | ... | A_n. That can cause the erasure of the underlying array to be Object. Fixes scala#15618
Kordyjan
pushed a commit
to dotty-staging/dotty
that referenced
this issue
Jul 26, 2022
1. The erasure of an array of matchtypes should sometimes be Object instead of Object[] 2. Classtags of matchtypes can be created only if all alternatives produce the same classtag. About 1: If a matchtype with alternative types A_1, ... A_n is an array element, it should be treated in the same way as the type ? <: A_1 | ... | A_n. It's an _unknown_ subtype of A_1 | ... | A_n. That can cause the erasure of the underlying array to be Object. Fixes scala#15618
bishabosha
pushed a commit
to dotty-staging/dotty
that referenced
this issue
Oct 18, 2022
1. The erasure of an array of matchtypes should sometimes be Object instead of Object[] 2. Classtags of matchtypes can be created only if all alternatives produce the same classtag. About 1: If a matchtype with alternative types A_1, ... A_n is an array element, it should be treated in the same way as the type ? <: A_1 | ... | A_n. It's an _unknown_ subtype of A_1 | ... | A_n. That can cause the erasure of the underlying array to be Object. Fixes scala#15618
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It looks like the array is instantiated as
Array[Any]
/Object[]
, even though i.e.ScalaType[Float32]
resolves toFloat
.Compiler version
3.1.3
Minimized code
Output
Expectation
toArray
should return anArray[Float]
The text was updated successfully, but these errors were encountered: