Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Regression in katrix/perspective (non-reducible Tuple type in match types) #16707

Closed
jchyb opened this issue Jan 16, 2023 · 1 comment · Fixed by #16708
Closed

Regression in katrix/perspective (non-reducible Tuple type in match types) #16707

jchyb opened this issue Jan 16, 2023 · 1 comment · Fixed by #16708
Assignees
@odersky
Labels
area:match-types area:tuples itype:bug regression This worked in a previous version but doesn't anymore
Milestone
3.3.1

Comments

@jchyb
Copy link
Contributor

jchyb commented Jan 16, 2023 •
edited
Loading

Community build

Compiler version

3.2.2-RC2 (stopped working somewhere between 3.2.0 and 3.2.1)

Minimized code

import scala.deriving.Mirror
import scala.reflect.ClassTag

transparent inline given derived[A](
      using m: Mirror.ProductOf[A],
      idClassTag: ClassTag[Tuple.Union[m.MirroredElemTypes]]
  ): Unit = ???

case class Foo(a: Int)

val instance = derived[Foo]

Output

[error] ./test.scala:16:28: No ClassTag available for Tuple.Union[m.MirroredElemTypes]
[error] 
[error] Note: a match type could not be fully reduced:
[error] 
[error]   trying to reduce  Tuple.Union[m.MirroredElemTypes]
[error]   trying to reduce  scala.Tuple.Fold[m.MirroredElemTypes, Nothing, [x, y] =>> x | y]
[error]   failed since selector  m.MirroredElemTypes
[error]   does not match  case EmptyTuple => Nothing
[error]   and cannot be shown to be disjoint from it either.
[error]   Therefore, reduction cannot advance to the remaining case
[error] 
[error]     case h *: t => h | scala.Tuple.Fold[t, Nothing, [x, y] =>> x | y]
[error] val instance = derived[Foo]
[error]

Expectation

Should compile, like it did in 3.2.0
@jchyb jchyb added itype:bug stat:needs triage Every issue needs to have an "area" and "itype" label regression This worked in a previous version but doesn't anymore labels Jan 16, 2023
@Kordyjan Kordyjan added area:match-types area:tuples and removed stat:needs triage Every issue needs to have an "area" and "itype" label labels Jan 16, 2023
@Kordyjan Kordyjan added this to the Future versions milestone Jan 16, 2023
@prolativ
Copy link
Contributor

Bisection seems to point to 8baaeae

odersky added a commit to dotty-staging/dotty that referenced this issue Jan 17, 2023
@odersky
Fix check whether classTag can be generated for match types
be2d0b4 
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 odersky mentioned this issue Jan 17, 2023
Merged
@odersky odersky self-assigned this Jan 17, 2023
odersky added a commit that referenced this issue Jan 23, 2023
@odersky
Fix check whether classtag can be generated for match types (#16708)
23febb8 
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
@Kordyjan Kordyjan modified the milestones: 3.3.0 backports, 3.3.1 Aug 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@odersky odersky

Labels
area:match-types area:tuples itype:bug regression This worked in a previous version but doesn't anymore
Projects
None yet
Milestone
3.3.1
Development

Successfully merging a pull request may close this issue.

Fix check whether classtag can be generated for match types dotty-staging/dotty
4 participants
@odersky @prolativ @Kordyjan @jchyb