Skip to content

Unexpected ClassCastException #19752

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

Closed
Bersier opened this issue Feb 21, 2024 · 3 comments
Closed

Unexpected ClassCastException #19752

Bersier opened this issue Feb 21, 2024 · 3 comments
Labels
itype:bug itype:soundness Soundness bug (it lets us compile code that crashes at runtime with a ClassCastException) stat:fixed in next The issue was fixed in Next and only still applies to LTS.

Comments

@Bersier
Copy link
Contributor

Bersier commented Feb 21, 2024

Compiler version

3.3.2

Minimized code

dependentlyTypedMod2(Succ(Succ(Succ(Zero()))))

def dependentlyTypedMod2[N <: NatT](n: N): Mod2[N] = n match
  case Zero(): Zero => Zero()
  case Succ(Zero()): Succ[Zero] => Succ(Zero())
  case Succ(Succ(predPredN)): Succ[Succ[?]] => dependentlyTypedMod2(predPredN)

type Mod2[N <: NatT] <: NatT = N match
  case Zero => Zero
  case Succ[Zero] => Succ[Zero]
  case Succ[Succ[predPredN]] => Mod2[predPredN]

sealed trait NatT
case class Zero() extends NatT
case class Succ[N <: NatT](n: N) extends NatT

Output

java.lang.ClassCastException: class Succ cannot be cast to class Zero

Expectation

Succ(Zero())

See this issue.

@Bersier Bersier added itype:bug stat:needs triage Every issue needs to have an "area" and "itype" label labels Feb 21, 2024
@sjrd
Copy link
Member

sjrd commented Feb 21, 2024

This already does not compile on 3.4.0 anymore.

@sjrd sjrd closed this as completed Feb 21, 2024
@Bersier
Copy link
Contributor Author

Bersier commented Feb 21, 2024

@sjrd 3.3 is an LTS.

Also, how would you express this without the ascriptions?

@sjrd
Copy link
Member

sjrd commented Feb 21, 2024

@sjrd 3.3 is an LTS.

True. We can reopen. Although not sure anyone's going to work on this since match types before SIP-56 have been demonstrated to be unsound and depending on the whims of type inference.

Also, how would you express this without the ascriptions?

I don't know about that. I haven't looked into it.

@sjrd sjrd reopened this Feb 21, 2024
@sjrd sjrd added the stat:fixed in next The issue was fixed in Next and only still applies to LTS. label Feb 21, 2024
@dwijnand dwijnand added itype:soundness Soundness bug (it lets us compile code that crashes at runtime with a ClassCastException) and removed stat:needs triage Every issue needs to have an "area" and "itype" label labels Feb 21, 2024
@Bersier Bersier closed this as completed Sep 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
itype:bug itype:soundness Soundness bug (it lets us compile code that crashes at runtime with a ClassCastException) stat:fixed in next The issue was fixed in Next and only still applies to LTS.
Projects
None yet
Development

No branches or pull requests

3 participants