This keeps behaviour consistent in rare cases when JavaClass can be found but not resolved
As of now this can happen in IDE if we take PsiClass from index but file structure is wrong so we can't resolve the class
Add test which documents this case
Remove LazyJavaClassResolverWithCache
This actually can affect behaviour because JavaResolverCache has slightly different logic (uses CLASS key in BindingContext as opposed to FQNAME_TO_CLASS_DESCRIPTOR)
Add test suite for smart expression selector (the small expression list
popup in e.g. Extract Variable.)
The test file format is similar to that in JetNameSuggesterTest: a .kt
file with the usual <caret> marker specifying the place where the smart
selector will be run. Then, the last comment in the file should contain
the expected outcome.
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
BuiltInsSerializer will be distributed with Kotlin compiler from now on. This
will allow to serialize binary data of built-ins on 'ant dist', as opposed to
storing all *.kotlin_class files in the repository: ant dist will just invoke
this serializer from bootstrap-compiler.jar
Evgeny Gerashchenko