Skip to content

Fix #3015: use type inference to type child classes #3054

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

Closed
wants to merge 2 commits into from

Conversation

liufengyun
Copy link
Contributor

Fix #3015: use type inference to type child classes

odersky added a commit to dotty-staging/dotty that referenced this pull request Sep 4, 2017
odersky added a commit to dotty-staging/dotty that referenced this pull request Sep 4, 2017
if (ref1.underlying <:< ref2.underlying) tp2.derivedSelect(ref1) else tp2
case _ => tp2
def instantiate(tp1: Type, tp2: Type)(implicit ctx: Context): Type = {
val approx = new TypeMap {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does approx do? A more telling name or a comment would help.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed, a better name is more readable.

val approx = new TypeMap {
def apply(t: Type): Type = t match {
case t @ ThisType(tref) if !tref.symbol.isStaticOwner && !tref.symbol.is(Module) =>
newTypeVar(TypeBounds.upper(mapOver(tref & tref.givenSelfType)))
Copy link
Contributor

@odersky odersky Sep 4, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you want

newTypeVar(TypeBounds.upper(mapOver(t.underlying)))

here. That achieves what was written in simpler form. But why upper? Without an explanation it's hard to know whether it is correct. But it feels dangerous because the ThisType might appear at negative variance positions as well. How do you argue that the bound should not be changed in this case?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The argument here is that the child type created from childSym.typeRef can only be of the shape path.Child, thus the ThisType is always covariant.

if (protoTp1 <:< tp2 && isFullyDefined(protoTp1, ForceDegree.all)) protoTp1
else {
debug.println(s"$protoTp1 <:< $tp2 = false")
NoType
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Neat that this works! We might want to move it to something more generally available since it looks like the Linker will need something like this was well /cc @nicolasstucki. @DarkDimius

@odersky
Copy link
Contributor

odersky commented Sep 4, 2017

Can you rebase this PR on top of #3033? That would be the real test that exhaustiuveness checking is no longer tied to the particularities of how we encode applied types. I tried but got failures.

@liufengyun
Copy link
Contributor Author

test performance please

@dottybot
Copy link
Member

dottybot commented Sep 4, 2017

performance test scheduled: 1 jobs in total.

@liufengyun liufengyun mentioned this pull request Sep 4, 2017
@dottybot
Copy link
Member

dottybot commented Sep 4, 2017

Performance test finished successfully:

Visit http://dotty-bench.epfl.ch/3054 to see the changes.

Benchmarks for this PR is based on the merge of this PR (5ab6c36) with master

liufengyun pushed a commit to dotty-staging/dotty that referenced this pull request Sep 6, 2017
odersky added a commit to dotty-staging/dotty that referenced this pull request Sep 6, 2017
odersky added a commit to dotty-staging/dotty that referenced this pull request Sep 8, 2017
odersky added a commit to dotty-staging/dotty that referenced this pull request Sep 14, 2017
odersky added a commit to dotty-staging/dotty that referenced this pull request Sep 17, 2017
odersky added a commit to dotty-staging/dotty that referenced this pull request Sep 20, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants