Refactoring: Capabilities as a separate type #23180
Open
+925
−932
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Note i15923 does not signal a leak anymore. I moved it and some variants to pending. Note: There seems to be something more fundamentally wrong with this test: We get an infinite recursion for variant i15923b.
There was some accidental type confusion which made every capture root type end up with cap as pathRoot and caps as pathOwner.
Split out Capability from Type. For now we keep most of the overall structure. E.g. capability handling code is in file CaptureRef.scala. We will change this afterwards in separate refactorings.
odersky
force-pushed
the
refactor-capabilities
branch
from
1b7e08c to
77bb810
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Split out Capability from Type. There is some overlap: NamedTypes, ParamRefs and ThisTypes are types as well as capabilities. But there are capabilities that are not types (root capabilities and derived capabilities such as
x.rdandy*). And there are many kinds of types that are not capabilitities.The PR does away with the encodings of derived and root capabilities as annotated types and the encoding of
capas aTermref. Both proved to be very fragile in practice, since it was easy to apply some general logic to TermRefs or AnnotatedTypes while overlooking that these need special treatment for encoded capabilities.Based on #23171. The main commit that introduces the split of capabilities from types is 1b7e08c.