-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Change/higher kinded #137
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
Change/higher kinded #137
Conversation
… abstract type. This is needed to make the encoding og higher-kinded types work. E.g. Rep[Int] would be represented as Rep { type Arg$0 = Int } # Apply where Apply is an abstract member of the base class Lambfa$I of Rep.
Adding names and definitions for the Lambda scheme to hk types. Also add HigherKinded flag for HK type parameters and abstract types.
Testing whether a type is (a subtype of) a Lambda class.
... to bring it in sync with equals.
Type members used to always pick the last refined info for a type name. This is incorrect, as a type might have several refinements for the same type name, which are not necessarily subsumed by the last one. We now only pick the last one if it is an alias type (assuming we check for conflicts elsewhere).
Make sure that Lambda Arg refinements have the same variance as the Lambda classes they instantiate. Controlled by a Config parameter.
Apply cannot be treated as a type parameter because it does not count towards the number of legal arguments in an instantiation of a higher-kinded type.
Now also works for symbols that are not class members (and returns Iterator.empty for them).
Avoid to reduce projections `A{ ... }#T` to aliases if the alias would refer to abstract members of the refinement type.
Printing a type parameter reference `A#T` now only reduces to `T` if `A` is some `B.this.type`.
In case of "types differ" failure, explain why original and retyped type are not subtypes of each other.
Refined type subtyping needs to take into account all information that was seen about members of both refined types. This is handled by storing context info in `pendingRefinedBases` and making use of this to selective rebase qualifiers when comparing refined types. Note: This commit fails in pos/collections and dotc/ast, presumably because of bad interaction between the refined subtyping and the "matchingNames" logic (which will go away).
Switch to the new scheme where higher-kinded types (and also some polymorphic type aliases) are represented as instances of Lambda traits.
1) Honor variance of Apply and $hkArgs when instantiating them 2) Eta-lifting a higher-kinded type is straight eta expansion, no arguments are applied.
Was not called when comparing a named type with an #Apply projection. The commit fixes this.
refines needs to be made more stable, so that also aliases and derefernces typevars are recognized as prefixes.
TypeVars flip from the initial state, where underlying == origin to the final state where underlying == inst. This flip can invalidate information that depends on the underlying type of a TypeVar. Since we do not know when the flip occurs, we need to avoid keeping any such information in a cache. The commit makes three caches depend on a new value: typerState.ephemeral. The value is set to `true` each time we follow the underlying type of a TypeVar, and this disables cached information to be retained. A test case for this commit is t2693.scala. This test passes typechecking with the previous commit, but fails in -Ycheck:front because of stale cache info in an "#Apply" typeref. The present commit fixes that.
Reviews by @DarkDimius @adriaanm |
|
||
/** The HigherKinded trait corresponding to symbols `boundSyms` (which are assumed | ||
* to be the type parameters of a higher-kided type). This is a class symbol that | ||
* would be generated by the following schema. | ||
* | ||
* class HigherKindedXYZ { type v_n _$hk$0; ...; type v_n _$Hk$n } | ||
* class LambdaXYZ { type v_1 Arg1; ...; type v_N ArgN; type Apply } |
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.
I think the parentTraitRefs from the implementation should be described in this comment, right?
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.
right. I'll add an explanation.
else pre.refinedInfo match { | ||
case TypeBounds(lo, hi) /*if lo eq hi*/ => hi | ||
case TypeBounds(lo, hi) if lo eq hi => | ||
if (hi.existsPart(dependsOnThis)) NoType else hi |
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.
does existsPart look at bounds?
consider class C { type X } ; P { self => type T = C { type X <: self.U }; type U } # T
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, it follows bounds in a refinement.
I had to resort to skimming due to the size. I'm also new to the codebase, so I hope my comments make (some) sense. |
Guard every occurrence of name.head with a test whether name.length > 0
Thanks for the very helpful comments, Adriaan! I add two more commits to address them. |
Avoid special treating TermRef, as this is not demanded by the comment and does not change any of the test outcomes.
Added explanations where suggested by Adriaan in his review.
Backport "Rethrow SuspendExceptions caught in CodeGen phase" to 3.3 LTS
This is the new higher-kinded scheme.