Built-in sources are contained now in two directories: compiled and
non-compiled (native). kotlin-plugin.jar has them both under 'jet/', but for
tests we manually specify where to look for the former, as it was for the
latter in LightClassUtil.java.
Simplify code in JetReferenceUtil to have almost the same meaning as in
JetPsiReference.multiResolve()
This is needed because until we have modules and dependencies implemented in
our IDEA plugin, the whole project always is analyzed to highlight any file in
the project. This resulted in weird errors in different modules in Kotlin
project because two declarations were found for each built-in class: the one in
kotlin-runtime.jar and the one (totally unrelated) in the 'builtins' module
Remove references to "out/production/builtins", since those built-ins are
compiled by the bootstrap compiler, whereas we want to test built-ins compiled
by the new (working copy) compiler
Don't store binary data in the repository anymore. From now on any test on the
compiler requires that 'ant dist' was executed at least once since the last
update of the built-ins
Unit.VALUE is annotated right now (with "suppress"), so deserialization was
throwing an exception from AnnotationDeserializer.UNSUPPORTED. Return empty
collections of annotations instead; here we use the fact that it's the only
annotation in built-ins and its presence is useless to the type checker
BuiltInsSerializer now serializes built-ins found in two source roots:
core/builtins/native and core/builtins/src
Add return types to some declarations in core/builtins/src, because now that
BuiltInsSerializer processes them, it launches lazy resolution which can't
always deduce the return type
'builtins' will be used for platform-independent core built-in definitions,
'runtime.jvm' for things that should be present at runtime in order for Kotlin
code to execute correctly on JVM
ProgressionUtil goes to 'builtins' right now because progression iterators
depend on it, but should be rewritten to Kotlin later
The same can't be done with progressions, because its toString() checks if an
increment is greater than zero, but Progression.increment is of type Number,
which is not Comparable<Int>
Don't make 0.0 and -0.0 have the same hash code: they are different in Java (in
the sense that "Double.valueOf(0.0).equals(Double.valueOf(-0.0))" is false),
and they are considered different already in DoubleRange.equals, which calls
Double.compare, which differentiates them
The check in DoubleProgression "if (increment == 0.0 || increment == -0.0)"
(and similar in FloatProgression) was simplified to "if (increment == 0.0)"
because 0.0 == -0.0 on JVM
Andrey Breslav