Skip to content

More tests #1006

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

Merged
merged 22 commits into from
Dec 26, 2015
Merged

More tests #1006

merged 22 commits into from
Dec 26, 2015

Conversation

odersky
Copy link
Contributor

@odersky odersky commented Dec 20, 2015

Lots of new tests and some fixes. Review by @smarter

As the comment explains, this is not sound.
The fix solves two cases where we had a deep subtype before.
Since And/Or type themselves are parameterless, their
the union and intersection of hgiher-kinded types has to be treated
specially: The types have to be pulled under a common lambda.
If splitProjections is set, it is more efficient that way.
All pos tests up to 3999 have been triaged. One new test in pending.
Symbols can appear in patterns, so inserting an `apply` is wrong.
revios fix crashed for nullary functions
In a situation like

    List <: [X] -> <: GenTraversable[X]

We have to ask whether the rhs contains the instantiated lhs,
not whether it is a supertype.
@odersky
Copy link
Contributor Author

odersky commented Dec 20, 2015

This one is based on #1001, which should go in first.

@smarter
Copy link
Member

smarter commented Dec 20, 2015

/rebuild

@smarter
Copy link
Member

smarter commented Dec 20, 2015

Something weird is going on with constraints, in:

class A {
  def f[CC[X] <: Traversable[X]](x: CC[Int]): CC[Int] = x

  f(1 to 5)
}

we get:

[info] added constraint CC <: [+X0] -> scala.collection.immutable.IndexedSeq[X0] to
[info] Constraint(
[info]  uninstVars = CC;
[info]  constrained types = 
[info]   [CC <: [X0] ->  <: scala.collection.Traversable[X0]](x: CC[Int])CC[Int]
[info]  bounds = 
[info]      CC = [+X0] -> scala.collection.immutable.IndexedSeq[X0]
[info]  ordering = 
[info] ) = true
[error] [log frontend]           ==> adapting intWrapper(1).to of type ((end: Int)scala.collection.immutable.Range.Inclusive)(scala.runtime.RichInt#to) to FunProto(5):??
[error] [log frontend]           <== adapting intWrapper(1).to of type ((end: Int)scala.collection.immutable.Range.Inclusive)(scala.runtime.RichInt#to) to FunProto(5):? = intWrapper(1).to
[error] [log frontend]         <== adapting intWrapper(1).to of type <overloaded scala.runtime.RichInt#to> to FunProto(5):? = intWrapper(1).to
[error] [log frontend]       <== typing 1.to = intWrapper(1).to
[error] [log frontend]       ==> adapting 5 of type Int(5) to Int?
[error] [log frontend]       <== adapting 5 of type Int(5) to Int = 5
[error] [log frontend]       ==> adapting intWrapper(1).to(5) of type scala.collection.immutable.Range.Inclusive to CC[Int]?
[error] [log frontend]       <== adapting intWrapper(1).to(5) of type scala.collection.immutable.Range.Inclusive to CC[Int] = intWrapper(1).to(5)
[error] [log frontend]       ==> adapting this.f[CC](intWrapper(1).to(5)) of type CC[Int] to ??
[info] interpolate undet vars in CC[Int], pos = [71..72..80], mode = Mode(ImplicitsEnabled), undets = ArrayBuffer(CC@[71..72])
[info] qualifying undet vars: ArrayBuffer(TypeVar(PolyParam(CC)) / CC), constraint: Constraint(
[info]  uninstVars = CC;
[info]  constrained types = 
[info]   [CC <: [X0] ->  <: scala.collection.Traversable[X0]](x: CC[Int])CC[Int]
[info]  bounds = 
[info]      CC <: [X0] ->  <: scala.collection.Traversable[X0]
[info]  ordering = 
[info] )
[info] interpolate covariant CC in CC[Int]
[info] approx CC, from below = true, bound = Nothing, inst = Nothing
[info] instantiating CC with Nothing

Notice that we correctly have CC = [+X0] -> scala.collection.immutable.IndexedSeq[X0] in the constraint set, but then somehow we go back to CC <: [X0] -> <: scala.collection.Traversable[X0] and we infer CC to Nothing.

@odersky
Copy link
Contributor Author

odersky commented Dec 21, 2015

@smarter

Something weird is going on with constraints, in: ...

Where did that test come from? The example compiles OK for me (?)

@smarter @DarkDimius I cannot make sense of the test failures of this commit. It says something about compilation of pos/printing_v1fails, but I have no idea what that is. Can you help?

@smarter
Copy link
Member

smarter commented Dec 21, 2015

Where did that test come from? The example compiles OK for me (?)

I took hkrange.scala and changed it slightly. It does compile OK, the issue is that it infers Nothing instead of inferring [X] => IndexedSeq[X] for the call f(1 to 5).

@smarter @DarkDimius I cannot make sense of the test failures of this commit. It says something about compilation of pos/printing_v1fails, but I have no idea what that is. Can you help?

Not sure what the problem is either, I suspect it might be another kind of random bug that disappear when we rebuild.

@smarter
Copy link
Member

smarter commented Dec 21, 2015

/rebuild

@smarter
Copy link
Member

smarter commented Dec 26, 2015

LGTM since the issues I encountered are not specific to this PR, I'll investigate them separately

smarter added a commit that referenced this pull request Dec 26, 2015
@smarter smarter merged commit 2427f05 into scala:master Dec 26, 2015
@allanrenucci allanrenucci deleted the more-tests branch December 14, 2017 19:24
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.

3 participants