Allow refinements that refine already refined types.

[odersky]

Previously, a double definition errorfor T was produced in a case like this:

 type T1 = C { T <: A }
 type T2 = T1 { T <: B }

This was caused by the way T1 was treated in the refinement class
that is used to typecheck the type. Desugaring of T2 with refinedTypeToClass
would give

 trait <refinement> extends T1 { type T <: B }

and normalizeToClassRefs would transform this to:

 trait <refinement> extends C { type T <: A; type T <: B }

Hence the double definition. The new scheme desugars the rhs of T2 to:

 trait <refinement> extends C { this: T1 => type T <: B }

which avoids the problem.

Also, added tests that #232 (fix/boundsPropagation) indeed considers all refinements
together when comparing refined types.

Supersedes #243. Review by @retronym please.

[retronym]

Was this changed intentionally from Object to Any? If so, why?

[odersky]

Yes that was intentional. It seems that Any is the more natural parent type for a purely structural type.

[retronym]

Agreed. I remember this coming up as a rough edge between value classes and structural types:

scala> trait T extends Any { def t }
defined trait T

scala> def foo(c: { def t} ) = c.t
warning: there was one feature warning; re-run with -feature for details
foo: (c: AnyRef{def t: Unit})Unit

scala> def test(t: T) = foo(t)
<console>:9: error: type mismatch;
 found   : t.type (with underlying type T)
 required: AnyRef{def t: Unit}
       def test(t: T) = foo(t)
                            ^

It would be interesting to experiment with changing this in scalac and running the community build to find out how compatible it is.

[retronym]

LGTM.

[odersky]

Yes, I think the reason for AnyRef parent for structural types is historical. Structural types came before value classes and were represented as traits. Since traits could not have an Any parent then, it was logical to pick AnyRef.