summaryrefslogtreecommitdiff
path: root/test/pending/neg
diff options
context:
space:
mode:
authorEugene Burmako <xeno.by@gmail.com>2013-04-28 22:33:36 +0200
committerEugene Burmako <xeno.by@gmail.com>2013-05-11 18:37:10 +0200
commit0c6927b4845633f262794aadda9b188b140717b6 (patch)
tree43df0bbec137ffc57843275a3c0bbc244aee5448 /test/pending/neg
parent082ca2ea97dd925d688ad6ec813f9bbfae12598f (diff)
downloadscala-0c6927b4845633f262794aadda9b188b140717b6.tar.gz
scala-0c6927b4845633f262794aadda9b188b140717b6.tar.bz2
scala-0c6927b4845633f262794aadda9b188b140717b6.zip
[nomaster] temporarily breaks SI-5353
The subsequent fix to SI-5923 unmasks the fact that SI-5353 has not been fixed - it's just that one of its manifestation got hidden behing SI-5923. In fact, if in the code snippet from the bug report we change Array() to Array[Nothing](), things will start crashing as usual. The problem we have here is that arrays of nothings and nulls are very weird in a sense that their compile-time representations (types) and their runtime representations (JVM arrays of Object) behave differently with respect to subtyping. Due to an unlucky coincidence SI-5923 prevented some of the arrays of nothing from being compilable, so the problem was well hidden until now. A principled approach to handling the situation we have here would be to fix SI-5353 (we already know how to do that: https://github.com/scala/scala/pull/2486) and to disallow arrays of nothings and nulls as suggested in SI-7453. Unfortunately, both fixes are going to bring incompatibilities, which are not acceptable in a minor release (this pull request targets 2.10.x). Therefore we decided to turn a blind eye on the iceberg and just fix a tip of it by emulating the portion of SI-5923 that used to mask SI-5353, retaining perfect backward compatibility. Unfortunately, it's not that easy. Apparently one cannot simply report all the occurrences of Array() as errors, because if we know expected type of that expression, then everything's fine - the expected type will drive type inference and the dreaded Array[Nothing]() will not arise. All right, so let's just check whether pt == WildcardType and then report errors. However that's still not enough because of SI-3859. Having my hack failing for the third time, made me stop for a second and think whether it's worth to play with fire and introduce potential breakages for the sake of preventing a quite unlikely bug from happening. I don't think the it's okay to risk here, therefore I just disable the failing test, especially because we already have a working fix to SI-5353 submitted to master, so it's not like we're deferring the work to be done to a random point in unclear future. NOTE: That's only a temporary hack targeted at 2.10.x. There's no reason for this code to be merged into master, because master is soon going to have a principled solution to the problem: https://github.com/scala/scala/pull/2486.
Diffstat (limited to 'test/pending/neg')
-rw-r--r--test/pending/neg/t5353.check4
-rw-r--r--test/pending/neg/t5353.scala3
2 files changed, 7 insertions, 0 deletions
diff --git a/test/pending/neg/t5353.check b/test/pending/neg/t5353.check
new file mode 100644
index 0000000000..75e2435600
--- /dev/null
+++ b/test/pending/neg/t5353.check
@@ -0,0 +1,4 @@
+t5353.scala:2: error: this type parameter must be specified
+ def f(x: Boolean) = if (x) Array("abc") else Array()
+ ^
+one error found
diff --git a/test/pending/neg/t5353.scala b/test/pending/neg/t5353.scala
new file mode 100644
index 0000000000..1ee869aac1
--- /dev/null
+++ b/test/pending/neg/t5353.scala
@@ -0,0 +1,3 @@
+class A {
+ def f(x: Boolean) = if (x) Array("abc") else Array()
+}