Fixed TreeSet newCanBuildFrom ambiguity

Fixed ScalaCheck treeset.scala compiler error and reinstated t2030.scala
as a pos test by adding a newCanBuildFrom override in object TreeSet as
suggested in this comment on related Dotty changes,

scala/scala3#1246 (comment)

This change will be made obsolete when the new collections land.

Author: milessabin

src/library/scala/collection/immutable/TreeSet.scala

@@ -24,6 +24,7 @@ object TreeSet extends ImmutableSortedSetFactory[TreeSet] {
   implicit def implicitBuilder[A](implicit ordering: Ordering[A]): Builder[A, TreeSet[A]] = newBuilder[A](ordering)
   override def newBuilder[A](implicit ordering: Ordering[A]): Builder[A, TreeSet[A]] =
     new SetBuilder(empty[A](ordering))
+  override implicit def newCanBuildFrom[A](implicit ord : Ordering[A]) : CanBuildFrom[Coll, A, TreeSet[A]] = super.newCanBuildFrom
 
   /** The empty set of this type
    */

test/files/neg/t2030.check

@@ -0,0 +1,7 @@
+t2509-7b.scala:30: error: ambiguous implicit values:
+ both method make in object X of type => Both[X,X]
+ and method make in trait Factory of type => Both[Y,Y]
+ match expected type Both[Y,X]
+  get
+  ^
+one error found

test/files/neg/t2509-7b.check

@@ -0,0 +1,31 @@
+class Both[-A, +B]
+
+trait Factory[A] {
+  implicit def make: Both[A, A] = new Both[A, A]
+}
+
+trait X
+object X extends Factory[X] {
+  override implicit def make: Both[X, X] = super.make
+}
+
+class Y extends X
+object Y extends Factory[Y] {
+  // See test/files/pos/t2509-7a.scala ... discussion below
+  // override implicit def make: Both[Y, Y] = super.make
+}
+
+object Test {
+  def get(implicit ev: Both[Y, X]) = ev
+
+  // There are two possible implicits here: X.make and Y.make, neither are
+  // subtype of each other, so who wins?
+  // - Under the old scheme it's X.make because `isAsGood` sees that X.make is defined
+  // in X whereas Y.make is defined in Factory
+  // - Under the new scheme it's ambiguous because we replace contravariance by covariance
+  // in top-level type parameters so Y.make is treated as a subtype of X.make
+  // In both schemes we can get Y.make to win by uncommenting the override for make in Y
+  // (Y wins against X because `isDerived` also considers the subtyping relationships
+  // of companion classes)
+  get
+}

test/files/neg/t2509-7b.scala

@@ -0,0 +1,31 @@
+class Both[-A, +B]
+
+trait Factory[A] {
+  implicit def make: Both[A, A] = new Both[A, A]
+}
+
+trait X
+object X extends Factory[X] {
+  override implicit def make: Both[X, X] = super.make
+}
+
+class Y extends X
+object Y extends Factory[Y] {
+  // See test/files/neg/t2509-7b.scala ... discussion below
+  override implicit def make: Both[Y, Y] = super.make
+}
+
+object Test {
+  def get(implicit ev: Both[Y, X]) = ev
+
+  // There are two possible implicits here: X.make and Y.make, neither are
+  // subtype of each other, so who wins?
+  // - Under the old scheme it's X.make because `isAsGood` sees that X.make is defined
+  // in X whereas Y.make is defined in Factory
+  // - Under the new scheme it's ambiguous because we replace contravariance by covariance
+  // in top-level type parameters so Y.make is treated as a subtype of X.make
+  // In both schemes we can get Y.make to win by uncommenting the override for make in Y
+  // (Y wins against X because `isDerived` also considers the subtyping relationships
+  // of companion classes)
+  get
+}