-
Notifications
You must be signed in to change notification settings - Fork 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
Unsound application of boxed functions #15749
Comments
There's something wrong with the Before it was not a problem since we did not apply this reasoning to selections, so the type of |
Ah, so this simplified snippet reveals a problem different from the original one in #15731 (since the list in that example is church-encoded and no selection is involved). |
I tweaked the snippet a bit (defining the wrapper in church-style) and found this (which is closer to the original list encoding example and seems to reveal the same problem): class Unit
object unit extends Unit
type Top = {*} Any
type Wrapper[T] = [X] -> (op: T => X) -> X
def wrapper[T](x: T) = [X] => (op: T => X) => op(x)
def strictMap[A <: Top, B <: Top](mx: Wrapper[A])(f: A => B): Wrapper[B] =
mx((x: A) => wrapper(f(x)))
def force[A](thunk: Unit => A): A = thunk(unit)
def forceWrapper[A](mx: Wrapper[Unit => A]): Wrapper[A] =
// Γ ⊢ mx: Wrapper[□ {*} Unit => A]
// `force` should be typed as ∀(□ {*} Unit -> A) A, but it can not
strictMap[{*} Unit -> A, A](mx)(force) I am unfamiliar with how capture checker works yet, but it seems that when supplying |
1. Update info of TypeDef symbols to account for boxing. Previously, the changes were made to the tree, but were not propagated to the symbol. 2. Maintain alias types when adding boxes. 3. Don't accidentally widen in addResultBoxes. The boxmap pos test started failing after (1), (2) before the fix (3) was added. Fixes scala#15749
1. Update info of TypeDef symbols to account for boxing. Previously, the changes were made to the tree, but were not propagated to the symbol. 2. Maintain alias types when adding boxes. 3. Don't accidentally widen in addResultBoxes. The boxmap pos test started failing after (1), (2) before the fix (3) was added. Fixes scala#15749
@Linyxus Where do you think this latest example should issue an error? |
Maybe we should issue an error when applying |
@Linyxus Yes, I think that makes sense. |
1. Update info of TypeDef symbols to account for boxing. Previously, the changes were made to the tree, but were not propagated to the symbol. 2. Maintain alias types when adding boxes. 3. Don't accidentally widen in addResultBoxes. The boxmap pos test started failing after (1), (2) before the fix (3) was added. Fixes scala#15749
1. Update info of TypeDef symbols to account for boxing. Previously, the changes were made to the tree, but were not propagated to the symbol. 2. Maintain alias types when adding boxes. 3. Don't accidentally widen in addResultBoxes. The boxmap pos test started failing after (1), (2) before the fix (3) was added. Fixes #15749
Compiler version
3.1.3-RC4
Minimized code
Output
The code compiles but it shouldn't.
Expectation
This code is minimised from Ondrej's list encoding example (in #15731). In
force
, the functionv.x
is a boxed function of type□ {*} Unit -> A
, so we should not allow the applicationv.x(unit)
since we can not unbox it.This leads to the leaking of scoped capabilities, for example:
The text was updated successfully, but these errors were encountered: