-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Revise capability hierarchy and fix classifiers #23656
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
I think this is ready for review now. |
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!
library/src/scala/caps/package.scala
Outdated
trait ExclusiveCapability extends Capability, Classifier | ||
|
||
@experimental | ||
type Exclusive = SharedCapability |
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.
This looks like a typo?
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.
Yes indeed.
We now always give a reason in a TypeMismatch about which capture set inclusion failed.
Include result capabilities unless they are bound in the result.
Now we also report on level and classifier errors when comparing with FreshCaps.
Make reach improvement also dependent on migthSubCapture
- fix tryClassify and trsnaClassifiers for core capabilities - freeze classifications of FreshCaps in constant sets
- two subtraits: SharedCapability and ExclusiveCapability
Pre-type closure bodies with expected result type if expected type is a parametric function. This avoids turning fresh caps in their result type into result caps
For capabilities classified as Shared, assume `cap` instead.
We now make
Capability
a sealed trait with two subtraits:SharedCapability
andExclusiveCapability
. This forces one to pick one or the other when defining a newCapability
type. Most tests were changed to useSharedCapability
instead ofCapability
. Since classifiers are now much more common than before, this showed up some bugs and anomalies for classifyer handling, which are also addressed in this PR.Details:
captureSetOfInfo
. During experimentation I found that sometimescaptureSetOfInfo
could be cached too early, leading to a locked in universal cap in the info where we would expect to see a fresh cap. On the standard library it did not look like this had a noticeable performance impact.tryClassifyAs
andtransClassifiers
. In particular, we need to distinguishFreshCap
s that can still be classified from ones that cannot. Once aFreshCap
is part of a constant capture set, it gets classified by the type that prefixes the set and that classification cannot be changed anymore. But otherFreshCap
s are created as members of variable sets and then their classification status is open and can be constrained further.cap.rd
as implicitly added capability only for references extendingExclusiveCapability
. Usecap
for the others.We also include now captures in the result type of a function in the
captureSetofInfo
of that function.