-
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
Unsoundness due to erased
#4060
Comments
In a hurry, but since #4031 is open, is
@nicolasstucki @odersky what do you think? We should probably have a chat about this. |
object App {
def coerce[U, V](u: U): V = {
trait X { type R >: U }
trait Y { type R = V }
class T[A <: X](ghost val a: A)(val value: a.R)
val a = new T[Y & X]( ??? : Y & X )(u)
a.value
}
def main(args: Array[String]): Unit = {
val x: Int = coerce[String, Int]("a")
println(x + 1)
}
} |
unused
.
OK. I suppose already isStable in Typer could recognize |
@alexknvl I renamed |
Thinking again:
|
Implemented it through isStable in SymDenotations, not Typer, since it was easier to access the flag there (as IIUC it's a flag on symbols, not types themselves). |
Fix #4060 by marking ghost symbols as unstable
Unfortunately, this makes erased vals practically useless. We should backout this fix and mark erased vals as unrealizable instead. erased is really the same as lazy in this respect. Either implies that the right-hand side will be constructed. |
Reopening given the resolution to #4031 in #5568. When applying a dependent method/function to a dependent argument object App {
trait A { type L >: Any}
//def upcast(a: A, x: Any): a.L = x
def upcast(erased a: A)(x: Any): a.L = x
//lazy val p: A { type L <: Nothing } = p
erased val p: A { type L <: Nothing } = p
def coerce(x: Any): Int = upcast(p)(x)
def main(args: Array[String]): Unit = {
println(coerce("Uh oh!"))
}
} |
Martin today suggested we might want to just require all erased arguments to be realizable, to make this simpler to implement. |
most recent example from @Blaisorblade does still compile and lead to a class cast exception |
I think we should check that all erased definitions are realizable. See |
For i11896, we now no longer allow an erased val to be of a top-level type declaration X (since it is not a concrete type, per realizability rules). `class X` is used instead. Another test, `top-level-type`, was added to check this behaviour.
For i11896, we now no longer allow an erased val to be of a top-level type declaration X (since it is not a concrete type, per realizability rules). `class X` is used instead. Another test, `top-level-type`, was added to check this behaviour. Fix some tests using top-level types for erasedValue Add parameter-only dependency case
Fix #4060. Per @odersky's [comment](#4060 (comment)), we wish to add realizability checks to all erased vals. - [x] Add realization check to erased definitions typer - [x] Add note about realizibility in the spec - [x] Add tests for #4060
Related to #50 #4042 #4031.
The text was updated successfully, but these errors were encountered: