-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Treat local mutable vars as capabilities #24815
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
base: main
Are you sure you want to change the base?
Conversation
Move operations a bit higher up the callchain and allow for more modifications what is allowed.
When we have
var x: A^{c} = ...
where `x` is a local variable then when dereferencing `x` we also need to charge `c`.
This was forgotten before. For fields it's not a problem since `c` would already have been
charged for the prefix `p` in `p.x`.
An alternative would be to consider mutable variables to have boxed types. Then the same
capture set would be charged on unboxing.
cd61aff to
feb9b90
Compare
bracevac
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
| case self: CoreCapability => self.isTrackableRef | ||
| case _ => true | ||
|
|
||
| /** Under separatiion checking: Is this a mutable var owned by a term that is |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| /** Under separatiion checking: Is this a mutable var owned by a term that is | |
| /** Under separation checking: Is this a mutable var owned by a term that is |
| var r: Int = 0 | ||
| (() => r, (x: Int) => r = x) | ||
|
|
||
| class Struct: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The asymmetry between pairs and such a custom class is jarring.
I'm wondering if we could have a less boilerplate-y way of achieving the Struct case with standard pairs? Could we have a scoped delimiter that
says "We allow construction of data with shared components here"?
def foo() =
val r = Ref()
shared:
(() => r.get, (x: Int) => r.set(x)) // ok, nowMaking sure that the cap of the pair object subsumes the component caps?
Under separation checking: A mutable var owned by a term that is not annotated with @untrackedCaptures gives rise to a Mutable capability. Since a mutable variable is not trackable, we do this by adding a varMirror symbol to the variable which represents the capability.