Users' Java code will not break in common cases (when passing functions to
Kotlin), and deprecation warnings will be reported.
Provide an inspection with a quick fix which allows to replace deprecated
function class usages to the new classes. Include this fix to the "code
cleanup" action
Reflection interfaces (interfaces in kotlin.reflect.* in core/builtins/) are
now fully considered as built-ins and can be accessed via KotlinBuiltIns. This
increases runtime size by ~20kb, but only because KotlinBuiltIns is static and
is therefore constructed only via resource loading from the compiler classpath
at the moment. As soon as it's possible to inject KotlinBuiltIns to the
particular resolution process, the metadata on JVM will be loaded via standard
annotation mechanism (kotlin.jvm.internal.KotlinClass/KotlinPackage) and wasted
runtime space will be reclaimed
Metadata for KFunction classes is now longer serialized along with built-in
classes. This effectively means that it's no longer possible to find KFunction
classes via dependency on built-ins. There should be a kotlin-runtime library
in the specified classpath for reflection types to be resolvable.
A lot of tests were moved and changed, because tests on callable references
require stdlib in classpath from now on
'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
Denis Zharkov