Permalink
Browse files

[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: #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:
#2486.
  • Loading branch information...
1 parent 082ca2e commit 0c6927b4845633f262794aadda9b188b140717b6 @xeno-by xeno-by committed Apr 28, 2013
File renamed without changes.
File renamed without changes.

0 comments on commit 0c6927b

Please sign in to comment.