[Do not merge] Aborted Experiment: Native AppliedType #2947
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
Bonus point: No need to override applyPrefix in variances accumulator. This means we have reduced three different ways to compute the current variance to one.
Need to keep cycle breakers
Same principle as reading from Scala2 pickles applied = in the face of F-bounded polymorphism we cannot assume that the type parameters are known when we unpickle a type application.
This avoids memory leaks in unpicklers, where lazy refs don't capture the context anymore. Other lazyrefs still need to capture context, though.
AppliedType will be used for all type applications, higher-kinded or not. That is, eventually, it will replace HKApply and also the encodings of type applications as refined types. This commit introduces AppliedType and adapts baseType computations to take it into account. AppliedType is not yet constructed anywhere, however.
So far, everything up to parents is adapted to new scheme. Parents is half done; needs more work once we change layour of ClassInfo.
Simplifies usage and removes some obscure code in Types
Systematically introduce handlers for AppliedTypes where there was a handler for HKApply.
Also, change asSeenFrom to use it for arguments
The previous type parameter representation in terms of type members achieved bounds propagation by waiting until a type member was selected and then taking original bounds and refinements together as its info. This no longer works with explicit applications. Instead, we need to propagate bounds into wildcard arguments explicitly, when a type application is created.
|
Closed for the reasons given in the PR. |
odersky
added a commit
to dotty-staging/dotty
that referenced
this pull request
Aug 10, 2017
The test case shows that it is inadmissible to combine the infos of inherited denotations into a new denotation. The problem here is that a type parameter CC was instantiated in an inherited denotation to Traversable, yet the parameter was afterwards instantiated to ListBuffer. This shows that infos from inheroted denotations are useless; instead we have to go back to the inherited symbol's infos and map them with an asSeenFrom. This fix also shows that one of the reasons for abandoning scala#2947 was wrong. We cannot form denotations from parent denotations in any case, so instantiating early should be fine with the change in this commit.
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.
A more developed version of #2898.
In the end I did not go ahead with this. Here's a summary why:
First, there are other parts of the compiler that rely on the refinement encoding in interesting ways. In particular, the way we compute findMember relies on the fact that the member type
of
xin classCis a function of the member types ofxin the parent classes ofC. This is no longer true when we instantiate arguments immediately. To pick an example from collections: The type oftoCollectionhas the formwhere
Repris a parameter to all collections. If we see that type from a specificcollection
scwe get(x: sc.Repr)T. The inherited types oftoCollectionareall of the form
(x: P.this.Repr)TwherePis a parent class. The specific collectiontype is obtained by joining the patent types with
&after replacingP.thiswithsc.type.But if we expand parameters with arguments we get
(x: P)Tfor the parent types instead. And there is no safe operation which will allow us to recover(x: SC)Tfrom that.Second, there's the problem of bounds propagation (see
bounds-propagation.scalatest case).Those two problems can be solved by having a mixed scheme where we keep type parameters as members, but make them private and have special types that refer to them instead. But that brings back part of the complexity of the refinement type scheme.
The decisive reason to drop is elsewhere: The Linker relies on being able to refine any parameter bounds in a class or all its base classes retro-actively through refinements. If parameters are no longer instantiated through refinements, this will not work anymore. So if we want to keep the
option of a fast and precise control-flow analysis, we need to keep parameters as refinements.