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.

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

AntiAliasing limitation of consumed/owned mut params #154

Closed
yannbolliger opened this issue May 4, 2021 · 2 comments · Fixed by #156
Closed

AntiAliasing limitation of consumed/owned mut params #154

yannbolliger opened this issue May 4, 2021 · 2 comments · Fixed by #156
Assignees
Labels
enhancement Improvement to an existing feature imperative Feature or bug related to imperative features verification Feature or bug with the verification phase

Comments

@yannbolliger
Copy link
Collaborator

yannbolliger commented May 4, 2021

Stainless doesn't distinguish between owned objects and referenced/shared/borrowed objects, because on the JVM every object is a reference. Therefore, AntiAliasing in Stainless hinders the Rust frontend to pass such code:

#[var(field)]
struct S { field: i32 }

fn set_field(mut s: S) -> S {
  s.field = 789;
  s
} 

Which corresponds to the following in Scala (and is transformed to it by the Rust frontend's extraction). Internally, the mut s: S is translated to a LetVar at the beginning of the function:

sealed case class S((field: Int) @var)

def set_field(var0: S): S = {
  var (s: S) @var = var0
  s.field = 789
  s
}

But this is not allowed in Stainless, because Stainless can't see that the parameter var0 is consumed/owned and can be modified at will. Neither does it see that var0 is not used after the LetVar assignment. Finally, Stainless fails with Illegal Aliasing: var0.

@yannbolliger yannbolliger added enhancement Improvement to an existing feature imperative Feature or bug related to imperative features verification Feature or bug with the verification phase labels May 4, 2021
This was referenced May 4, 2021
@jad-hamza
Copy link

val s = var0 works for this one, but I don't know if that's good enough for your use case?

@yannbolliger
Copy link
Collaborator Author

Take-away from the discussion with @jad-hamza:

  • We need something that is basically like snapshot. It tells Stainless that we operate on a new copy/version of the ADT that no one else has access to. This is the same as the idea of the @owned flag, @romac suggested.
  • This primitive should be added as a tree in Stainless.
  • Functions that use the primitive on all their mutable parameters can be @pure because they only operate on the new copy of the params.
  • In the best case, this can even make it possible to set all ADT fields to @var.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Improvement to an existing feature imperative Feature or bug related to imperative features verification Feature or bug with the verification phase
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants