Required as a workaround for Proguard bug
https://sourceforge.net/p/proguard/bugs/664/
When processing bytecode generated by Kotlin compiler for constructor
call with stack spilling during arguments evaluation, ProGuard performs
an equivalent transformation for the bytecode, but emits invalid stack
frame information.
In JVM 1.6, such invalid stack frames are ignored and re-evaluated by
JVM during bytecode verification.
In JVM 1.8, such invalid stack frames cause VerifyError.
Use legacy implementation title in manifest of JS stdlib for now.
Change the way common jvm project configurations is applied.
Add missing artifacts to common libraries.
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
Ilya Gorbunov