summaryrefslogtreecommitdiff
path: root/test/files/pos/t4910.scala
Commit message (Collapse)AuthorAgeFilesLines
* Unify "object Foo" and "Foo.type".Paul Phillips2012-04-041-0/+6
The source of many bugs over the years is that the first is represented as a TypeRef and the second a SingleType. Over a great period of time I figured out how to shield us from the more obvious bug manifestations, but a recent comment by adriaan jarred me into realizing that we can fix it at the source. This commit changes <:< and =:= to recognize when those two representations are being compared and to treat them as equivalent regardless of which is on the left. The reason I don't quash one representation entirely is that a fair bit of code depends on singleton types having an underlying type which is not the same, and regardless of that it would entail more changes and more risk. The change allows removing the type inference conditions which worried about this, and also fixes SI-4910. scala> val t1 = typeRef(ScalaPackageClass.thisType, NoneModule.moduleClass, Nil) t1: $r.intp.global.Type = None.type scala> val t2 = t1.narrow t2: $r.intp.global.Type = None.type scala> (t1.getClass, t2.getClass) res20: (Class[?0], Class[?0]) forSome { type ?0 <: $r.intp.global.Type; type ?0 <: $r.intp.global.Type } = (class scala.reflect.internal.Types$ModuleTypeRef,class scala.reflect.internal.Types$UniqueSingleType) scala> ((t1 =:= t2, t2 =:= t1, t1 <:< t2, t2 <:< t1)) res21: (Boolean, Boolean, Boolean, Boolean) = (true,true,true,true)