summaryrefslogtreecommitdiff
path: root/test/files/pos/spec-params-new.scala
diff options
context:
space:
mode:
authorAleksandar Prokopec <axel22@gmail.com>2012-06-19 19:54:02 +0200
committerAleksandar Prokopec <aleksandar.prokopec@gmail.com>2012-06-21 01:05:43 +0200
commitb29c01b710b67dd329ad418c7d5ef4e61845c6d1 (patch)
treeff393138b123a02e3023a14d2cfbd11a6e7203cb /test/files/pos/spec-params-new.scala
parent16f53506e289ae0b9b97537e01de8fdc985ee4bf (diff)
downloadscala-b29c01b710b67dd329ad418c7d5ef4e61845c6d1.tar.gz
scala-b29c01b710b67dd329ad418c7d5ef4e61845c6d1.tar.bz2
scala-b29c01b710b67dd329ad418c7d5ef4e61845c6d1.zip
Fix SI-5284.
The problem was the false assumption that methods specialized on their type parameter, such as this one: class Foo[@spec(Int) T](val x: T) { def bar[@spec(Int) S >: T](f: S => S) = f(x) } have their normalized versions (`bar$mIc$sp`) never called from the base specialization class `Foo`. This meant that the implementation of `bar$mIc$sp` in `Foo` simply threw an exception. This assumption is not true, however. See this: object Baz { def apply[T]() = new Foo[T] } Calling `Baz.apply[Int]()` will create an instance of the base specialization class `Foo` at `Int`. Calling `bar` on this instance will be rewritten by specialization to calling `bar$mIc$sp`, hence the error. So, we have to emit a valid implementation for `bar`, obviously. Problem is, such an implementation would have conflicting type bounds in the base specialization class `Foo`, since we don't know if `T` is a subtype of `S = Int`. In other words, we cannot emit: def bar$mIc$sp(f: Int => Int) = f(x) // x: T without typechecking errors. However, notice that the bounds are valid if and only if `T = Int`. In the same time, invocations of `bar$mIc$sp` will only be emitted in callsites where the type bounds hold. This means we can cast the expressions in method applications to the required specialized type bound. The following changes have been made: 1) The decision of whether or not to create a normalized version of the specialized method is not done on the `conflicting` relation anymore. Instead, it's done based on the `satisfiable` relation, which is true if there is possibly an instantiation of the type parameters where the bounds hold. 2) The `satisfiable` method has a new variant called `satisfiableConstraints`, which does unification to figure out how the type parameters should be instantiated in order to satisfy the bounds. 3) The `Duplicators` are changed to transform a tree using the `castType` method which just returns the tree by default. In specialization, the `castType` in `Duplicators` is overridden, and uses a map from type parameters to types. This map is obtained by `satisfiableConstraints` from 2). If the type of the expression is not equal to the expected type, and this map contains a mapping to the expected type, then the tree is cast, as discussed above. Additional tests added. Review by @dragos Review by @VladUreche Conflicts: src/compiler/scala/tools/nsc/transform/SpecializeTypes.scala src/compiler/scala/tools/nsc/typechecker/Duplicators.scala
Diffstat (limited to 'test/files/pos/spec-params-new.scala')
-rw-r--r--test/files/pos/spec-params-new.scala2
1 files changed, 1 insertions, 1 deletions
diff --git a/test/files/pos/spec-params-new.scala b/test/files/pos/spec-params-new.scala
index 661e686f0e..959ce1591c 100644
--- a/test/files/pos/spec-params-new.scala
+++ b/test/files/pos/spec-params-new.scala
@@ -31,4 +31,4 @@ class Foo[@specialized A: ClassTag] {
val xs = new Array[A](1)
xs(0) = x
}
-} \ No newline at end of file
+}