summaryrefslogtreecommitdiff
path: root/test/files/specialized
diff options
context:
space:
mode:
authorVlad Ureche <vlad.ureche@gmail.com>2013-06-14 15:01:37 +0200
committerVlad Ureche <vlad.ureche@gmail.com>2013-06-28 01:54:52 +0200
commit32163215b183883f5c37ae0fd3342a4ae93a0090 (patch)
tree16ddf1df3488aea70d80032b65c509ece1c1cd65 /test/files/specialized
parentb5f70c844c77ac974118d07a9d53e3fd98a69e5f (diff)
downloadscala-32163215b183883f5c37ae0fd3342a4ae93a0090.tar.gz
scala-32163215b183883f5c37ae0fd3342a4ae93a0090.tar.bz2
scala-32163215b183883f5c37ae0fd3342a4ae93a0090.zip
SI-7344 Specialize methods in private scopes
This performs method specialization inside a scope other than a {class, trait, object}: could be another method or a value. This specialization is much simpler, since there is no need to record the new members in the class signature, their signatures are only visible locally. It works according to the usual logic: - we use normalizeMember to create the specialized symbols - we leave DefDef stubs in the tree that are later filled in by tree duplication and adaptation The solution is limited by SI-7579: since the duplicator loses the sym annotations when duplicating, this expansion and rewiring can only take place in code that has not been subject to duplication. You can see the test case for an example. Review by @dragos, @paulp or @axel22.
Diffstat (limited to 'test/files/specialized')
-rw-r--r--test/files/specialized/SI-7344.scala53
1 files changed, 53 insertions, 0 deletions
diff --git a/test/files/specialized/SI-7344.scala b/test/files/specialized/SI-7344.scala
new file mode 100644
index 0000000000..1040460bd1
--- /dev/null
+++ b/test/files/specialized/SI-7344.scala
@@ -0,0 +1,53 @@
+/* Test for SI-7344, where specialized methods inside the bodies of other
+ * methods are not specialized, although they might as well be. The name
+ * for the specialized method should not be different depending on the
+ * outside method/class' specialization. */
+
+class Test[@specialized(Int, Double) X](val x: X) {
+
+ def checkSpecialization[Y](@specialized(Int, Double) y: Y): X = {
+
+ // checking the specialization using the method name, which we can
+ // extract from an exception's stack trace. We can match just the
+ // prefix, since the compiler will add a suffix to the method name
+ // during lambdalift, when it lifts the local methods outside.
+ def specMe[@specialized(Int, Double) T, N](t: T, n: N): Unit = checkNameStartsWith(n.toString)
+
+ // expected to specialize:
+ specMe("x", "specMe")
+ specMe(123, "specMe$mIc$sp")
+ specMe(1.3, new { override def toString = "specMe$mDc$sp" })
+
+ x
+ }
+
+ // name matching:
+ private[this] def checkNameStartsWith(prefix: String): Unit = {
+ val method = (new Exception).getStackTrace()(1).getMethodName()
+ assert(method.startsWith(prefix), method + ".startsWith(" + prefix + ") should be true")
+ }
+}
+
+object Test extends App {
+ val t1 = new Test("x")
+ val t2 = new Test(123)
+ val t3 = new Test(1.3)
+
+ // we want specialization to rewire these,
+ // that's why they're not in a for loop:
+ t1.checkSpecialization("x")
+
+ // Prevented by SI-7579:
+ // The duplicator loses the @specialized annotation,
+ // so our tree transformation doesn't know it needs to
+ // specialize specMe inside the duplicated (and specialized)
+ // variants of the `checkSpecialization` method
+ // t1.checkSpecialization(123)
+ // t1.checkSpecialization(1.3)
+ // t2.checkSpecialization("x")
+ // t2.checkSpecialization(123)
+ // t2.checkSpecialization(1.3)
+ // t3.checkSpecialization("x")
+ // t3.checkSpecialization(123)
+ // t3.checkSpecialization(1.3)
+}